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 <[email protected]>: > 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 [email protected]. > 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 [email protected]. 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.
