Exposing Docker socket provides root escalation path

[fotinakis]

Any thoughts on this? https://www.lvh.io/posts/dont-expose-the-docker-socket-not-even-to-a-container.html

Is it required to have the the docker socket exposed to the Datadog agent?

[alq666]

@fotinakis we are looking into it. I think we only need read access but we will confirm once we have a good solution.

[fotinakis]

Sounds good, looking forward to hearing about it.

[alq666]

@fotinakis I take that back as we need to send commands to the socket to communicate with the daemon (we use docker-py for that). Stay tuned.

[remh]

@fotinakis For now there is unfortunately no workaround. We require the docker socket to be exposed so that the agent can communicate to the Docker API.

The Agent only performs read only operations to the API (that can be audited in the dd-agent repo: https://github.com/DataDog/dd-agent).

The read only operations that are performed are needed for the docker_daemon (formerly docker) check to run, as it's the only way for us to list the containers and get their metadata.

Hopefully the docker remote api will implement more fine grained permissions so that the Datadog Agent would be restricted to read only operations.

[fotinakis]

That makes sense, but aren't the security vulnerabilities mitigated if you mount the socket as readonly? So, this might be as simple as updating the README to have :ro on the docker socket as well, or am I missing something?

I use kubernetes so it's a bit of a different config format for me, but I'd love to know if mounting the socket readonly would still work for this container. From what you're saying, it probably does.

[leonardpunt]

FYI: we're using Kubernetes as well and mount the Docker socket as read-only. This works perfectly fine.

[hkaj]

Mounting the socket as read-only should work just fine, it's just not helping that much. Basically it only prevent the container from deleting the socket, not from issuing write operations to the socket.

An attacker with access to the agent container could still tamper with containers linked to this socket. I will update the documentation to suggest using :ro but keep in mind that it does not make write operations impossible.

Docker would need fine grained permissions for this.

[sinneduy]

It has been almost 3 years since this issue was initially opened. As someone who is interested in running Datadog in my Kubernetes setup, how can I do so without exposing the docker socket to the Datadog container?

[hkaj]

Hi @sinneduy In Kubernetes you can skip mounting the docker socket, and rely solely on the kubelet API for pod metrics. We also support autodiscovery based on the kubelet instead of docker.

You will loose docker metrics by doing that, but most of them are mirrored by metrics that we get from the kubelet anyway, so just look for metrics starting with kubernetes. in the app and you should see most of what we get from docker show up.

Side note: this repo is for the old version of the datadog agent. For more recent info, refer to the datadog-agent repo