Stephen, thanks for your reply. You're right, nobody would run Jenkins as root in a production environment, but through the Cloudbees Docker Workflow plugin Jenkins is in control of the docker client, and hence it's root on some machine (e.g. a build slave).
I don't really understand what you mean with "running a build slave as the trusted account". Maybe I'm missing something here, but from a security point of view, as soon as untrusted users control a docker host on a build slave (e.g. through Jenkins job definitions) that build slave is all but trusted, and an untrusted machine has no place in a corporate network. If one builds a firewall around an untrusted build slave as mitigation, I would expect practical problems accessing SCM or artifact repositories inside the corporate network from that slave. Calling the docker client through Jenkins can be considered safe if Jenkins runs in a locked down environment (where only trusted users can define jobs), or if the docker host (build slave) is short lived (e.g. an ephemeral VM like Boot2Docker). Unfortunately, non of these options would work for me. /Thomas On Monday, January 11, 2016 at 3:08:41 PM UTC+1, Stephen Connolly wrote: > > FYI you do not run *Jenkins* as root... rather you run a build slave as > the trusted account and then you lock down access to that build slave... > e.g. if that build slave deploys into production you can use it as a kind > of bastion host whereby it is off-line until you want to deploy into > production. > > On 10 January 2016 at 11:17, Thomas Goeppel <thomas....@gmail.com > <javascript:>> wrote: > >> >> >> On Sunday, January 10, 2016 at 1:05:07 AM UTC+1, Christopher Orr wrote: >>> >>> > One option would be to write a shim for the docker command, that only >>> > allows a subset of commands, and sanitizes the options and parameters. >>> >>> Even if you do that, the jenkins user, as part of the docker group, will >>> still have direct access to the unix socket that the Docker daemon uses. >>> >>> >> As is quite often the case with a CI server, you most likely need to >>> either trust the users who can configure jobs (or edit Workflow scripts >>> (if in source control)), or lock down the Jenkins configuration to allow >>> only specific users. >>> >>> >> >>> The Docker security guide also says "only trusted users should be >>> allowed to control your Docker daemon": >>> https://docs.docker.com/engine/articles/security/ >>> >>> I feel that you're mixing up two areas of trust here, Jenkins (and CI >> users), and Docker (and system administrators). In an organization of any >> size or complexity, the roles allowed to control Jenkins won't be held by >> the same people that have the roles with root access. Even if it were so, >> just how much would one have to lock down a Jenkins production environment >> to mitigate the risks associated with running Jenkins as root, i.e. user >> "jenkins" in the group "docker"? >> >> We could give up on provisioning containerized toolchains through Jenkins >> in a Non-Root-Jenkins production environment, but there is a lot of value >> in running and controlling Docker containers through Jenkins. Fortunately, >> full control of Docker isn't required for this use case: Jesse Glick >> demonstrated that nicely with the implementation of docker.image().inside >> {} that passes reasonably safe parameters through the Docker CLI (e.g. -u >> non-root). >> >> Obviously, delegation of watching over safe use of the Docker CLI to >> Jenkins isn't possible in any environment where we can't run Jenkins as >> "root" ("docker"), and hence we need a trusted proxy. Technically that >> proxy might run with "setuid docker" (and have access to the Unix socket), >> or use a web service, but I think that the docker counterpart to a >> "restricted >> shell <https://en.wikipedia.org/wiki/Restricted_shell>" would be best. >> >> -- >> 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-use...@googlegroups.com <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/jenkinsci-users/aa632bac-58cb-4e3f-9238-ab1ad4424fe8%40googlegroups.com >> >> <https://groups.google.com/d/msgid/jenkinsci-users/aa632bac-58cb-4e3f-9238-ab1ad4424fe8%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/e20cbe1a-6da3-4e39-86cc-7055b5109995%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
