RFE: Ability to restrict use of insecure options for user-defined containers

[0x442E472E]

Setup Jenkins version: 2.138 Docker Plugin version: 1.1.5

Motivation We would like to isolate the builds of our development teams. Their build configs can already be isolated using the built-in permissions of Jenkins. However, on a file basis, there is no built-in way to separate the individual workspaces and processes because everything is being run using the same user. Using the Docker Plugin, it is theoretically possible to execute each build in a temporary container and thus isolating the individual builds. In practice, the Docker Plugin allows custom docker templates per build config which could be used to break the isolation. As an example, the build could run as root and also mount docker.sock or even activate privileged mode, which essentially grants root access to the host.

Feature Request We are kindly requesting to a) introduce a setting that disallows custom docker templates b) alternatively, a possibility to disallow customizing specific settings (like volumes, user, image or privileged mode)

This should be sufficent to isolate the individual builds.

[pjdarton]

TL;DR: If you want your docker containers to be secured against each other then the place to do that is in the docker host.

You are correct that privileged mode opens up all sorts of security concerns but if you're concerned about that, the place to enforce that is in the docker host itself, not the Jenkins docker-plugin. The Jenkins docker plugin isn't doing anything that a Jenkins build (that's equipped with a docker client) can't do, so if your docker host allows "anyone who asks" to create a docker container with dubious mount points and with privileged mode set then configuring Jenkins not to make it easy still isn't going to stop people, as users could simply ask the docker host to do this without Jenkins' help.

i.e. Having Jenkins say "I'm not going to help you do that" isn't going to prevent people from doing that.

[0x442E472E]

I do agree that enforcing permissions should happen on the docker host, if possible. However, i don't see that as an argument against my feature request because we are talking about two completely different groups of users here. You seem to be assuming that the people who have access to the docker host are also the people that create build configs, but this is not the case for us. Assuming jenkins doesn't leak the credentials, the latter group of users would not be able to circumvent any restrictions enforced by jenkins.

[pjdarton]

I guess you're right, as long as the credentials for the docker host are locked down sufficiently that Jenkins can only use it for globally-configured slaves. Without further research, I don't know enough about the Jenkins credentials subsystem to say if that's possible or not.

OK; if you (or someone else) creates a PR that implements it then, assuming the code's acceptable, there's no reason it wouldn't get merged in.