Hacker News new | ask | show | jobs
by raesene4 3746 days ago
With 1.10 you can just enable User namespaces, which allows for root in a container to map to a non-privileged user outside the container, that way it's a one-time (per instance) change.
1 comments

While this is a nice security boost once you're in the container, don't you still need to be root (docker group) in order to start the container? It honestly doesn't help me much if I have to give users root in order to start a container, even if they are wrapped inside the container.
Yep, at the moment, with raw docker engine, if a user has access to create containers, they're basically able to get root on the box, as the docker daemon runs as root and there isn't any authorization control by default, so it doesn't work well for that kind of scenario.

With that said there's a couple of ways this is getting addressed.

1) in 1.10 authorization plugins landed as a feature,so it's possible to add this functionality. 2) there's a number of services which run on top of Docker Engine (e.g. Docker Universal Control Plane) which have authentication/authorisation at that level.

This is what sudo is for. Give each user access to run their containers (and only their containers) as a member of the docker group in sudoers.
This doesn't work when users may need to run arbitrary (or user-defined) containers. You can only sudo so much... But, perhaps you could restrict it to "sudo docker run". I'll have to give that a try. But that would make it extraordinarily more difficult for a user to stop / rm / kill a container. Plus, it's not like docker has the concept of an "owner" for a container - does it?

Nonetheless, you shouldn't need to run anything as root in order to start a container that doesn't require extra privileges .

Please clarify what you mean by "access to run ... only their containers". How is that possible?
sudo arguably is another vector of attack