3 ms·
But exactly that is the issue especially something like Jenkins shouldn't use the default docker setup, but one of the multiple ways it can be hardened (mainly
by dathinab 2y ago
But exactly that is the issue especially something like Jenkins shouldn't use the default docker setup, but one of the multiple ways it can be hardened (mainly rootfull using user namespaces or rootless using user namespaces).
also to quote that documentation:
> By default, the Docker Pipeline plugin will communicate with a local Docker daemon, typically accessed through docker.sock.
which means that iff they do it right it will just work frictionless. Rootless docker still has a local socket and in a proper setup $DOCKER_HOST is used to point to it. $DOCKER_HOST is used the docker command, and any other application which communicates with the docker socket instead MUST handle it or it's a pretty big bug even in the absence of rootless.
And again you don't need rootless, you can also configure user namespaces with rootfull docker. Which isn't fixing all issues for all use cases, but fixes the ones which are an security issue for Jenkins.
In general the only place where a default docker setup can be security wise acceptable is where it's acceptable to always explicitly use sudo, e.g. no developer setup. Which mainly leaves use cases like using it for long running manual managed services, but then using podman instrumented through systemd (systemd directly supports OCI images as services) is still most times preferable.