Overview

Enabling read-only root filesystem (ROFS) has become a common container security practice to prevent unauthorized modifications to the container’s filesystem. ROFS is recommended by major security frameworks including AWS Security Hub ECS.5, AWS EKS Best Practices, and the NSA/CISA Kubernetes Hardening Guide.

If you’re using a managed deployment method for the Datadog Agent (Helm chart, Datadog Operator, ECS Terraform module, etc.) then ROFS is already enabled. Otherwise, this guide explains how to run the Datadog Agent with ROFS enabled: by configuring writable volume mounts for your self-managed Datadog Agent installation.

Configuration pattern

To configure the Datadog Agent for ROFS:

1. Provide writable volumes for the required directories
2. Use an init container to copy default configuration files before the Agent starts
3. Mount volumes to both the init and Agent containers

Specific implementation varies by platform (Kubernetes, Docker, ECS, etc.), but the pattern remains the same.

Example

The following is complete Docker Compose example demonstrating the read-only root filesystem configuration pattern:

services:
  # Init container populating 'datadog-config' volume with config files.
  datadog-init:
    image: gcr.io/datadoghq/agent:latest
    command: ["sh", "-c", "cp -r /etc/datadog-agent/* /opt/datadog-agent-config/"]
    volumes:
      - datadog-config:/opt/datadog-agent-config

  datadog:
    image: gcr.io/datadoghq/agent:latest
    read_only: true
    pid: host
    depends_on:
      datadog-init:
        condition: service_completed_successfully
    environment:
      - DD_API_KEY=${DD_API_KEY}
      - DD_SITE="datadoghq.com"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - /proc/:/host/proc/:ro
      - /sys/fs/cgroup/:/host/sys/fs/cgroup:ro
      - /var/lib/docker/containers:/var/lib/docker/containers:ro
      # Mounting populated config volume with read-write permissions.
      - datadog-config:/etc/datadog-agent:rw
      - datadog-run:/opt/datadog-agent/run:rw
      - datadog-sockets:/var/run/datadog:rw
      # (optional) The Agent will operate mostly normally without these volumes
      - datadog-tmp:/tmp:rw
      - datadog-logs:/var/log/datadog:rw

volumes:
  datadog-config:
  datadog-run:
  datadog-sockets:
  datadog-tmp:
  datadog-logs:

• datadog-init service copies default configuration files to the datadog-config volume.
• datadog service starts only after init completes successfully.
• All required directories are mounted as writable volumes.

To adapt this pattern to other container orchestrators like ECS, Kubernetes, or plain Docker:

1. Create an init container that copies /etc/datadog-agent/* to a shared volume
2. Mount that volume to /etc/datadog-agent in the main Datadog Agent container
3. Mount writable volumes for other runtime directories (like /opt/datadog-agent/run and /var/run/datadog)
4. Enable read-only root filesystem

Datadog Agent filesystem write footprint

Following Linux Filesystem Hierarchy Standard (FHS) guidelines, the Datadog Agent writes defaults to the following directories, which require read/write permissions:

Troubleshooting

Agent fails to start with “read-only file system” errors

Check the Agent logs to identify which directory needs write access. The most common required directories are /etc/datadog-agent/, /opt/datadog-agent/run/, and /var/run/datadog/.

Metrics or traces not being collected

1. Verify that /var/run/datadog/ is mounted as writable. This directory contains the APM and DogStatsD socket files needed for trace and metric collection.
2. Confirm default /etc/datadog-agent/conf.d checks aren’t overwritten by an empty volume.

Flare creation fails

Agent flare requires write access to /tmp/. If generating flares is important for your troubleshooting workflow, mount /tmp/ as a writable volume.

Further Reading

お役に立つドキュメント、リンクや記事:

Datadog Docker Agent documentationDOCUMENTATION Datadog Kubernetes documentationDOCUMENTATION AWS Security Hub ECS.5 ControlEXTERNAL