Considerations for Setting ReadonlyRootFilesystem to true in ECS Task Definitions

When enhancing container security on ECS, you might encounter the following finding from AWS Security Hub's Cloud Security Posture Management (CSPM):

[ECS.5] ECS containers should be restricted to read-only access to their root file system.

This control checks whether an Amazon ECS container has read-only access to its root file system. The control fails if the readonlyRootFilesystem parameter is set to false, or the parameter doesn't exist in the container definition within the task definition. This control evaluates only the latest active revision of an Amazon ECS task definition.

https://docs.aws.amazon.com/securityhub/latest/userguide/ecs-controls.html#ecs-5
While it's a straightforward process to improve security by setting the readonlyRootFilesystem parameter to true in your task definition, enforcing a universal write prohibition can cause certain features to malfunction. Below are a couple of examples.

ECS Exec

ECS Exec allows you to connect to a running container and leverages the AWS Systems Manager (SSM) framework. This feature requires write permissions to specific volumes to function correctly. Specifically, you need to allow write access to the /var/lib/amazon and /var/log/amazon directories. Here is an example of how to configure this in your task definition.

{
  ...
  "containerDefinitions": [
    {
      ...
      "mountPoints": [
        {
          "sourceVolume": "var-lib-amazon",
          "containerPath": "/var/lib/amazon",
          "readOnly": false
        },
        {
          "sourceVolume": "var-log-amazon",
          "containerPath": "/var/log/amazon",
          "readOnly": false
        }
      ],
      ...
    },
    ...
  ],
  ...
  "volumes": [
    {
      "name": "var-lib-amazon",
      "host": {}
    },
    {
      "name": "var-log-amazon",
      "host": {}
    }
  ],
  ...
}

Datadog Agent

Similarly, the Datadog Agent will not start if it doesn't have write permissions to certain directories. Additionally, to properly collect Fargate-specific metrics like ecs.fargate.cpu.usage, you must also set specific dockerLabels as confirmed by Datadog support.

{
  ...
  "containerDefinitions": [
    {
      ...
      "mountPoints": [
        {
          "sourceVolume": "dd-agent-etc-datadog-agent",
          "containerPath": "/etc/datadog-agent",
          "readOnly": false
        },
        {
          "sourceVolume": "dd-agent-opt-datadog-agent-run",
          "containerPath": "/opt/datadog-agent/run",
          "readOnly": false
        },
        {
          "sourceVolume": "dd-agent-var-run-datadog",
          "containerPath": "/var/run/datadog",
          "readOnly": false
        }
      ],
      ...
      "dockerLabels": {
        "com.datadoghq.ad.init_configs": "[{}]",
        "com.datadoghq.ad.instances": "[{}]",
        "com.datadoghq.ad.check_names": "[\"ecs_fargate\"]"
      },
      ...
    },
    ...
  ],
  ...
  "volumes": [
    {
      "name": "dd-agent-etc-datadog-agent",
      "host": {}
    },
    {
      "name": "dd-agent-opt-datadog-agent-run",
      "host": {}
    },
    {
      "name": "dd-agent-var-run-datadog",
      "host": {}
    }
  ],
  ...
}

Summary

Enabling ReadonlyRootFilesystem is a vital step for enhancing container security. However, it's crucial to be aware that some applications and features require specific directories to remain writable to function correctly.