My two cents : * Set executors number on master to 0 and run jobs only on slaves. That prevents anyone without admin access to your master to screw it. * If you're still afraid to screw your slaves, use one-off slaves using one of the Cloud implementations (using VMWare, Docker, or any other solution which would be applicable in your case) * Restrict who can define jobs either directly in Jenkins, or by using a plugin such as Job DSL plugin which allows you to put these definition in a SCM (then you use whatever access control your SCM allows to review any incoming changes)
Vincent 2016-03-30 23:21 GMT+02:00 Jason Hull <tarballe...@gmail.com>: > Thank you for your response, Victor! > > Below are my responses to your comments. Before that, however, for > background I should state that I work in a large enterprise in a highly > regulated industry. Thus my keen interest in security. > > On Wednesday, March 30, 2016 at 3:31:18 PM UTC-5, Victor Martinez wrote: >> >> I see there are two different points: >> >> 1) Securing your Jenkins instance >> a) Probably you could add some security policies: >> - https://wiki.jenkins-ci.org/display/JENKINS/Securing+Jenkins >> - https://wiki.jenkins-ci.org/display/JENKINS/Ownership-Based+security >> > Thank you for the links. There's a lot of info here so I'm still > digesting, but I think these are (mostly) user security oriented and don't > necessarily discuss self-inflicted wounds. > > >> b) Avoid granting privileges to the 'jenkins' user more than the required >> > This is the crux of the problem. Jobs run as Jenkins and thus can edit > anything that Jenkins owns, like authorized_keys, credentials.xml, etc. > > >> c) Also you could develop a particular plugin to avoid running jobs which >> contains those particular rm -rf, although some evil might skip that and do >> something else... >> > The links you shared in a) lead me to > https://wiki.jenkins-ci.org/display/JENKINS/Slave+To+Master+Access+Control > . > > My gut tells me blacklisting will be too limited/ineffective and > whitelisting will be too crippling. > > 2) Configuration Management tools >> Regarding your authorized keys, if you use any kind of Configuration >> Management tools you might fix that easily as those systems won't be in the >> expected state and will be changed immediately or after a period of time. >> > Yes, this is a good point. However I'd like to lock the door rather than > just closing it automatically after an intruder has walked in. > > Although I'll prefer to trust my users rather than stopping them/blocking >> them. But that's my point of view. >> > I agree with you. This doesn't cut it, however, in highly secure/regulated > environments. > > -- > You received this message because you are subscribed to the Google Groups > "Jenkins Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to jenkinsci-users+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jenkinsci-users/771ee4fe-5ed7-4d22-9891-f6c73777a426%40googlegroups.com > <https://groups.google.com/d/msgid/jenkinsci-users/771ee4fe-5ed7-4d22-9891-f6c73777a426%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/CAH-zGCjvQ3npWNyE_r5YEr%3DyK8aYJJ%2BiSnog4Haq1A-8W68J_A%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
