Docker run options

Docker run options

docker run offers a few configuration options that can be enabled to share data with the container. While these options can be interesting for monitoring purpose (eg. sharing the process tree, the network stack, etc.), they can represent a security threat if available in the container.

The purpose of this document is to explain how and why to enable these options, and to warn about the risks of doing so.

--privileged

By default, Docker containers are “unprivileged” and cannot, for example, run a Docker daemon inside a Docker container. This is because by default a container is not allowed to access any devices, but a “privileged” container is given access to all devices

When the operator executes docker run --privileged, Docker will enable to access to all devices on the host as well as set some configuration in AppArmor or SELinux to allow the container nearly all the same access to the host as processes running outside containers on the host. Additional information about running with --privileged is available on the Docker Blog.

Docker documentation

The --privileged switch gives a lot more power to the container. Without it root privilege in the container is quite limited (mount operations are forbidden, access to raw sockets is denied, etc.), but this flag lifts all the limitations enforced by the device cgroup controller, and gives all capabilities to the container. In other words, the container can then do almost everything that the host can do.

It should therefore be used with caution. It is only necessary to use it in specific cases with the Datadog agent container, and it should be avoided when possible.

--net=host

Tells Docker to skip placing the container inside of a separate network stack. In essence, this choice tells Docker to not containerize the container’s networking!

While container processes will still be confined to their own filesystem and process list and resource limits, a quick ip addr command will show you that, network-wise, they live “outside” in the main Docker host and have full access to its network interfaces. Note that this does not let the container reconfigure the host network stack — that would require --privileged=true — but it does let container processes open low-numbered ports like any other root process. It also allows the container to access local network services like D-bus. This can lead to processes in the container being able to do unexpected things like restart your computer. You should use this option with caution.

Docker documentation

This option is useful to collect fine grained network metrics about what happens on the host, and in other containers depending on their own configuration. It would for example allow to collect stats about all network interfaces and not just the general network stats about docker. However the container would have more power over the host than what we think is right.

--pid=host

In certain cases you want your container to share the host’s process namespace, basically allowing processes within the container to see all of the processes on the system.

Docker documentation

This parameter will share the process table of the host with the container. Processes running on the host would be visible to the container - running ps -e will illustrate that - and processes inside the container could interact with them.

This feature is useful in case some interesting processes are running on the host and they need to be monitored. In this case the process check running in the agent container will be able to collect metrics about them since the container processes belong to the same process tree as the host's.

The issue is that sharing the same process table gives more power over the host to the container than needed, and raises security issues as processes running in the container could kill and/or tamper with some of the processes running on the host.

Note: If the container is also running with --privileged, the security issue gets even more serious.