5 ms·

While this thread has visibility, I am curious about your typical security model with docker. From my experience, whoever is running docker seems to be able to

While this thread has visibility, I am curious about your typical security model with docker. From my experience, whoever is running docker seems to be able to run root commands on the host [1]. So any best practices for running docker ? [1] http://reventlov.com/advisories/using-the-docker-command-to-root-the-host http://reventlov.com/advisories/using-the-docker-command-to-...

majewsky 10y ago
In production, you usually don't want to have users running around and spawning containers anyway. You will likely have an orchestrator like Kubernetes or Mesos or Swarm, who will be running as root and spawning containers for you. Of course, that just replaces the question of "how is access to the docker daemon secured?" with "how is access to the orchestrator API secured?".
- shriphani 10y ago
  How about something that isn't spawned by an orchestrator - for instance the marathon load-balancer - they provide only a docker image which clearly is meant to be run using `docker run`
  - majewsky 10y ago
    I would still run it using an orchestrator, if only to have it restart the container automatically on failure or after your node reboots.
    - shriphani 10y ago
      I mentioned this in a sibling comment - I'm currently running the container using systemd which gives me restart ability and all that. Do you think this is insufficient?
r4um 10y ago
Other security controls aside, for the user thing we make it mandatory to have USER directive in the Dockerfile, else the docker builds fail.
justincormack 10y ago
You can use authorization plugins to control what commands are allowed. However generally you don't give people access to run any docker command in production, you have some system that lets them deploy containers with predetermined settings, which don't include being able to set --privileged or add capabilities or change security policies.
- shriphani 10y ago
  I am currently running docker with a systemd script (it seemed like a reasonable idea at the time). But docker = sudo without password essentially. So I am curious if there is a recommended way to run a service with a docker run.
lima 10y ago
Best practice? Docker daemon access to equivalent to root access, so only allow it for root.
hackits 10y ago
I would of though that if you want to restrict developer from doing that you would add commands to the sudoes file? isn't that the whole point of sudo? Correct me if I'm wrong, I'm interested to know? I'm currently looking into docker and the advantages it brings to deployment instead of using a VM.
_joel 10y ago
Take a look at this pdf - https://www.nccgroup.trust/globalassets/our-research/us/whitepapers/2016/april/ncc_group_understanding_hardening_linux_containers-10pdf/ https://www.nccgroup.trust/globalassets/our-research/us/whit... There is also a docker-bench-security tool set worth checking out.
wlamartin 10y ago
You are right that docker currently runs as root. There is some phenomenal work that Aleksa Sarai is doing on getting runc to work as an unprivileged user [1] that Docker should be able to take advantage of at some point. There are still a lot of places which need love without root in the Docker world, but it's a huge step forward. [1] https://github.com/cyphar/runc/tree/rootless-containers https://github.com/cyphar/runc/tree/rootless-containers

majewsky 10y ago

In production, you usually don't want to have users running around and spawning containers anyway. You will likely have an orchestrator like Kubernetes or Mesos or Swarm, who will be running as root and spawning containers for you. Of course, that just replaces the question of "how is access to the docker daemon secured?" with "how is access to the orchestrator API secured?".

shriphani 10y ago
How about something that isn't spawned by an orchestrator - for instance the marathon load-balancer - they provide only a docker image which clearly is meant to be run using `docker run`
- majewsky 10y ago
  I would still run it using an orchestrator, if only to have it restart the container automatically on failure or after your node reboots.
  - shriphani 10y ago
    I mentioned this in a sibling comment - I'm currently running the container using systemd which gives me restart ability and all that. Do you think this is insufficient?

r4um 10y ago

Other security controls aside, for the user thing we make it mandatory to have USER directive in the Dockerfile, else the docker builds fail.

justincormack 10y ago

You can use authorization plugins to control what commands are allowed. However generally you don't give people access to run any docker command in production, you have some system that lets them deploy containers with predetermined settings, which don't include being able to set --privileged or add capabilities or change security policies.

shriphani 10y ago
I am currently running docker with a systemd script (it seemed like a reasonable idea at the time). But docker = sudo without password essentially. So I am curious if there is a recommended way to run a service with a docker run.

lima 10y ago

Best practice? Docker daemon access to equivalent to root access, so only allow it for root.

hackits 10y ago

I would of though that if you want to restrict developer from doing that you would add commands to the sudoes file? isn't that the whole point of sudo? Correct me if I'm wrong, I'm interested to know? I'm currently looking into docker and the advantages it brings to deployment instead of using a VM.

_joel 10y ago

Take a look at this pdf - https://www.nccgroup.trust/globalassets/our-research/us/whitepapers/2016/april/ncc_group_understanding_hardening_linux_containers-10pdf/ https://www.nccgroup.trust/globalassets/our-research/us/whit... There is also a docker-bench-security tool set worth checking out.

wlamartin 10y ago

You are right that docker currently runs as root. There is some phenomenal work that Aleksa Sarai is doing on getting runc to work as an unprivileged user [1] that Docker should be able to take advantage of at some point. There are still a lot of places which need love without root in the Docker world, but it's a huge step forward. [1] https://github.com/cyphar/runc/tree/rootless-containers https://github.com/cyphar/runc/tree/rootless-containers