-
Improvement
-
Resolution: Incomplete
-
Major
-
None
We are encouraging our developers to use the new declarative pipeline syntax with docker agents to fully isolate their builds and give them control over the environment. However, when said builds in turn produce docker images (such as via the docker-maven-plugin) they do not work with this approach, giving an error along the lines of
[ERROR] Failed to execute goal io.fabric8:docker-maven-plugin:0.23.0:build (default-cli) on project my-project: Execution default-cli of goal io.fabric8:docker-maven-plugin:0.23.0:build failed: No <dockerHost> given, no DOCKER_HOST environment variable, no read/writable '/var/run/docker.sock' or '//./pipe/docker_engine' and no external provider like Docker machine configured -> [Help 1]
There are a few ways to resolve this, from setting the DOCKER_HOST variable and exposing and outside docker daemon to the container, or mounting the hosts's /var/run/docker.sock into the image. However it is not clear that there is a way to achieve this without requiring developers to include these steps in their Jenkinsfiles. It would be great if for example there was a way to se thte default options that get applied to a docker invocation in a pipeline so that developers do not have to worry about these concerns and this style of build could be supported system-wide.
"exposing and outside docker daemon to the container" introduces a significant security risk. In some circumstances (dedicated docker host) this is acceptable, but this can't be the default option.
Best way to address this is for you to have your pipeline configure DOCKER_HOST to target an explicitly configured docker infra with adequate credentials to be can used by configured job. Doing this you can filter from docker infra the permissions granted to your build.
Other option would be for docker-plugin to act as proxy to underlying docker infra (like it does with classic build steps) and offer some filtering on available commands / inject security options. Typically, any container/build ran from your build should share the same parent cgroup to ensure assigned resource quotas for this build are applied.