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.goep...@gmail.com> 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-users+unsubscr...@googlegroups.com. > 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/CA%2BnPnMzzUaSbkC7C3DxQ8KOtYDh3vGpe1Cnzw3v-%2B4snAxtZ8w%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
