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