2 ms·

> I mean they could ship rootless docker by default, like podman defaults to rootless (or other by now possible more secure non default setups). Upstream doesn

> I mean they could ship rootless docker by default, like podman defaults to rootless (or other by now possible more secure non default setups). Upstream doesn’t support that configuration as default and it will likely break all the docker tutorials online that assume a rootful daemon. (A quick example: google “Jenkins docker integration” and it will likely tell you to pass through the docker socket) Hence package maintainers don’t want to take the burden of maintaining that.

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.

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.