Policy Templates for Amazon ECS
Amazon Elastic Container Services (ECS)
Policy Templates for CSPM are used with Amazon Elastic Container Service (ECS).
For instructions on how to find Policy templates that are new or updated due to changed recommendations, see Find New and Updated Policy Templates.
| Policy Name | Resource | Benchmark | PCI DSS | HIPAA | NIST 800-53 | Policy Description |
|---|---|---|---|---|---|---|
| ECS: HEALTHCHECK instruction should be added to the container image | ECS | CIS Level 1 | CM-3 | Add HEALTHCHECK instruction in your docker container images to perform the health check on running containers. | ||
| ECS: A daemon wide custom seccomp profile should be applied | ECS | CIS Level 2 | CM-3 | You can choose to apply your custom seccomp profile at the daemon-wide level if needed and override Docker's default seccomp profile. | ||
| ECS: Incoming container traffic should be binded to a specific host interface | ECS | CIS Level 1 | SC-4 | By default, Docker containers can make connections to the outside world, but the outside world cannot connect to containers. Each outgoing connection will appear to originate from one of the host machine's own IP addresses. Only allow container services to be contacted through a specific external interface on the host machine. | ||
| ECS: Centralized and remote logging should be configured | ECS | CIS Level 1 | CM-3 | Docker now supports various log drivers. A preferable way to store logs is the one that supports centralized and remote logging. | ||
| ECS: Container CPU priority should be set appropriately | ECS | CIS Level 1 | SC-6 | By default, all containers on a Docker host share the resources equally. By using the resource management capabilities of Docker host, such as CPU shares, you can control the host CPU resources that a container may consume. | ||
| ECS: Container sprawl should be avoided | ECS | CIS Level 1 | CM-3 | Do not keep a large number of containers on the same host. | ||
| ECS: Docker's default bridge networking mode should not be used | ECS | CIS Level 1 | CM-3 | Do not use Docker's default bridge docker0. Use docker's user-defined networks for container networking | ||
| ECS: Default seccomp profile should not be disabled | ECS | CIS Level 1 | CM-3 | Seccomp filtering provides a means for a process to specify a filter for incoming system calls. The default Docker seccomp profile works on whitelist basis and allows 311 system calls blocking all others. It should not be disabled unless it hinders your container application usage. | ||
| ECS: Host devices should not be exposed directly to containers | ECS | CIS Level 1 | SC-4 | Host devices can be directly exposed to containers at runtime. Do not directly expose host devices to containers especially for containers that are not trusted. | ||
| ECS: Host's IPC namespace should not be shared | ECS | CIS Level 1 | SC-4 | IPC (POSIX/SysV IPC) namespace provides separation of named shared memory segments, semaphores and message queues. IPC namespace on the host thus should not be shared with the containers and should remain isolated. | ||
| ECS: Memory usage for container should be limited | ECS | CIS Level 1 | SC-6 | By default, all containers on a Docker host share the resources equally. By using the resource management capabilities of Docker host, such as memory limit, you can control the amount of memory that a container may consume. | ||
| ECS: Docker socket should not be mounted inside any containers | ECS | CIS Level 1 | CM-3 | The docker socket (docker.sock) should not be mounted inside a container. Rationale: If the docker socket is mounted inside a container it would allow processes running within the container to execute docker commands which effectively allows for full control of the host. |
||
| ECS: A non-root user should be created for the container | ECS | CIS Level 1 | SC-2 | Create a non-root user for the container in the Dockerfile for the container image. | ||
| ECS: The 'on-failure' container restart policy should be set to 5 | ECS | CIS Level 1 | CM-3 | Using the '--restart' flag in 'docker run' command you can specify a restart policy for how a container should or should not be restarted on exit. You should choose the 'on-failure' restart policy and limit the restart attempts to 5. | ||
| ECS: PIDs cgroup limit should be used | ECS | CIS Level 1 | CM-3 | Use --pids-limit flag at container runtime | ||
| ECS: Host process namespace should not be shared | ECS | CIS Level 1 | SC-4 | Process ID (PID) namespaces isolate the process ID number space, meaning that processes in different PID namespaces can have the same PID. This is process level isolation between containers and the host. | ||
| ECS: Privileged ports should not be mapped within containers | ECS | CIS Level 1 | CM-3 | The TCP/IP port numbers below 1024 are considered privileged ports. Normal users and processes are not allowed to use them for various security reasons. Docker allows a container port to be mapped to a privileged port. | ||
| ECS: Privileged containers should not be used | ECS | CIS Level 1 | CM-3 | The --privileged flag gives all capabilities to the container, and it also lifts all the limitations enforced by the device cgroup controller. In other words, the container can then do almost everything that the host can do. This flag exists to allow special use-cases, like running Docker within Docker. | ||
| ECS: Container's file system should be mounted in read-only mode | ECS | CIS Level 1 | CM-3 | The container's root file system should be treated as a 'golden image' and any writes to the root filesystem should be avoided. You should explicitly define a container volume for writing. | ||
| ECS: Setuid and Setgid permissions should be removed in the images | ECS | CIS Level 1 | CM-3 | Removing setuid and setgid permissions in the images would prevent privilege escalation attacks in the containers. | ||
| ECS: Container should be restricted from acquiring additional permissions | ECS | CIS Level 1 | CM-3 | Restrict the container from acquiring additional permissions via suid or sgid bits. | ||
| ECS: Network traffic should be restricted between containers | ECS | CIS Level 1 | SC-7 | By default, all network traffic is allowed between containers on the same host. If not desired, restrict all the inter container communication. Link specific containers together that require inter communication. | ||
| ECS: Mount propagation mode should not be set to shared | ECS | CIS Level 1 | CM-3 | A shared mount is replicated at all mounts and the changes made at any mount point are propagated to all mounts. Mounting a volume in shared mode does not restrict any other container to mount and make changes to that volume. This might be catastrophic if the mounted volume is sensitive to changes. Do not set mount propagation mode to shared until needed. | ||
| ECS: Swarm mode should not be enabled | ECS | CIS Level 1 | CM-3 | Do not enable swarm mode on a docker engine instance unless needed. | ||
| ECS: Host's UTS namespace should not be shared | ECS | CIS Level 1 | SC-4 | UTS namespaces provide isolation of two system identifiers: the hostname and the NIS domain name. It is used for setting the hostname and the domain that is visible to running processes in that namespace. Processes running within containers do not typically require to know hostname and domain name. Hence, the namespace should not be shared with the host. | ||
| ECS: User namespace support should be enabled | ECS | CIS Level 1 | SC-2 | Enable user namespace support in Docker daemon to utilize container user to host user re-mapping. This recommendation is beneficial where containers you are using do not have an explicit container user defined in the container image. If container images that you are using have a pre-defined non-root user, this recommendation may be skipped since this feature is still in its infancy and might give you unpredictable issues and complexities. | ||
| ECS: Container health should be checked at runtime | ECS | CIS Level 1 | CM-3 | If the container image does not have an HEALTHCHECK instruction defined, use --health-cmd parameter at container runtime for checking container health. | ||
| ECS: Content Trust should be enabled For Docker | ECS | CIS Level 2 | CM-3 | By default, all containers on a Docker host share the resources equally. By using the resource management capabilities of Docker host, such as memory limit, you can control the amount of memory that a container may consume. | ||
| ECS: Sensitive host system directories should not be mounted on containers | ECS | CIS Level 2 | CM-3 | Sensitive host system directories such as below should not be allowed to be mounted as container volumes especially in read-write mode. | ||
| ECS: Linux Kernel Capabilities should be restricted within containers | ECS | CIS Level 2 | CM-3 | By default, Docker starts containers with a restricted set of Linux Kernel Capabilities. It means that any process may be granted the required capabilities instead of root access. Using Linux Kernel Capabilities, the processes do not have to run as root for almost all the specific areas where root permissions are usually needed. | ||
| ECS: SELinux security options should be verified | ECS | CIS Level 2 | CM-3 | SELinux is an effective and easy-to-use Linux application security system. It is available on quite a few Linux distributions by default such as Red Hat and Fedora. | ||
| ECS: Docker Version should be kept up to date | ECS | CIS Level 1 | CM-3 | Frequent releases for Docker are issued which address security vulnerabilities, resolve product bugs and bring in new functionality. You should keep a tab on these product updates and upgrade as frequently as possible in line with the general IT security policy of your organization. | ||
| ECS: Group container workloads onto hosts by sensitivity level | ECS | SC-3 | ||||
| ECS: Keeping containerized workloads isolated to container-specific hosts | ECS | SC-3 | ||||
| ECS: Use of secrets in docker image history or environmental variables | ECS | SI-14 | ||||
| ECS: Secret Manager should be used to manage secrets in a cluster | ECS | SI-14 | ||||
| ECS: Insecure Registry Connections Images/Containers Configuration Defects | SI-14 | |||||
| ECS Docker Host: AppArmor Profile should be enabled if applicable | ECS | CIS Level 1 | 164.312(b), 164.312(c)(2), 164.312(e)(2)(i) | CM-3, SC-39 | AppArmor is an effective and easy-to-use Linux application security system. It is available on some Linux distributions by default, for example, on Debian and Ubuntu. | |
| ECS Docker Host: COPY should be used instead of ADD in Dockerfiles | ECS | CIS Level 1 | CM-3, SC-39 | You should use the COPY instruction instead of the ADD instruction in the Dockerfile. | ||
| ECS Docker Host: Centralized and remote logging should be configured. | ECS | CIS Level 1 | 164.308(a)(1)(ii)(D) | CM-3, SC-39 | Docker supports various logging mechanisms. A preferable method for storing logs is one that supports centralized and remote management. | |
| ECS Docker Host: An user for the container should be created | ECS | CIS Level 1 | 164.308(a)(3)(i), 164.308(b)(1), 164.312(a)(1), 164.312(c)(1), 164.312(e)(1) | CM-3, SC-39 | Containers should run as a non-root user. | |
| ECS Docker Host: Docker Default seccomp profile should not be disabled | ECS | CIS Level 1 | 164.308(a)(3)(i), 164.308(b)(1), 164.312(a)(1), 164.312(c)(1), 164.312(e)(1) | CM-3, SC-39 | Seccomp filtering provides a means for a process to specify a filter for incoming system calls. The default Docker seccomp profile works on a whitelist basis and allows for a large number of common system calls, whilst blocking all others. This filtering should not be disabled unless it causes a problem with your container application usage. | |
| ECS Docker Host: Experimental features should not be implemented in production | ECS | CIS Level 1 | CM-3, SC-39 | Experimental is currently a runtime Docker daemon flag rather than being a feature of a separate build. Passing --experimental as a runtime flag to the docker daemon activates experimental features. Whilst Experimental is considered a stable release, it has a number of features which may not have been fully tested and do not guarantee API stability. | ||
| ECS Docker Host: Host's user namespaces should not be shared | ECS | CIS Level 1 | CM-3, SC-39 | User namespaces ensure that a root process inside the container will be mapped to a non-root process outside the container. Sharing the user namespaces of the host with the container does not therefore isolate users on the host from users in the containers. | ||
| ECS Docker Host: Insecure registries should not be used | ECS | CIS Level 1 | 164.308(a)(3)(i), 164.308(b)(1), 164.312(a)(1), 164.312(c)(1), 164.312(e)(1) | CM-3, SC-39 | Docker considers a private registry either secure or insecure. By default, registries are considered secure. | |
| ECS Docker Host: live restore should be enabled. | ECS | CIS Level 1 | CM-3, SC-39 | The --live-restore option enables full support of daemon-less containers within Docker. It ensures that Docker does not stop containers on shutdown or restore and that it properly reconnects to the container when restarted | ||
| ECS Docker Host: SELinux security options should be enabled if applicable | ECS | CIS Level 1 | 164.312(b), 164.312(c)(2), 164.312(e)(2)(i) | CM-3, SC-39 | SELinux is an effective and easy-to-use Linux application security system. It is available by default on some distributions such as Red Hat and Fedora. | |
| ECS Docker Host: TLS authentication should be configured for docker daemon | ECS | CIS Level 1 | 164.312(b), 164.312(c)(2), 164.312(e)(2)(i) | CM-3, SC-39 | It is possible to make the Docker daemon available remotely over a TCP port. If this is required, you should ensure that TLS authentication is configured in order to restrict access to the Docker daemon via IP address and port. | |
| ECS Docker Host: update instructions should not be use alone in the Dockerfile | ECS | CIS Level 1 | CM-3, SC-39 | You should not use OS package manager update instructions such as apt-get update or yum update either alone or in a single line in the Dockerfile. | ||
| ECS Docker Host: Userland Proxy should be disabled | ECS | CIS Level 1 | CM-3, SC-39 | The Docker daemon starts a userland proxy service for port forwarding whenever a port is exposed. Where hairpin NAT is available, this service is generally superfluous to requirements and can be disabled. | ||
| ECS Docker Host: aufs storage driver should not be used | ECS | CIS Level 1 | 164.312(b), 164.312(c)(2), 164.312(e)(2)(i) | CM-3, SC-39 | Docker considers a private registry either secure or insecure. By default, registries are considered secure. | |
| ECS Docker Host: Base device size should not be changed untill needed | ECS | CIS Level 1 | CM-3, SC-39 | Under certain circumstances, you might need containers larger than 10G. Where this applies you should carefully choose the base device size. | ||
| ECS Docker Host: cgroup usage should be confirmed | ECS | CIS Level 1 | 164.308(a)(3)(i), 164.308(b)(1), 164.312(a)(1), 164.312(c)(1), 164.312(e)(1) | CM-3, SC-39 | Seccomp filtering provides a means for a process to specify a filter for incoming system calls. The default Docker seccomp profile works on a whitelist basis and allows for a large number of common system calls, whilst blocking all others. This filtering should not be disabled unless it causes a problem with your container application usage. | |
| ECS Docker Host: A separate partition for containers should be created | ECS | CIS Level 1 | 164.312(b), 164.312(c)(2), 164.312(e)(2)(i) | CM-3, SC-39 | All Docker containers and their data and metadata is stored under /var/lib/docker directory. By default, /var/lib/docker should be mounted under either the / or /var partitions dependent on how the Linux operating system in use is configured. | |
| ECS Docker Host: cgroup usuage should be confirmed. | ECS | CIS Level 1 | CM-3, SC-39 | The --cgroup-parent option allows you to set the default cgroup parent to use for all containers. If there is no specific usage requirement for this, the setting should be left at its default. | ||
| ECS Docker Host: Default ulimit should be configured appropriately | ECS | CIS Level 1 | CM-3, SC-39 | Set the default ulimit options as appropriate in your environment. | ||
| ECS Docker Host: Authorization for Docker client commands should be enabled | ECS | CIS Level 1 | 164.308(a)(3)(i), 164.308(b)(1), 164.312(a)(1), 164.312(c)(1), 164.312(e)(1) | CM-3, SC-39 | You should use native Docker authorization plugins or a third party authorization mechanism with the Docker daemon to manage access to Docker client commands. | |
| ECS Docker Host: Docker Daemon json file permissions should be set to 644 or more restrictive | ECS | CIS Level 1 | 164.308(a)(3)(i), 164.308(b)(1), 164.312(a)(1), 164.312(c)(1), 164.312(e)(1) | CM-3, SC-39 | You should verify that the file permissions on the docker daemonfile are correctly set to 644 or more restrictively. | |
| ECS Docker Host: Daemon.json file ownership should set to root:root | ECS | CIS Level 1 | 164.308(a)(3)(i), 164.308(b)(1), 164.312(a)(1), 164.312(c)(1), 164.312(e)(1) | CM-3, SC-39 | You should verify that the daemon.json file individual ownership and group ownership is correctly set to root. | |
| ECS Docker Host: Version of Docker should be kept up to date | ECS | CIS Level 1 | 164.308(a)(3)(i), 164.308(b)(1), 164.312(a)(1), 164.312(c)(1), 164.312(e)(1) | CM-3, SC-39 | Frequent releases for Docker are issued which address security vulnerabilities, resolve product bugs and bring in new functionality. You should keep a tab on these product updates and upgrade as frequently as possible in line with the general IT security policy of your organization. | |
| ECS Docker Host: Docker.socket file permissions should be set to 644 or more restrictive | ECS | CIS Level 1 | 164.308(a)(3)(i), 164.308(b)(1), 164.312(a)(1), 164.312(c)(1), 164.312(e)(1) | CM-3, SC-39 | You should verify that the file permissions on the docker.socket file are correctly set to 644 or more restrictively. | |
| ECS Docker Host: docker.socket file ownership should be set to root | ECS | CIS Level 1 | 164.308(a)(3)(i), 164.308(b)(1), 164.312(a)(1), 164.312(c)(1), 164.312(e)(1) | CM-3, SC-39 | You should verify that the docker.socket file ownership and group ownership are correctly set to root. | |
| ECS Docker Host: Docker host socket should not be mounted inside any containers | ECS | CIS Level 1 | 164.308(a)(3)(i), 164.308(b)(1), 164.312(a)(1), 164.312(c)(1), 164.312(e)(1) | CM-3, SC-39 | The Docker socket docker.sock should not be mounted inside a container. | |
| ECS Docker Host: Docker's default bridge docker0 should not be used | ECS | CIS Level 1 | 164.308(a)(3)(i), 164.308(b)(1), 164.312(a)(1), 164.312(c)(1), 164.312(e)(1) | CM-3, SC-39 | You should not use Docker's default bridge docker0. Instead you should use Docker's user-defined networks for container networking. | |
| ECS Docker Host: Docker Host's IPC namespace should not be shared | ECS | CIS Level 1 | 164.308(a)(3)(i), 164.308(b)(1), 164.312(a)(1), 164.312(c)(1), 164.312(e)(1) | CM-3, SC-39 | IPC (POSIX/SysV IPC) namespace provides separation of named shared memory segments, semaphores and message queues. IPC namespace on the host thus should not be shared with the containers and should remain isolated. | |
| ECS Docker Host: Docker Host process namespace should not be shared | ECS | CIS Level 1 | 164.308(a)(3)(i), 164.308(b)(1), 164.312(a)(1), 164.312(c)(1), 164.312(e)(1) | CM-3, SC-39 | Process ID (PID) namespaces isolate the process ID number space, meaning that processes in different PID namespaces can have the same PID. This is process level isolation between containers and the host. | |
| ECS Docker Host: Network traffic should be restricted within containers | ECS | CIS Level 1 | 164.308(a)(3)(i), 164.308(b)(1), 164.312(a)(1), 164.312(c)(1), 164.312(e)(1) | CM-3, SC-39 | By default, all network traffic is allowed between containers on the same host on the default network bridge. If not desired, restrict all inter-container communication. Link specific containers together that require communication. Alternatively, you can create custom network and only join containers that need to communicate to that custom network. | |
| ECS Docker Host: IpTables should be allowed to be changed by Docker | ECS | CIS Level 1 | CM-3, SC-39 | The iptables firewall is used to set up, maintain, and inspect the tables of IP packet filter rules within the Linux kernel. The Docker daemon should be allowed to make changes to the iptables ruleset. | ||
| ECS Docker Host: Logging level should be set to info | ECS | CIS Level 1 | 164.308(a)(1)(ii)(D) | CM-3, SC-39 | Set Docker daemon log level to info. | |
| ECS Docker Host: trusted users should be allowed to control Docker daemon | ECS | CIS Level 1 | 164.308(a)(3)(i), 164.308(b)(1), 164.312(a)(1), 164.312(c)(1), 164.312(e)(1) | CM-3, SC-39 | The Docker daemon currently requires access to the Docker socket which is, by default, owned by the user root and the group docker. | |
| ECS Docker Host: CPU priority should be set appropriately on containers | ECS | CIS Level 2 | CM-3 | By default, all containers on a Docker host share resources equally. By using the resource management capabilities of the Docker host you can control the host CPU resources that a container may consume. | ||
| ECS Docker Host: Incoming container traffic should be bound to a specific host interface | ECS | CIS Level 2 | 164.308(a)(3)(i), 164.308(b)(1), 164.312(a)(1), 164.312(c)(1), 164.312(e)(1) | CM-3, SC-39 | By default, Docker containers can make connections to the outside world, but the outside world cannot connect to containers and each outgoing connection will appear to originate from one of the host machine's own IP addresses. You should only allow container services to be contacted through a specific external interface on the host machine.. | |
| ECS Docker Host: memory usage for containers should be limited | ECS | CIS Level 2 | CM-3, SC-39 | By default, all containers on a Docker host share resources equally. By using the resource management capabilities of the Docker host, you can control the amount of memory that a container is able to use.. | ||
| ECS Docker Host: The 'on-failure' container restart policy should be set to '5' | ECS | CIS Level 2 | CM-3, SC-39 | By using the --restart flag in the docker run command you can specify a restart policy for how a container should or should not be restarted on exit. You should choose the on-failure restart policy and limit the restart attempts to 5. | ||
| ECS Docker Host: container's root filesystem should be mounted as read only | ECS | CIS Level 2 | CM-3, SC-39 | The container's root filesystem should be treated as a 'golden image' by using Docker run's --read-only option. This prevents any writes to the container's root filesystem at container runtime and enforces the principle of immutable infrastructure. | ||
| ECS Docker Host: Docker host's network namespace should not be shared | ECS | CIS Level 2 | 164.308(a)(3)(i), 164.308(b)(1), 164.312(a)(1), 164.312(c)(1), 164.312(e)(1) | CM-3, SC-39 | When the networking mode on a container is set to --net=host, the container is not placed inside a separate network stack. Effectively, applying this option instructs Docker to not containerize the container's networking. The consequence of this is that the container lives outside" in the main Docker host and has full access to its network interfaces. " | |
| ECS Docker Host: host system directories should not be mounted on containers | ECS | CIS Level 2 | CM-3, SC-39 | You should not allow sensitive host system directories such as those listed below to be mounted as container volumes, especially in read-write mode. | ||
| ECS Docker Host: Docker Privileged ports should not be mapped within containers | ECS | CIS Level 2 | 164.308(a)(3)(i), 164.308(b)(1), 164.312(a)(1), 164.312(c)(1), 164.312(e)(1) | CM-3, SC-39 | The TCP/IP port numbers below 1024 are considered privileged ports. Normal users and processes are not allowed to use them for various security reasons. Docker does, however allow a container port to be mapped to a privileged port. |