Hacker News Reader

Comment by goatinaboat | Hacker News Reader

For a very long time there was a gaping security hole in Docker: anyone who could run a container could mount anything on the underlying host as root. This says to me that Docker (the company) don’t really consider any use cases beyond “fooling around on a personal laptop”. Meanwhile other container projects took seriously from day 1 that they would need to run in production.

Docker (the company) certainly helped to raise the profile of containerisation but they invented very little of it and did a poor job of implementing what they did do. Good riddance to them.

View on HN

A couple of things :-

You can still mount filesystems as root from a container, if you have Docker command rights. In Docker's security model access to run docker commands on a given host == root, that's a design choice AFAIK, not an oversight.

It's perfectly possible to mitigate that issue, by restricting who can run containers and also ensuring that all containers specify and use a non-root user account (or enable user namespaces at the Docker daemon level)

Also, many early stage technologies don't prioritise security . For example, for several early releases of Kubernetes all you needed was remote access to a single port (10250/TCP) and you could get root access to the underlying host without any authentication...

If you run in your container as a non-root user, it makes working with volumes a pain. Who knows what the container user UID will map to on the host and whether this host user, if any, will have permissions to access files in the volume.

Otherwise you can hard code a UID when creating the user in the Dockerfile but that means your containers aren't generally portable.

In the end, the path of least resistance is to run as root within the container and simply accept the security implications if using volumes.

In the Dockerfile, get UID and GID as ARGs, and make sure those variables are available in your host environment. Then when creating the user in Dockerfile, use that UID and GID. Volumes will work like a charm.

That's what I am doing for local development setups with Docker.

See https://github.com/a2way-com/template-docker-laravel/blob/ma... and its README.

That means your docker file is portable, but your images are not, which is what your parent is referring to. It's a friggin mess. It's still the same as when I started using docker.

> Docker (the company) don’t really consider any use cases beyond “fooling around on a personal laptop”

Much worse: Docker was never built with security in mind but the company kept pushing it as production ready.

That's not a gaping security hole. Only root users can run docker containers. Users added to the docker group count as root users and the documentation explictly tells you that.

That's only a problem if you allow untrusted users operate the docker daemon.

That's only a problem if you allow untrusted users operate the docker daemon.

Sure, if you trust every developer in your company with the root password anyway, why not? That might be true at Docker (the company), I don’t know. Certainly wasn’t true at one company I worked at with 30,000 devs...

By the way, this problem does not exist with competing container tools like Podman/Buildah.

Why would you be allowing devs to directly deploy to production in a company with 30,000 developers?

Surely you'd have proper release management where Ops teams would review deployment artifacts before deploying them?

You wouldn’t but you wouldn’t give every dev root access to every dev box either... would you?

I'd have developers working in Dev VMs on their laptops, and sure I'd let them have root access to those.

Not necessarily every dev box, but I'd say that in most environments it's reasonable that devs would have full permissions in any "their" dev boxes/VMs. If you split boxes/VMs across devs instead of sharing them, then the access would be limited to whatever people are assigned to own that box, but they'd have full access. I mean, if something breaks, it should be trivial to reset that machine or get a new one, VMs can be cloned and spawned in seconds and there's no reason not to spend an hour once so that you automatically get a fully working dev environment with all the tooling needed.

In any case the notion of "the root password" seems weird, root passwords should be unique (even for VMs), randomly generated, and mostly not used; in most situations you'd use publickey authentication instead of passwords.

Reply on news.ycombinator.com