52 ms·

These are all pretty good points. I can understand why Docker allows any base layer OS, but they could have made their own packages or limited a single distro a

• krferriter 7y ago
  We were using Docker-in-Docker in our cluster to run user-defined containers, and something about it resulted in the outer container disk usage blowing up to like 20GiB per container. I think something due to the overlay filesystem driver. We were under a time constraint so we just grew all the host root filesystems, but it was pretty inconvenient and not inexpensive to do so. I have to assume this also had a drastic negative impact on storage I/O performance in the inner container as well.
  • geggam 7y ago
    Docker in Docker feels like a root kit generator to me
• imiric 7y ago
  > The fact you have to share the entire Docker socket for containers to be able to control other containers, or that it's not trivial to run Docker-in-Docker, is terrible. FWIW, if you enable the remote API, which, granted, isn't as trivial to do securely as it should be[1], then you can connect from any Docker client by simply setting the `DOCKER_HOST` env var and using the right TLS certs. This makes Docker-in-Docker much easier to manage, avoids the security issues of sharing the Unix socket, and works remotely of course. [1]: https://docs.docker.com/engine/security/https/ https://docs.docker.com/engine/security/https/
  • djsumdog 7y ago
    I created an ansible role that does this for me: https://github.com/sumdog/bee2/blob/master/ansible/roles/docker/tasks/servertls.yml https://github.com/sumdog/bee2/blob/master/ansible/roles/doc... It creates client certs and copies them locally too, so I can connect to Docker remotely over a VPN. Still this doesn't solve the original problem I talked about. It's not about securely connecting to the daemon. Even if you connect securely, you still essentially have root access on the host machine. I've considered writing a proxy that restricts what commands can be forwarded on to the Docker host socket (e.g. allowing for container IPs x,y and z to restart containers, but not to create new ones or pull images). There doesn't seem to be fine grained security or roles built into the docker daemon itself. Running docker in a docker container would give you a throw-away docker to use for things like Jenkins, Gitlab-CI, and other build tools without giving it access directly to root on the host.
    • imiric 7y ago
      > Even if you connect securely, you still essentially have root access on the host machine. Your original point was about the pain of sharing the Unix socket to control other containers, so that's why I brought up the API approach. It's been a while since I used Docker, but have you tried enabling user namespace remapping[1]? I remember it working as documented, and don't see why it wouldn't work remotely or DiD. There's also experimental rootless support since 19.03[2], maybe give that a try. Other than that, make sure you trust the images you run, or preferably, inspect every Dockerfile, ensure that the process runs as an unprivileged user, and build everything from scratch yourself. I agree with you that this is a major security issue, but we've known that since its introduction, and things seem to be improving, albeit slowly. Thankfully, nowadays there is other OCI-compatible tooling you can use and sidestep Docker altogether. Podman[3] is growing on me, mostly because of rootless support, though it's not without its issues and limitations. [1]: https://docs.docker.com/engine/security/userns-remap/ https://docs.docker.com/engine/security/userns-remap/ [2]: https://github.com/moby/moby/blob/master/docs/rootless.md https://github.com/moby/moby/blob/master/docs/rootless.md [3]: https://podman.io/ https://podman.io/