In Kubernetes environments, applications often communicate with the Datadog Agent to send telemetry data such as custom metrics via DogStatsD or traces through Datadog APM. How this communication takes place depends on the communication mode set on the Datadog Cluster Agent’s Admission Controller. With the sockets option, communication takes place through local inter-process communication via Unix domain sockets (UDS), whereas the service and default hostip options rely on network communication.

Among these methods, the sockets option via UDS is typically preferred because it bypasses the network stack entirely, resulting in better speed and performance. The sockets option also helps improve observability because UDS makes it easier for the Agent to identify the origin of packets sent to the socket. However, enabling UDS-based communication has historically required mounting socket files via hostPath volumes, a method incompatible with namespaces governed by non-privileged Pod Security Standards (PSS).

To resolve this issue, Datadog has released a CSI (Container Storage Interface) driver that mounts UDS sockets into pods by using CSI volumes instead of hostPath volumes. CSI volumes are compatible with all PSS levels, including the restricted level, making it possible for teams to adopt UDS-based observability features without violating security constraints.

In this post, we’ll look at:

• Why hostPath volumes are blocked in secure Kubernetes environments
• How UDS sockets are mounted securely with the Datadog CSI driver
• Which mount types are supported for observability sockets
• How CSI volumes are injected using the Datadog Admission Controller
• What’s next for CSI driver support

Why hostPath volumes are blocked in secure environments

In Kubernetes, hostPath volumes allow pods to mount files or directories directly from the host node’s filesystem. Though flexible, this mechanism introduces significant security risks. For example, malicious or compromised pods could access sensitive host data—such as kubelet credentials—or interact with the container runtime in ways that could lead to privilege escalation or lateral movement.

For these reasons, Kubernetes defines hostPath as a privileged capability and disallows its use under the baseline and restricted Pod Security Standards. These standards are increasingly adopted in security-conscious organizations and are documented in the Kubernetes Pod Security Standards guide.

How UDS sockets are mounted securely with the Datadog CSI driver

The Datadog CSI driver provides a Kubernetes-native way to mount DogStatsD and APM UDS sockets into application pods using CSI volumes. Introduced as part of the CSI GA effort by Kubernetes (as explained in this blog post), CSI allows third-party vendors to implement secure volume plugins without relying on hostPath.

By using the CSI driver, Datadog shifts the hostPath volume from the user namespace to the CSI driver namespace. With this shift, user apps mount a Datadog CSI volume, and there is no need for user apps to mount a hostPath volume since it is replaced with a CSI volume. This new arrangement allows your services to use high-performance telemetry data and APM trace ingestion via sockets even in namespaces with restrictive pod security standards.

The CSI driver is deployed as a Kubernetes DaemonSet and is open source, with support for manual setup or Helm-based configuration. It is compatible with all CSI-enabled Kubernetes versions (v1.13+), and integrates directly with the Datadog Admission Controller to simplify adoption.

Which mount types are supported for observability sockets

The CSI driver supports four mount types, enabling both granular and directory-level socket access. You can configure:

• DSDSocket: to mount only the DogStatsD socket file
• APMSocket: to mount the trace agent’s socket file
• DSDSocketDirectory: to mount the parent directory of the DogStatsD socket
• APMSocketDirectory: to mount the parent directory of the trace agent socket

These options are defined in the type property of Datadog CSI volume’s VolumeAttributes and used in conjunction with standard pod volumeMounts. Example manifests and usage guides are available in the GitHub README.

How CSI volumes are injected using the Datadog Admission Controller

Datadog’s Admission Controller automatically configures observability communication for pods based on the selected mode: service, hostip, socket, or the newly added csi. When csi mode is enabled, the Admission Controller injects a CSI volume instead of a hostPath volume—ensuring compliance with any enforced PSS policies.

The admission controller handles this transformation transparently, as shown in the sequence diagram below. When a user creates a pod, the Admission Controller mutates the pod spec to include a CSI volume source for socket-based communication. When the pod is scheduled, the kubelet requests the CSI volume, and the Datadog CSI driver mounts the appropriate socket into the container.

What’s next for CSI support

In upcoming updates, Datadog is planning to extend the CSI driver to support mounting APM Single Step Instrumentation (SSI) libraries via CSI. This will allow pods that use APM SSI to start faster and use disk more efficiently, as the libraries will be available at container startup without needing to be downloaded or injected post-launch.

Run UDS-based observability securely with Datadog CSI

With the Datadog CSI driver, Kubernetes users can enjoy the full performance benefits of UDS-based observability—even in environments governed by restrictive Pod Security Standards. The CSI-based approach ensures compliance with Pod Security Standards and integrates with Datadog Admission Controller to automatically inject the CSI volume into pods.

To learn more, check out the Datadog CSI driver on GitHub and read our documentation for step-by-step setup instructions. If you’re not yet using Datadog, you can sign up for a 14-day free trial.