Policy Templates for CSPM
- Last updated
- Save as PDF
Policy Templates for CSPM are used with:
- Amazon Elastic Container Service (ECS)
- Amazon Elastic Container Registry (ECR)
- Amazon Elastic Kubernetes Service (EKS)
- Google Container Registry (GCR)
- Google Kubernetes Engine (GKE)
- Azure Kubernetes Services (AKS)
- Azure Container Registry (ACR)
- AWS Fargate
For AWS, see Policy Templates for AWS.
Skyhigh CASB supports the CIS Kubernetes v1.23 Benchmark v1.0.0 - 02-04-2022 specification for auditing CSP-managed clusters.
For instructions on how to find Policy templates that are new or updated due to changed recommendations, see Find New and Updated Policy Templates.
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: 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 |
Content trust is disabled by default and should be enabled in line with organizational security policy. Content trust provides the ability to use digital signatures for data sent to and received from remote Docker registries. These signatures allow client-side verification of the identity and the publisher of specific image tags and ensures the provenance of container images. |
||
| 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. |
Amazon Elastic Container Registry (ECR)
Policy Templates for CSPM are used with Amazon Elastic Container Registry (ECR).
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 |
|---|---|---|---|---|---|---|
| ECR: Image Registry should not have more than 200 repositories | ECR | Yes | SC-6, Resource Availability | Image registry should have a limit on number of respositories | ||
| ECR: Users should not be granted FullAccess ECR Permission | ECR | Yes | 3.2.3 Insufficient authentication and authorization restrictions | Users should not be granted full Access ECR permissions | ||
| ECR: Repository should not allow unknown cross account access | ECR | Yes | SI-7, Software, Firmware, and Information Integrity. | Multiple accounts should not be involved in a repository policy | ||
| ECR: Repositories should not be exposed to everyone/ publicly for push actions | ECR | Yes | SI-7, Software, Firmware, and Information Integrity. | Repository policy push actions should be avoided | ||
| ECR: Repositories should not be exposed to everyone/ publicly for pull actions | ECR | Yes | SI-7, Software, Firmware, and Information Integrity. | Repository policy pull actions should be avoided | ||
| ECR: Repositories should not be exposed to everyone/ publicly for delete actions | ECR | Yes | SI-7, Software, Firmware, and Information Integrity. | Repository policy delete actions should be avoided | ||
| ECR: Image tag immutability should be set correctly for repository | ECR | Yes | SI-7, Software, Firmware, and Information Integrity. | Image Tag Immutability should be set correctly for repository |
Amazon Elastic Kubernetes Services (EKS)
The following Kubernetes policies apply to Amazon Elastic Kubernetes Service (EKS).
Skyhigh CASB supports the CIS Kubernetes v1.23 Benchmark v1.0.0 - 02-04-2022 specification for auditing CSP managed clusters.
For instructions on how to find new and updated templates on the Policy Templates page, see Find New and Updated Policy Templates.
| Policy Name | Resource | Benchmark | PCI DSS | HIPAA | NIST 800-53 | Policy Description |
|---|---|---|---|---|---|---|
| EKS: Argument AdvancedAuditing should not be set to false for API Server | EKS | CIS Level 1 | 10.1 10.2.2, 10.2.4, 10.2.5, 10.2.7 10.3.1, 10.3.2, 10.3.3, 10.3.4, 10.3.5, 10.3.6 | 164.308(a)(5)(ii)(C), 164.312(b), 164.312(c)(2), 164.312(e)(2)(i), 164.308(a)(1)(ii)(D) | CM-3 | AdvancedAuditing enables a much more general API auditing pipeline, which includes support for pluggable output backends and an audit policy specifying how different requests should be audited. Additionally, this enables auditing of failed authentication, authorization and login attempts which could prove crucial for protecting your production clusters. It is thus recommended not to disable advanced auditing |
| EKS: Admission control plugin AlwaysAdmit should not be set for API Server | EKS | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 6.5.8 7.2 | CM-3 | Setting admission control plugin AlwaysAdmit allows all requests and do not filter any requests. | |
| EKS: Admission control plugin AlwaysPullImages should be set for API Server | EKS | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 6.5.8 7.1 PCI_SSC_Cloud_guidelines_v3 | CM-3 | Setting admission control policy to AlwaysPullImages forces every new pod to pull the required images every time. In a multi-tenant cluster users can be assured that their private images can only be used by those who have the credentials to pull them. Without this admission control policy, once an image has been pulled to a node, any pod from any user can use it simply by knowing the image’s name, without any authorization check against the image ownership. When this plug-in is enabled, images are always pulled prior to starting containers, which means valid credentials are required. | |
| EKS: Argument anonymous-auth should be set to false for API Server | EKS | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 6.5.8 7.2 | 164.312(a)(1),164.308(a)(3)(i),164.308(b)(1), 164.312(c)(1), 164.312(e)(1) | CM-3 | When enabled, requests that are not rejected by other configured authentication methods are treated as anonymous requests. These requests are then served by the API server. You should rely on authentication to authorize access and disallow anonymous requests. |
| EKS: Argument audit-log-maxage should be set to 30 or as appropriate for API Server | EKS | CIS Level 1 | 10.7 | 164.308(a)(5)(ii)(C), 164.312(b), 164.312(c)(2), 164.312(e)(2)(i), 164.308(a)(1)(ii)(D) | CM-3 | Retaining logs for at least 30 days ensures that you can go back in time and investigate or correlate any events. Set your audit log retention period to 30 days or as per your business requirements. |
| EKS: Argument audit-log-maxbackup should be set to 10 or as appropriate for API Server | EKS | CIS Level 1 | 10.5.3 10.7 | 164.308(a)(5)(ii)(C), 164.312(b), 164.312(c)(2), 164.312(e)(2)(i), 164.308(a)(1)(ii)(D) | CM-3 | Kubernetes automatically rotates the log files. Retaining old log files ensures that you would have sufficient log data available for carrying out any investigation or correlation. For example, if you have set file size of 100 MB and the number of old log files to keep as 10, you would approximate have 1 GB of log data that you could potentially use for your analysis. |
| EKS: Argument audit-log-maxsize should be set to 100 or as appropriate for API Server | EKS | CIS Level 1 | 10.5.3 10.7 | 164.308(a)(5)(ii)(C), 164.312(b), 164.312(c)(2), 164.312(e)(2)(i), 164.308(a)(1)(ii)(D) | CM-3 | Kubernetes automatically rotates the log files. Retaining old log files ensures that you would have sufficient log data available for carrying out any investigation or correlation. If you have set file size of 100 MB and the number of old log files to keep as 10, you would approximate have 1 GB of log data that you could potentially use for your analysis. |
| EKS: Argument audit-log-path should be set as appropriate for API Server | EKS | CIS Level 1 | 10.1 10.2.2, 10.2.4, 10.2.5, 10.2.7 10.3.1, 10.3.2, 10.3.3, 10.3.4, 10.3.5, 10.3.6 | 164.308(a)(5)(ii)(C), 164.312(b), 164.312(c)(2), 164.312(e)(2)(i), 164.308(a)(1)(ii)(D) | CM-3 | Auditing the API Server provides a security-relevant chronological set of records documenting the sequence of activities that have affected system by individual users, administrators or other components of the system. Even though currently, Kubernetes provides only basic audit capabilities, it should be enabled. You can enable it by setting an appropriate audit log path. |
| EKS: Argument authorization-mode should not be set to AlwaysAllow for API Server | EKS | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 6.5.8 2.2.2 6.4.2 | 164.312(a)(1),164.308(a)(3)(i),164.308(b)(1), 164.312(c)(1), 164.312(e)(1) | CM-3 | The API Server, can be configured to allow all requests. This mode should not be used on any production cluster. |
| EKS: Argument authorization-mode should include Node for API Server | EKS | CIS Level 1 | 7.1 | 164.312(a)(1),164.308(a)(3)(i),164.308(b)(1), 164.312(c)(1), 164.312(e)(1) | CM-3 | The Node authorization mode only allows kubelets to read Secret, ConfigMap, PersistentVolume, and PersistentVolumeClaim objects associated with their nodes. |
| EKS: Argument authorization-mode should include RBAC for API Server | EKS | CIS Level 1 | 7.1 | 164.312(a)(1),164.308(a)(3)(i),164.308(b)(1), 164.312(c)(1), 164.312(e)(1) | CM-3 | Role Based Access Control (RBAC) allows fine-grained control over the operations that different entities can perform on different objects in the cluster. It is recommended to use the RBAC authorisation mode. |
| EKS: Argument basic-auth-file should not be set for API Server | EKS | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 6.5.3 | CM-3 | Basic authentication uses plaintext credentials for authentication. Currently, the basic authentication credentials last indefinitely, and the password cannot be changed without restarting API server. The basic authentication is currently supported for convenience. Hence, basic authentication should not be used. | |
| EKS: Argument client-ca-file should be set as appropriate for API Server | EKS | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 6.5.4 6.5.8 | 164.312(a)(1),164.308(a)(3)(i),164.308(b)(1), 164.312(c)(1), 164.312(e)(1) | CM-3 | API server communication contains sensitive parameters that should remain encrypted in transit. Configure the API server to serve only HTTPS traffic. If --client-ca-file argument is set, any request presenting a client certificate signed by one of the authorities in the client-ca-file is authenticated with an identity corresponding to the CommonName of the client certificate. |
| EKS: Argument encryption-provider-config should be set as appropriate for API Server | EKS | CIS Level 1 | 2.2 6.5.3 | 164.312(e)(2)(ii),164.312(e)(1),164.312(c)(1), 164.312(a)(2)(iv) | CM-3 | etcd is a highly available key-value store used by Kubernetes deployments for persistent storage of all of its REST API objects. These objects are sensitive in nature and should be encrypted at rest to avoid any disclosures. |
| EKS: Argument etcd-cafile should be set as appropriate for API Server | EKS | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 6.5.8 7.1 | 164.312(a)(1),164.308(a)(3)(i),164.308(b)(1), 164.312(c)(1), 164.312(e)(1) | CM-3 | etcd is a highly-available key value store used by Kubernetes deployments for persistent storage of all of its REST API objects. These objects are sensitive in nature and should be protected by client authentication. This requires the API server to identify itself to the etcd server using a SSL Certificate Authority file. |
| EKS: Arguments etcd-certfile and etcd-keyfile should be set as appropriate for API Server | EKS | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 6.5.8 7.1 PCI_SSC_Cloud_guidelines_v3 E.7 | 164.312(a)(1),164.308(a)(3)(i),164.308(b)(1), 164.312(c)(1), 164.312(e)(1) | CM-3 | etcd is a highly-available key value store used by Kubernetes deployments for persistent storage of all of its REST API objects. These objects are sensitive in nature and should be protected by client authentication. This requires the API server to identify itself to the etcd server using a client certificate and key |
| EKS: Admission control plugin EventRateLimit should be set for API Server | EKS | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 | 164.312(a)(2)(iii) | CM-3 | Using EventRateLimit admission control enforces a limit on the number of events that the API Server will accept in a given time slice. A misbehaving workload could overwhelm and DoS the API Server, making it unavailable. This particularly applies to a multi-tenant cluster, where there might be a small percentage of misbehaving tenants which could have a significant impact on the performance of the cluster overall. Hence, it is recommended to limit the rate of events that the API server will accept. |
| EKS: Argument insecure-bind-address should not be set for API Server | EKS | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 2.2.2 6.5.4 6.5.8 | 164.312(a)(1),164.308(a)(3)(i),164.308(b)(1), 164.312(c)(1), 164.312(e)(1) | CM-3 | If you bind the apiserver to an insecure address, basically anyone who could connect to it over the insecure port, would have unauthenticated and unencrypted access to your master node. The apiserver doesn't do any authentication checking for insecure binds and traffic to the Insecure API port is not encrpyted, allowing attackers to potentially read sensitive data in transit. |
| EKS: Argument insecure-port should be set to 0 for API Server | EKS | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 2.2.2 6.5.4 6.5.8 | 164.312(a)(1),164.308(a)(3)(i),164.308(b)(1), 164.312(c)(1), 164.312(e)(1) | CM-3 | Setting up the apiserver to serve on an insecure port would allow unauthenticated and unencrypted access to your master node. This would allow attackers who could access this port, to easily take control of the cluster. |
| EKS: Argument insecure-allow-any-token should not be set for API Server | EKS | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 6.5.4 10.5 | 164.312(a)(1),164.308(a)(3)(i),164.308(b)(1), 164.312(c)(1), 164.312(e)(1) | CM-3 | Accepting insecure tokens would allow any token without actually authenticating anything. User information is parsed from the token and connections are allowed. |
| EKS: Argument kubelet-certificate-authority should be set as appropriate for API Server | EKS | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 6.5.4 10.5 | 164.312(a)(1),164.308(a)(3)(i),164.308(b)(1), 164.312(c)(1), 164.312(e)(1) | CM-3 | The connections from the apiserver to the kubelet are used for fetching logs for pods, attaching (through kubectl) to running pods, and using the kubelet’s port-forwarding functionality. These connections terminate at the kubelet’s HTTPS endpoint. By default, the apiserver does not verify the kubelet’s serving certificate, which makes the connection subject to man-in-the-middle attacks, and unsafe to run over untrusted and/or public networks. |
| EKS: Arguments kubelet-client-certificate and kubelet-client-key should be set as appropriate for API Server | EKS | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 6.5.4 10.5 | 164.312(a)(1),164.308(a)(3)(i),164.308(b)(1), 164.312(c)(1), 164.312(e)(1) | CM-3 | The apiserver, by default, does not authenticate itself to the kubelet's HTTPS endpoints. The requests from the apiserver are treated anonymously. You should set up certificatebased kubelet authentication to ensure that the apiserver authenticates itself to kubelets when submitting requests. |
| EKS: Argument kubelet-https should be set to true for API Server | EKS | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 6.5.4 | 164.312(e)(2)(ii),164.312(e)(1),164.312(c)(1), 164.312(a)(2)(iv) | CM-3 | Connections from apiserver to kubelets could potentially carry sensitive data such as secrets and keys. It is thus important to use in-transit encryption for any communication between the apiserver and kubelets. |
| EKS: Admission control plugin NamespaceLifecycle should be set for API Server | EKS | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 PCI_SSC_Cloud_guidelines_v3 | CM-3 | Setting admission control policy to NamespaceLifecycle ensures that objects cannot be created in non-existent namespaces, and that namespaces undergoing termination are not used for creating the new objects. This is recommended to enforce the integrity of the namespace termination process and also for the availability of the newer objects | |
| EKS: Admission control plugin NodeRestriction should be set for API Server | EKS | CIS Level 1 | 7.1 | CM-3 | Using the NodeRestriction plug-in ensures that the kubelet is restricted to the Node and Pod objects that it could modify as defined. Such kubelets will only be allowed to modify their own Node API object, and only modify Pod API objects that are bound to their node. | |
| EKS: Admission control plugin PodSecurityPolicy should be set for API Server | EKS | CIS Level 1 | 1.2 | CM-3 | A Pod Security Policy is a cluster-level resource that controls the actions that a pod can perform and what it has the ability to access. The PodSecurityPolicy objects define a set of conditions that a pod must run with in order to be accepted into the system. Pod Security Policies are comprised of settings and strategies that control the security features a pod has access to and hence this must be used to control pod access permissions. | |
| EKS: Argument profiling should be set to false for API Server | EKS | CIS Level 1 | 7.1 7.2, 7.2.1, 7.2.2, 7.2.3 | CM-3 | Profiling allows for the identification of specific performance bottlenecks. It generates a significant amount of program data that could potentially be exploited to uncover system and program details. If you are not experiencing any bottlenecks and do not need the profiler for troubleshooting purposes, it is recommended to turn it off to reduce the potential attack surface. | |
| EKS: Argument repair-malformed-updates should be set to false for API Server | EKS | CIS Level 1 | 6.5.5 | CM-3 | The API Server will potentially attempt to fix the update requests to pass the validation even if the requests are malformed. Malformed requests are one of the potential ways to interact with a service without legitimate information. Such requests could potentially be used to sabotage API Server responses. | |
| EKS: Argument request-timeout should be set as appropriate for API Server | EKS | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 8.1.8 | 164.312(a)(2)(iii) | CM-3 | Kubernetes automatically rotates the log files. Retaining old log files ensures that you would have sufficient log data available for carrying out any investigation or correlation. If you have set file size of 100 MB and the number of old log files to keep as 10, you would approximate have 1 GB of log data that you could potentially use for your analysis. |
| EKS: Argument secure-port should not be set to 0 for API Server | EKS | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 6.5.4 6.5.8 | CM-3 | The secure port is used to serve https with authentication and authorization. If you disable it, no https traffic is served and all traffic is served unencrypted. | |
| EKS: Admission control plugin SecurityContextDeny should be set if PodSecurityPolicy is not used for API Server | EKS | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 PCI_SSC_Cloud_guidelines_v3 | CM-3 | SecurityContextDeny can be used to provide a layer of security for clusters which do not have PodSecurityPolicies enabled. | |
| EKS: Argument service-account-key-file should be set as appropriate for API Server | EKS | CIS Level 1 | 8.2.2 8.5 | CM-3 | By default, if no --service-account-key-file is specified to the apiserver, it uses the private key from the TLS serving certificate to verify service account tokens. To ensure that the keys for service account tokens could be rotated as needed, a separate public/private key pair should be used for signing service account tokens. Hence, the public key should be specified to the apiserver with --service-account-key-file. | |
| EKS: Argument service-account-lookup should be set to true for API Server | EKS | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 6.5.10 | CM-3 | If --service-account-lookup is not enabled, the apiserver only verifies that the authentication token is valid, and does not validate that the service account token mentioned in the request is actually present in etcd. This allows using a service account token even after the corresponding service account is deleted. This is an example of time of check to time of use security issue | |
| EKS: Admission control plugin ServiceAccount should be set for API Server | EKS | CIS Level 1 | 2.1 | CM-3 | When you create a pod, if you do not specify a service account, it is automatically assigned the default service account in the same namespace. You should create your own service account and let the API server manage its security tokens. | |
| EKS: Arguments tls-cert-file and tls-private-key-file should be set as appropriate for API Server | EKS | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 6.5.4 6.5.8 | 164.312(e)(2)(ii),164.312(e)(1),164.312(c)(1), 164.312(a)(2)(iv) | CM-3 | The connections from the apiserver to the kubelet are used for fetching logs for pods, attaching (through kubectl) to running pods, and using the kubelet’s port-forwarding functionality. These connections terminate at the kubelet’s HTTPS endpoint. By default, the apiserver does not verify the kubelet’s serving certificate, which makes the connection subject to man-in-the-middle attacks, and unsafe to run over untrusted and/or public networks. |
| EKS: API Server should only use Strong Cryptographic Ciphers | EKS | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 6.5.8 | 164.312(e)(2)(ii),164.312(e)(1),164.312(c)(1), 164.312(a)(2)(iv) | CM-3 | TLS ciphers have had a number of known vulnerabilities and weaknesses, which can reduce the protection provided by them. By default Kubernetes supports a number of TLS ciphersuites including some that have security concerns, weakening the protection provided. |
| EKS: Argument token-auth-file should not be set for API Server | EKS | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 6.5.3 8.2.1 | CM-3 | The token-based authentication utilizes static tokens to authenticate requests to the apiserver. The tokens are stored in clear-text in a file on the apiserver, and cannot be revoked or rotated without restarting the apiserver. Hence, do not use static token-based authentication. | |
| EKS: Argument address should be set to 127.0.0.1 for Controller Manager | EKS | CIS Level 1 | 7.1 7.2, 7.2.1, 7.2.2, 7.2.3 | CM-3 | The Controller Manager API service which runs on port 10252/TCP by default is used for health and metrics information and is available without authentication or encryption. As such it should only be bound to a localhost interface, to minimize the cluster's attack surface | |
| EKS: Argument profiling should be set to false for Controller Manager | EKS | CIS Level 1 | 7.1 7.2, 7.2.1, 7.2.2, 7.2.3 | CM-3 | Profiling allows for the identification of specific performance bottlenecks. It generates a significant amount of program data that could potentially be exploited to uncover system and program details. If you are not experiencing any bottlenecks and do not need the profiler for troubleshooting purposes, it is recommended to turn it off to reduce the potential attack surface. | |
| EKS: Argument root-ca-file should be set as appropriate for Controller Manager | EKS | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 6.5.4 6.5.8 | 164.312(a)(1),164.308(a)(3)(i),164.308(b)(1), 164.312(c)(1), 164.312(e)(1) | CM-3 | Processes running within pods that need to contact the API server must verify the API server's serving certificate. Failing to do so could be a subject to man-in-the-middle attacks. Providing the root certificate for the API server's serving certificate to the controller manager with the --root-ca-file argument allows the controller manager to inject the trusted bundle into pods so that they can verify TLS connections to the API server. |
| EKS: Argument RotateKubeletServerCertificate should be set to true for Controller Manager | EKS | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 6.5.4 6.5.8 | 164.312(a)(1),164.308(a)(3)(i),164.308(b)(1), 164.312(c)(1), 164.312(e)(1) | CM-3 | RotateKubeletServerCertificate causes the kubelet to both request a serving certificate after bootstrapping its client credentials and rotate the certificate as its existing credentials expire. This automated periodic rotation ensures that the there are no downtimes due to expired certificates and thus addressing availability in the CIA security triad. |
| EKS: Argument use-service-account-credentials should be set to true for Controller Manager | EKS | CIS Level 1 | 7.1 7.2, 7.2.1, 7.2.2, 7.2.3 | CM-3 | The controller manager creates a service account per controller in the kube-system namespace, generates a credential for it, and builds a dedicated API client with that service account credential for each controller loop to use. Setting the --use-service-accountcredentials to true runs each control loop within the controller manager using a separate service account credential. When used in combination with RBAC, this ensures that the control loops run with the minimum permissions required to perform their intended tasks. | |
| EKS: Argument service-account-private-key-file should be set as appropriate for Controller Manager | EKS | CIS Level 1 | 8.2.2 8.5 | CM-3 | To ensure that keys for service account tokens can be rotated as needed, a separate public/private key pair should be used for signing service account tokens. The private key should be specified to the controller manager with --service-account-private-key-file as appropriate. | |
| EKS: Argument terminated-pod-gc-threshold should be set as appropriate for Controller Manager | EKS | CIS Level 1 | 6.5.2 | 164.312(a)(2)(iii) | CM-3 | Garbage collection is important to ensure sufficient resource availability and avoiding degraded performance and availability. In the worst case, the system might crash or just be unusable for a long period of time. The current setting for garbage collection is 12,500 terminated pods which might be too high for your system to sustain. Based on your system resources and tests, choose an appropriate threshold value to activate garbage collection. |
| EKS: Argument address should be set to 127.0.0.1 for Scheduler | EKS | CIS Level 1 | 7.1 7.2, 7.2.1, 7.2.2, 7.2.3 | CM-3 | The Scheduler API service which runs on port 10251/TCP by default is used for health and metrics information and is available without authentication or encryption. As such it should only be bound to a localhost interface, to minimize the cluster's attack surface | |
| EKS: Argument profiling should be set to false for Scheduler | EKS | CIS Level 1 | 7.1 7.2, 7.2.1, 7.2.2, 7.2.3 | CM-3 | Profiling allows for the identification of specific performance bottlenecks. It generates a significant amount of program data that could potentially be exploited to uncover system and program details. If you are not experiencing any bottlenecks and do not need the profiler for troubleshooting purposes, it is recommended to turn it off to reduce the potential attack surface. | |
| EKS: Argument anonymous-auth should be set to false for Kubelet Server | EKS | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 6.5.8 7.2 | 164.312(a)(1),164.308(a)(3)(i),164.308(b)(1), 164.312(c)(1), 164.312(e)(1) | CM-3 | When enabled, requests that are not rejected by other configured authentication methods are treated as anonymous requests. These requests are then served by the Kubelet server. You should rely on authentication to authorize access and disallow anonymous requests. |
| EKS: Argument authorization-mode should not be set to AlwaysAllow for Kubelet Server | EKS | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 6.5.8 2.2.2 6.4.2 | 164.312(a)(1),164.308(a)(3)(i),164.308(b)(1), 164.312(c)(1), 164.312(e)(1) | CM_3 | Kubelets, by default, allow all authenticated requests (even anonymous ones) without needing explicit authorization checks from the apiserver. You should restrict this behavior and only allow explicitly authorized requests. |
| EKS: Argument client-ca-file should be set as appropriate for Kubelet Server | EKS | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 6.5.4 6.5.8 | 164.312(a)(1),164.308(a)(3)(i),164.308(b)(1), 164.312(c)(1), 164.312(e)(1) | CM-3 | The connections from the apiserver to the kubelet are used for fetching logs for pods, attaching (through kubectl) to running pods, and using the kubelet’s port-forwarding functionality. These connections terminate at the kubelet’s HTTPS endpoint. By default, the apiserver does not verify the kubelet’s serving certificate, which makes the connection subject to man-in-the-middle attacks, and unsafe to run over untrusted and/or public networks. Enabling Kubelet certificate authentication ensures that the apiserver could authenticate the Kubelet before submitting any requests. |
| EKS: Argument event-qps should be set to 0 or a level which ensures appropriate event capture for Kubelet Server | EKS | CIS Level 1 | 10.1 10.2.2, 10.2.4, 10.2.5, 10.2.7 10.3.1, 10.3.2, 10.3.3, 10.3.4, 10.3.5, 10.3.6 | 164.308(a)(5)(ii)(C), 164.312(b), 164.312(c)(2), 164.312(e)(2)(i), 164.308(a)(1)(ii)(D) | CM-3 | It is important to capture all events and not restrict event creation. Events are an important source of security information and analytics that ensure that your environment is consistently monitored using the event data. |
| EKS: Argument make-iptables-util-chains should be set to true for Kubelet Server | EKS | CIS Level 1 | 7.1 7.2, 7.2.1, 7.2.2, 7.2.3 | CM-3 | Kubelets can automatically manage the required changes to iptables based on how you choose your networking options for the pods. It is recommended to let kubelets manage the changes to iptables. This ensures that the iptables configuration remains in sync with pods networking configuration. Manually configuring iptables with dynamic pod network configuration changes might hamper the communication between pods/containers and to the outside world. You might have iptables rules too restrictive or too open. | |
| EKS: Argument protect-kernel-defaults should be set to true for Kubelet Server | EKS | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 | CM-3 | Kernel parameters are usually tuned and hardened by the system administrators before putting the systems into production. These parameters protect the kernel and the system. Your kubelet kernel defaults that rely on such parameters should be appropriately set to match the desired secured system state. Ignoring this could potentially lead to running pods with undesired kernel behavior | |
| EKS: Argument rotate-certificates should be set to true for Kubelet Server | EKS | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 8.2.4 | 164.312(a)(1),164.308(a)(3)(i),164.308(b)(1), 164.312(c)(1), 164.312(e)(1) | CM-3 | The --rotate-certificates setting causes the kubelet to rotate its client certificates by creating new CSRs as its existing credentials expire. This automated periodic rotation ensures that the there are no downtimes due to expired certificates and thus addressing availability in the CIA security triad. This recommendation only applies if you let kubelets get their certificates from the API server. In case your kubelet certificates come from an outside authority/tool (e.g. Vault) then you need to take care of rotation yourself |
| EKS: Argument RotateKubeletServerCertificate should be set to true for Kubelet Server | EKS | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 8.2.4 | 164.312(a)(1),164.308(a)(3)(i),164.308(b)(1), 164.312(c)(1), 164.312(e)(1) | CM-3 | RotateKubeletServerCertificate causes the kubelet to both request a serving certificate after bootstrapping its client credentials and rotate the certificate as its existing credentials expire. This automated periodic rotation ensures that the there are no downtimes due to expired certificates and thus addressing availability in the CIA security triad. This recommendation only applies if you let kubelets get their certificates from the API server. In case your kubelet certificates come from an outside authority/tool (e.g. Vault) then you need to take care of rotation yourself. |
| EKS: Argument streaming-connection-idle-timeout should not be set to 0 for Kubelet Server | EKS | CIS Level 1 | 8.1.8 | 164.312(a)(2)(iii) | CM-3 | Setting idle timeouts ensures that you are protected against Denial-of-Service attacks, inactive connections and running out of ephemeral ports. By default, --streaming-connection-idle-timeout is set to 4 hours which might be too high for your environment. Setting this as appropriate would additionally ensure that such streaming connections are timed out after serving legitimate use cases. |
| EKS: Arguments tls-cert-file and tls-private-key-file should be set as appropriate for Kubelet Server | EKS | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 6.5.4 6.5.8 | 164.312(e)(2)(ii),164.312(e)(1),164.312(c)(1), 164.312(a)(2)(iv) | CM-3 | Kubelet communication contains sensitive parameters that should remain encrypted in transit. Configure the Kubelets to serve only HTTPS traffic. |
| EKS: Kubelet should only use strong Cryptographic Ciphers | EKS | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 6.5.8 | 164.312(e)(2)(ii),164.312(e)(1),164.312(c)(1), 164.312(a)(2)(iv) | CM-3 | TLS ciphers have had a number of known vulnerabilities and weaknesses, which can reduce the protection provided by them. By default Kubernetes supports a number of TLS ciphersuites including some that have security concerns, weakening the protection provided. |
| EKS: Do not admit containers with allowPrivilegeEscalation in Pod Security Policies | EKS | CIS Level 1 | 1.2 2.2, 2.2.3, 2.2.4, 2.3 PCI_SSC_Cloud_guidelines_v3 E.7 | 164.312(a)(1),164.308(a)(3)(i),164.308(b)(1), 164.312(c)(1), 164.312(e)(1) | CM-3 | A container running with the allowPrivilegeEscalation flag set to true may have processes that can gain more privileges than their parent. There should be at least one admission control policy defined which does not permit containers to allow privilege escalation. The option exists (and is defaulted to true) to permit set uid binaries to run. If you have need to run containers which use set uid binaries or require privilege escalation, this should be defined in a separate policy and you should carefully check to ensure that only limited service accounts and users are given permission to use that policy. |
| EKS: Do not admit containers wishing to share the host IPC namespace in Pod Security Policies | EKS | CIS Level 1 | 1.2 2.2, 2.2.3, 2.2.4, 2.3 PCI_SSC_Cloud_guidelines_v3 E.7 | CM-3 | A container running in the host's IPC namespace can use IPC to interact with processes outside the container. There should be at least one admission control policy defined which does not permit containers to share the host IPC namespace. If you need to run containers which require hostIPC, this should be definited in a separate policy and you should carefully check to ensure that only limited service accounts and users are given permission to use that policy. | |
| EKS: Do not admit containers wishing to share the host network namespace in Pod Security Policies | EKS | CIS Level 1 | 1.2 2.2, 2.2.3, 2.2.4, 2.3 PCI_SSC_Cloud_guidelines_v3 E | 164.312(a)(1),164.308(a)(3)(i),164.308(b)(1), 164.312(c)(1), 164.312(e)(1) | CM-3 | A container running in the host's network namespace could access the local loopback device, and could access network traffic to and from other pods. There should be at least one admission control policy defined which does not permit containers to share the host network namespace. If you need to run containers which require access to the host's network namesapces, this should be defined in a separate policy and you should carefully check to ensure that only limited service accounts and users are given permission to use that policy. |
| EKS: Do not admit containers wishing to share the host process ID namespace in Pod Security Policies | EKS | CIS Level 1 | 1.2 2.2, 2.2.3, 2.2.4, 2.3 PCI_SSC_Cloud_guidelines_v3 E.7 | 164.312(a)(1),164.308(a)(3)(i),164.308(b)(1), 164.312(c)(1), 164.312(e)(1) | SC-4 | A container running in the host's PID namespace can inspect processes running outside the container. If the container also has access to ptrace capabilities this can be used to escalate privileges outside of the container. There should be at least one admission control policy defined which does not permit containers to share the host PID namespace. If you need to run containers which require hostPID, this should be defined in a separate policy and you should carefully check to ensure that only limited service accounts and users are given permission to use that policy. |
| EKS: Do not admit privileged containers in Pod Security Policies | EKS | CIS Level 1 | 1.2 2.2, 2.2.3, 2.2.4, 2.3 PCI_SSC_Cloud_guidelines_v3 E.7 | 164.312(a)(1),164.308(a)(3)(i),164.308(b)(1), 164.312(c)(1), 164.312(e)(1) | CM-3 | Privileged containers have access to all Linux Kernel capabilities and devices. A container running with full privileges can do almost everything that the host can do. This flag exists to allow special use-cases, like manipulating the network stack and accessing devices. There should be at least one admission control policy defined which does not permit privileged containers. If you need to run privileged containers, this should be defined in a separate policy and you should carefully check to ensure that only limited service accounts and users are given permission to use that policy. |
| EKS: Do not admit containers with NET_RAW capabilities in Pod Security Policies | EKS | CIS Level 1 | 1.2 2.2, 2.2.3, 2.2.4, 2.3 PCI_SSC_Cloud_guidelines_v3 E.7 | CM-3 | Containers run with a default set of capabilities as assigned by the Container Runtime. By default this can include potentially dangerous capabilities. With Docker as the container runtime the NET_RAW capability is enabled which may be misused by malicious containers. Ideally, all containers should drop this capability. There should be at least one admission control policy defined which does not permit containers with the NET_RAW capability. If you need to run containers with this capability, this should be defined in a separate policy and you should carefully check to ensure that only limited service accounts and users are given permission to use that policy. | |
| EKS: Do not generally permit containers to be run as the root user in Pod Security Policies | EKS | CIS Level 2 | 1.2 2.2, 2.2.3, 2.2.4, 2.3 PCI_SSC_Cloud_guidelines_v3 E.7 | 164.312(a)(1),164.308(a)(3)(i),164.308(b)(1), 164.312(c)(1), 164.312(e)(1) | CM-3 | Containers may run as any Linux user. Containers which run as the root user, whilst constrained by Container Runtime security features still have a escalated likelihood of container breakout. Ideally, all containers should run as a defined non-UID 0 user. There should be at least one admission control policy defined which does not permit root containers. If you need to run root containers, this should be defined in a separate policy and you should carefully check to ensure that only limited service accounts and users are given permission to use that policy. |
| EKS: Group container workloads onto hosts by sensitivity level | EKS | SC-3 | ||||
| EKS: Keeping containerized workloads isolated to container-specific hosts | EKS | SC-3 | ||||
| EKS: Enable control plane logging during EKS cluster creation | EKS | 10.1 10.2.2, 10.2.4, 10.2.5, 10.2.7 10.3.1, 10.3.2, 10.3.3, 10.3.4, 10.3.5, 10.3.6 | CM-3 | |||
| EKS Docker Host: COPY should be used instead of ADD in Dockerfiles in AWS EKS cluster hosts | EKS | CM-3, SC-39 | You should use the COPY instruction instead of the ADD instruction in the Dockerfile | |||
| EKS Docker Host: Centralized and remote logging should be configured in AWS EKS cluster hosts | EKS | 164.308(a)(1)(ii)(D) | CM-3 | Docker supports various logging mechanisms. A preferable method for storing logs is one that supports centralized and remote management. | ||
| EKS Docker Host: Docker Default seccomp profile should not be disabled in AWS EKS cluster hosts | EKS | 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. | ||
| EKS Docker Host: Experimental features should not be implemented in production in AWS EKS cluster hosts | EKS | 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. | |||
| EKS Docker Host: Host's user namespaces should not be shared in AWS EKS cluster hosts | EKS | 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. | |||
| EKS Docker Host: Incoming container traffic should be bound to a specific host interface in AWS EKS cluster hosts | EKS | 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. | ||
| EKS Docker Host: Insecure registries should not be used in AWS EKS cluster hosts | EKS | 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. | ||
| EKS Docker Host: Live restore should be enabled in AWS EKS cluster hosts | EKS | 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 | |||
| EKS Docker Host: Privileged containers should not be used in docker host in AWS EKS cluster hosts | EKS | 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 | Using the --privileged flag provides all Linux kernel capabilities to the container to which it is applied and therefore overwrites the --cap-add and --cap-drop flags. For this reason you should ensure that it is not used. | ||
| EKS Docker Host: Container health should be checked at runtime in AWS EKS cluster hosts | EKS | CM-3, SC-39 | If the container image does not have an HEALTHCHECK instruction defined, you should use the --health-cmd parameter at container runtime to check container health. | |||
| EKS Docker Host: Update instructions should not be use alone in the Dockerfile in AWS EKS cluster hosts | EKS | 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. | |||
| EKS Docker Host: User namespace support should be enabled for a container in AWS EKS cluster hosts | EKS | CM-3, SC-39 | You should enable user namespace support in Docker daemon to utilize container user to host user re-mapping. This recommendation is beneficial where the containers you are using do not have an explicit container user defined in the container image. If the container images that you are using have a pre-defined non-root user, this recommendation may be skipped as this feature is still in its infancy, and might result in unpredictable issues or difficulty in configuration. | |||
| EKS Docker Host: Userland Proxy should be disabled in AWS EKS cluster hosts | EKS | 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. | |||
| EKS Docker Host: Cgroup usage should be confirmed in AWS EKS cluster hosts | EKS | 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. | ||
| EKS Docker Host: Default cgroup usage should be confirmed in AWS EKS cluster hosts | EKS | 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 | |||
| EKS Docker Host: Default ulimit should be configured appropriately in AWS EKS cluster hosts | EKS | CM-3, SC-39 | Set the default ulimit options as appropriate in your environment. | |||
| EKS Docker Host: Authorization for Docker client commands should be enabled in AWS EKS cluster hosts | EKS | 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. | ||
| EKS Docker Host: Docker's default bridge docker0 should not be used in AWS EKS cluster hosts | EKS | 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. | ||
| EKS Docker Host: Network traffic should be restricted within containers in AWS EKS cluster hosts | EKS | 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. | ||
| EKS Docker Host: IpTables should be allowed to be changed by Docker in AWS EKS cluster hosts | EKS | 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. | |||
| EKS Docker Host: Docker Privileged ports should not be mapped within containers in AWS EKS cluster hosts | EKS | 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. | ||
| EKS: Do not generally permit containers with capabilities assigned beyond the default set in Pod Security Policies | EKS | CIS Level 1 | Containers run with a default set of capabilities as assigned by the Container Runtime. Capabilities outside this set can be added to containers which could expose them to risks of container breakout attacks. There should be at least one policy defined which prevents containers with capabilities beyond the default set from launching. If you need to run containers with additional capabilities, this should be defined in a separate policy and you should carefully check to ensure that only limited service accounts and users are given permission to use that policy. | |||
| EKS: Argument DenyServiceExternalIPs should not be set for API Server | EKSz | CIS Level 1 | This admission controller rejects all net-new usage of the Service field externalIPs. This feature is very powerful (allows network traffic interception) and not well controlled by policy. When enabled, users of the cluster may not create new Services which use externalIPs and may not add new values to externalIPs on existing Service objects. Existing uses of externalIPs are not affected, and users may remove values from externalIPs on existing Service objects.\nMost users do not need this feature at all, and cluster admins should consider disabling it. Clusters that do need to use this feature should consider using some custom policy to manage usage of it. | |||
| EKS Container Host: Version of Containerd should be kept up to date | EKS | CM-3, SC-39 | Frequent releases for Containerd 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. | |||
| EKS Container Host: A separate partition for containers should be created | EKS | 164.312(b), 164.312(c)(2), 164.312(e)(2)(i) | CM-3, SC-39 | All containers and their data and metadata is stored under /var/lib/containerd directory. By default, /var/lib/containerd should be mounted under either the / or /var partitions dependent on how the Linux operating system in use is configured. | ||
| EKS Container Host: Base device size should not be changed until needed | EKS | 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. | |||
| EKS Container Host: memory usage for containers should be limited | EKS | 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. | |||
| EKS Container Host: PIDs cgroup limit should be used | EKS | 164.312(a)(2)(iii) | CM-3, SC-39 | Attackers could launch a fork bomb with a single command inside the container. This fork bomb could crash the entire system and would require a restart of the host to make the system functional again. Using the PIDs cgroup parameter --pids-limit would prevent this kind of attack by restricting the number of forks that can happen inside a container within a specified time frame. | ||
| EKS Container Host: Container's root filesystem should be mounted as read only | EKS | 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. | |||
| EKS Container Host: TLS authentication should be configured for containerd daemon | EKS | 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. | ||
| EKS Container Host: An user for the container should be created | EKS | 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. | ||
| EKS Container Host: AppArmor Profile should be enabled if applicable | EKS | CIS Level 1 | 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. | |||
| EKS Container Host: CPU priority should be set appropriately on containers | EKS | CIS Level 2 | 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. | |||
| EKS Container Host: Containers should be restricted from acquiring additional previleges | EKS | 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, you should restrict containers from acquiring additional permissions via suid or sgid. | |
| EKS Container Host: Linux Kernel Capabilities should be restricted within containers | EKS | CIS Level 2 | CM-3, SC-39 | By default, the container starts 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. | ||
| EKS Container Host: SELinux security options should be enabled if applicable | EKS | 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. | |
| EKS Container Host: Aufs storage driver should not be used | EKS | CIS Level 1 | 164.312(b), 164.312(c)(2), 164.312(e)(2)(i) | CM-3, SC-39 | Do not use aufs as the storage driver for your Docker instance. | |
| EKS Container Host: Container Daemon json file permissions should be set to 644 or more restrictive | EKS | 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 daemon file are correctly set to 644 or more restrictively. | |
| EKS Container Host: Daemon.json file ownership should set to root:root | EKS | 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. | |
| EKS Container Host: Container .socket file permissions should be set to 644 or more restrictive | EKS | 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 container .socket file are correctly set to 644 or more restrictively. | |
| EKS Container Host: Container host socket should not be mounted inside any containers | EKS | 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 Container socket Container .sock should not be mounted inside a container. | |
| EKS Container Host: Container Host's IPC namespace should not be shared | EKS | 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. | |
| EKS Container Host: Container host's network namespace should not be shared | EKS | 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 Container host and has full access to its network interfaces. | |
| EKS Container Host: Container Host process namespace should not be shared | EKS | CIS Level 1 | 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. | |||
| EKS Container Host: host system directories should not be mounted on containers | EKS | 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. | ||
| EKS Container Host: Logging level should be set to info | EKS | CIS Level 1 | 164.308(a)(1)(ii)(D) | CM-3, SC-39 | Set Container daemon log level to info. | |
| EKS Container Host: Trusted users should be allowed to control container daemon | EKS | 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 Container daemon currently requires access to the container socket which is, by default, owned by the user root and the group container. | |
| EKS Container Host: Container .socket file ownership should be set to root | EKS | 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 container .socket file ownership and group ownership are correctly set to root | |
| EKS Container Host: UTS namespace should not be shared | EKS | CIS Level 1 | SC-4 | UTS namespaces provide isolation between two system identifiers: the hostname and the NIS domain name. It is used to set the hostname and the domain which are visible to running processes in that namespace. Processes running within containers do not typically require to know either the hostname or the domain name. The UTS namespace should therefore not be shared with the host. |
Google Container Registry (GCR)
Policy Templates for Container Security are used with Google Container Registry (GCR).
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 |
|---|---|---|---|---|---|---|
| GCR: Registries should not be exposed to everyone/ publicly for push actions | GCR | Yes | SC-6, Resource Availability | Registry push actions should not be allowed to everyone | ||
| GCR: Registries should not be exposed to everyone/ publicly for pull actions | GCR | Yes | SI-7, Software, Firmware, and Information Integrity. | Registry pull actions should not be allowed to everyone | ||
| GCR: Registries should not be exposed to everyone/ publicly for push actions | GCR | Yes | SI-7, Software, Firmware, and Information Integrity. | Registry push actions should not be allowed to everyone | ||
| GCR: Image Registry should not have more than 200 repositories | GCR | Yes | SC-6, Resource Availability | Image Registry should not have more than 200 repositories | ||
| GCR: Users should not be granted FullAccess GCR Permission | GCR | Yes | 3.2.3 Insufficient authentication and authorization restrictions | IAM Policies are not recommended to be associated with GCR Full Access Permissions |
Google Kubernetes Engine (GKE)
The following Kubernetes policies apply to Google Kubernetes Engine (GKE).
Skyhigh CASB supports the CIS Kubernetes v1.23 Benchmark v1.0.0 - 02-04-2022 specification for auditing CSP managed clusters.
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 |
|---|---|---|---|---|---|---|
| GKE: Argument AdvancedAuditing should not be set to false for API Server | GKE | CIS Level 1 | 10.1 10.2.2, 10.2.4, 10.2.5, 10.2.7 10.3.1, 10.3.2, 10.3.3, 10.3.4, 10.3.5, 10.3.6 | 164.308(a)(5)(ii)(C), 164.312(b), 164.312(c)(2), 164.312(e)(2)(i), 164.308(a)(1)(ii)(D) | CM-3 | AdvancedAuditing enables a much more general API auditing pipeline, which includes support for pluggable output backends and an audit policy specifying how different requests should be audited. Additionally, this enables auditing of failed authentication, authorization and login attempts which could prove crucial for protecting your production clusters. It is thus recommended not to disable advanced auditing |
| GKE: Admission control plugin AlwaysAdmit should not be set for API Server | GKE | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 6.5.8 7.2 | CM-3 | Setting admission control plugin AlwaysAdmit allows all requests and do not filter any requests. | |
| GKE: Admission control plugin AlwaysPullImages should be set for API Server | GKE | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 6.5.8 7.1 PCI_SSC_Cloud_guidelines_v3 | CM-3 | Setting admission control policy to AlwaysPullImages forces every new pod to pull the required images every time. In a multi-tenant cluster users can be assured that their private images can only be used by those who have the credentials to pull them. Without this admission control policy, once an image has been pulled to a node, any pod from any user can use it simply by knowing the image’s name, without any authorization check against the image ownership. When this plug-in is enabled, images are always pulled prior to starting containers, which means valid credentials are required. | |
| GKE: Argument anonymous-auth should be set to false for API Server | GKE | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 6.5.8 7.2 | 164.312(a)(1),164.308(a)(3)(i),164.308(b)(1), 164.312(c)(1), 164.312(e)(1) | CM-3 | When enabled, requests that are not rejected by other configured authentication methods are treated as anonymous requests. These requests are then served by the API server. You should rely on authentication to authorize access and disallow anonymous requests. |
| GKE: Argument audit-log-maxage should be set to 30 or as appropriate for API Server | GKE | CIS Level 1 | 10.7 | 164.308(a)(5)(ii)(C), 164.312(b), 164.312(c)(2), 164.312(e)(2)(i), 164.308(a)(1)(ii)(D) | CM-3 | Retaining logs for at least 30 days ensures that you can go back in time and investigate or correlate any events. Set your audit log retention period to 30 days or as per your business requirements. |
| GKE: Argument audit-log-maxbackup should be set to 10 or as appropriate for API Server | GKE | CIS Level 1 | 10.5.3 10.7 | 164.308(a)(5)(ii)(C), 164.312(b), 164.312(c)(2), 164.312(e)(2)(i), 164.308(a)(1)(ii)(D) | CM-3 | Kubernetes automatically rotates the log files. Retaining old log files ensures that you would have sufficient log data available for carrying out any investigation or correlation. For example, if you have set file size of 100 MB and the number of old log files to keep as 10, you would approximate have 1 GB of log data that you could potentially use for your analysis. |
| GKE: Argument audit-log-maxsize should be set to 100 or as appropriate for API Server | GKE | CIS Level 1 | 10.5.3 10.7 | 164.308(a)(5)(ii)(C), 164.312(b), 164.312(c)(2), 164.312(e)(2)(i), 164.308(a)(1)(ii)(D) | CM-3 | Kubernetes automatically rotates the log files. Retaining old log files ensures that you would have sufficient log data available for carrying out any investigation or correlation. If you have set file size of 100 MB and the number of old log files to keep as 10, you would approximate have 1 GB of log data that you could potentially use for your analysis. |
| GKE: Argument audit-log-path should be set as appropriate for API Server | GKE | CIS Level 1 | 10.1 10.2.2, 10.2.4, 10.2.5, 10.2.7 10.3.1, 10.3.2, 10.3.3, 10.3.4, 10.3.5, 10.3.6 | 164.308(a)(5)(ii)(C), 164.312(b), 164.312(c)(2), 164.312(e)(2)(i), 164.308(a)(1)(ii)(D) | CM-3 | Auditing the API Server provides a security-relevant chronological set of records documenting the sequence of activities that have affected system by individual users, administrators or other components of the system. Even though currently, Kubernetes provides only basic audit capabilities, it should be enabled. You can enable it by setting an appropriate audit log path. |
| GKE: Argument authorization-mode should not be set to AlwaysAllow for API Server | GKE | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 6.5.8 2.2.2 6.4.2 | 164.312(a)(1),164.308(a)(3)(i),164.308(b)(1), 164.312(c)(1), 164.312(e)(1) | CM-3 | The API Server, can be configured to allow all requests. This mode should not be used on any production cluster. |
| GKE: Argument authorization-mode should include Node for API Server | GKE | CIS Level 1 | 7.1 | 164.312(a)(1),164.308(a)(3)(i),164.308(b)(1), 164.312(c)(1), 164.312(e)(1) | CM-3 | The Node authorization mode only allows kubelets to read Secret, ConfigMap, PersistentVolume, and PersistentVolumeClaim objects associated with their nodes. |
| GKE: Argument authorization-mode should include RBAC for API Server | GKE | CIS Level 1 | 7.1 | 164.312(a)(1),164.308(a)(3)(i),164.308(b)(1), 164.312(c)(1), 164.312(e)(1) | CM-3 | Role Based Access Control (RBAC) allows fine-grained control over the operations that different entities can perform on different objects in the cluster. It is recommended to use the RBAC authorisation mode. |
| GKE: Argument basic-auth-file should not be set for API Server | GKE | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 6.5.3 | CM-3 | Basic authentication uses plaintext credentials for authentication. Currently, the basic authentication credentials last indefinitely, and the password cannot be changed without restarting API server. The basic authentication is currently supported for convenience. Hence, basic authentication should not be used. | |
| GKE: Argument client-ca-file should be set as appropriate for API Server | GKE | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 6.5.4 6.5.8 | 164.312(a)(1),164.308(a)(3)(i),164.308(b)(1), 164.312(c)(1), 164.312(e)(1) | CM-3 | API server communication contains sensitive parameters that should remain encrypted in transit. Configure the API server to serve only HTTPS traffic. If --client-ca-file argument is set, any request presenting a client certificate signed by one of the authorities in the client-ca-file is authenticated with an identity corresponding to the CommonName of the client certificate. |
| GKE: Argument encryption-provider-config should be set as appropriate for API Server | GKE | CIS Level 1 | 2.2 6.5.3 | 164.312(e)(2)(ii),164.312(e)(1),164.312(c)(1), 164.312(a)(2)(iv) | CM-3 | etcd is a highly available key-value store used by Kubernetes deployments for persistent storage of all of its REST API objects. These objects are sensitive in nature and should be encrypted at rest to avoid any disclosures. |
| GKE: Argument etcd-cafile should be set as appropriate for API Server | GKE | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 6.5.8 7.1 | 164.312(a)(1),164.308(a)(3)(i),164.308(b)(1), 164.312(c)(1), 164.312(e)(1) | CM-3 | etcd is a highly-available key value store used by Kubernetes deployments for persistent storage of all of its REST API objects. These objects are sensitive in nature and should be protected by client authentication. This requires the API server to identify itself to the etcd server using a SSL Certificate Authority file. |
| GKE: Arguments etcd-certfile and etcd-keyfile should be set as appropriate for API Server | GKE | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 6.5.8 7.1 PCI_SSC_Cloud_guidelines_v3 E.7 | 164.312(a)(1),164.308(a)(3)(i),164.308(b)(1), 164.312(c)(1), 164.312(e)(1) | CM-3 | etcd is a highly-available key value store used by Kubernetes deployments for persistent storage of all of its REST API objects. These objects are sensitive in nature and should be protected by client authentication. This requires the API server to identify itself to the etcd server using a client certificate and key |
| GKE: Admission control plugin EventRateLimit should be set for API Server | GKE | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 | 164.312(a)(2)(iii) | CM-3 | Using EventRateLimit admission control enforces a limit on the number of events that the API Server will accept in a given time slice. A misbehaving workload could overwhelm and DoS the API Server, making it unavailable. This particularly applies to a multi-tenant cluster, where there might be a small percentage of misbehaving tenants which could have a significant impact on the performance of the cluster overall. Hence, it is recommended to limit the rate of events that the API server will accept. |
| GKE: Argument insecure-bind-address should not be set for API Server | GKE | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 2.2.2 6.5.4 6.5.8 | 164.312(a)(1),164.308(a)(3)(i),164.308(b)(1), 164.312(c)(1), 164.312(e)(1) | CM-3 | If you bind the apiserver to an insecure address, basically anyone who could connect to it over the insecure port, would have unauthenticated and unencrypted access to your master node. The apiserver doesn't do any authentication checking for insecure binds and traffic to the Insecure API port is not encrpyted, allowing attackers to potentially read sensitive data in transit. |
| GKE: Argument insecure-port should be set to 0 for API Server | GKE | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 2.2.2 6.5.4 6.5.8 | 164.312(a)(1),164.308(a)(3)(i),164.308(b)(1), 164.312(c)(1), 164.312(e)(1) | CM-3 | Setting up the apiserver to serve on an insecure port would allow unauthenticated and unencrypted access to your master node. This would allow attackers who could access this port, to easily take control of the cluster. |
| GKE: Argument insecure-allow-any-token should not be set for API Server | GKE | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 6.5.4 10.5 | 164.312(a)(1),164.308(a)(3)(i),164.308(b)(1), 164.312(c)(1), 164.312(e)(1) | CM-3 | Accepting insecure tokens would allow any token without actually authenticating anything. User information is parsed from the token and connections are allowed. |
| GKE: Argument kubelet-certificate-authority should be set as appropriate for API Server | GKE | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 6.5.4 10.5 | 164.312(a)(1),164.308(a)(3)(i),164.308(b)(1), 164.312(c)(1), 164.312(e)(1) | CM-3 | The connections from the apiserver to the kubelet are used for fetching logs for pods, attaching (through kubectl) to running pods, and using the kubelet’s port-forwarding functionality. These connections terminate at the kubelet’s HTTPS endpoint. By default, the apiserver does not verify the kubelet’s serving certificate, which makes the connection subject to man-in-the-middle attacks, and unsafe to run over untrusted and/or public networks. |
| GKE: Arguments kubelet-client-certificate and kubelet-client-key should be set as appropriate for API Server | GKE: | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 6.5.4 10.5 | 164.312(a)(1),164.308(a)(3)(i),164.308(b)(1), 164.312(c)(1), 164.312(e)(1) | CM-3 | The apiserver, by default, does not authenticate itself to the kubelet's HTTPS endpoints. The requests from the apiserver are treated anonymously. You should set up certificatebased kubelet authentication to ensure that the apiserver authenticates itself to kubelets when submitting requests. |
| GKE: Argument kubelet-https should be set to true for API Server | GKE | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 6.5.4 | 164.312(e)(2)(ii),164.312(e)(1),164.312(c)(1), 164.312(a)(2)(iv) | CM-3 | Connections from apiserver to kubelets could potentially carry sensitive data such as secrets and keys. It is thus important to use in-transit encryption for any communication between the apiserver and kubelets. |
| GKE: Admission control plugin NamespaceLifecycle should be set for API Server | GKE | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 PCI_SSC_Cloud_guidelines_v3 | CM-3 | Setting admission control policy to NamespaceLifecycle ensures that objects cannot be created in non-existent namespaces, and that namespaces undergoing termination are not used for creating the new objects. This is recommended to enforce the integrity of the namespace termination process and also for the availability of the newer objects | |
| GKE: Admission control plugin NodeRestriction should be set for API Server | GKE | CIS Level 1 | 7.1 | CM-3 | Using the NodeRestriction plug-in ensures that the kubelet is restricted to the Node and Pod objects that it could modify as defined. Such kubelets will only be allowed to modify their own Node API object, and only modify Pod API objects that are bound to their node. | |
| GKE: Admission control plugin PodSecurityPolicy should be set for API Server | GKE | CIS Level 1 | 1.2 | CM-3 | A Pod Security Policy is a cluster-level resource that controls the actions that a pod can perform and what it has the ability to access. The PodSecurityPolicy objects define a set of conditions that a pod must run with in order to be accepted into the system. Pod Security Policies are comprised of settings and strategies that control the security features a pod has access to and hence this must be used to control pod access permissions. | |
| GKE: Argument profiling should be set to false for API Server | GKE | CIS Level 1 | 7.1 7.2, 7.2.1, 7.2.2, 7.2.3 | CM-3 | Profiling allows for the identification of specific performance bottlenecks. It generates a significant amount of program data that could potentially be exploited to uncover system and program details. If you are not experiencing any bottlenecks and do not need the profiler for troubleshooting purposes, it is recommended to turn it off to reduce the potential attack surface. | |
| GKE: Argument repair-malformed-updates should be set to false for API Server | GKE | CIS Level 1 | 6.5.5 | CM-3 | The API Server will potentially attempt to fix the update requests to pass the validation even if the requests are malformed. Malformed requests are one of the potential ways to interact with a service without legitimate information. Such requests could potentially be used to sabotage API Server responses. | |
| GKE: Argument request-timeout should be set as appropriate for API Server | GKE | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 8.1.8 | 164.312(a)(2)(iii) | CM-3 | Kubernetes automatically rotates the log files. Retaining old log files ensures that you would have sufficient log data available for carrying out any investigation or correlation. If you have set file size of 100 MB and the number of old log files to keep as 10, you would approximate have 1 GB of log data that you could potentially use for your analysis. |
| GKE: Argument secure-port should not be set to 0 for API Server | GKE | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 6.5.4 6.5.8 | CM-3 | The secure port is used to serve https with authentication and authorization. If you disable it, no https traffic is served and all traffic is served unencrypted. | |
| GKE: Admission control plugin SecurityContextDeny should be set if PodSecurityPolicy is not used for API Server | GKE | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 PCI_SSC_Cloud_guidelines_v3 | CM-3 | SecurityContextDeny can be used to provide a layer of security for clusters which do not have PodSecurityPolicies enabled. | |
| GKE: Argument service-account-key-file should be set as appropriate for API Server | GKE | CIS Level 1 | 8.2.2 8.5 | CM-3 | By default, if no --service-account-key-file is specified to the apiserver, it uses the private key from the TLS serving certificate to verify service account tokens. To ensure that the keys for service account tokens could be rotated as needed, a separate public/private key pair should be used for signing service account tokens. Hence, the public key should be specified to the apiserver with --service-account-key-file. | |
| GKE: Argument service-account-lookup should be set to true for API Server | GKE: | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 6.5.10 | CM-3 | If --service-account-lookup is not enabled, the apiserver only verifies that the authentication token is valid, and does not validate that the service account token mentioned in the request is actually present in etcd. This allows using a service account token even after the corresponding service account is deleted. This is an example of time of check to time of use security issue | |
| GKE: Admission control plugin ServiceAccount should be set for API Server | GKE | CIS Level 1 | 2.1 | CM-3 | When you create a pod, if you do not specify a service account, it is automatically assigned the default service account in the same namespace. You should create your own service account and let the API server manage its security tokens. | |
| GKE: Arguments tls-cert-file and tls-private-key-file should be set as appropriate for API Server | GKE | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 6.5.4 6.5.8 | 164.312(e)(2)(ii),164.312(e)(1),164.312(c)(1), 164.312(a)(2)(iv) | CM-3 | The connections from the apiserver to the kubelet are used for fetching logs for pods, attaching (through kubectl) to running pods, and using the kubelet’s port-forwarding functionality. These connections terminate at the kubelet’s HTTPS endpoint. By default, the apiserver does not verify the kubelet’s serving certificate, which makes the connection subject to man-in-the-middle attacks, and unsafe to run over untrusted and/or public networks. |
| GKE: API Server should only use Strong Cryptographic Ciphers | GKE | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 6.5.8 | 164.312(e)(2)(ii),164.312(e)(1),164.312(c)(1), 164.312(a)(2)(iv) | CM-3 | TLS ciphers have had a number of known vulnerabilities and weaknesses, which can reduce the protection provided by them. By default Kubernetes supports a number of TLS ciphersuites including some that have security concerns, weakening the protection provided. |
| GKE: Argument token-auth-file should not be set for API Server | GKE | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 6.5.3 8.2.1 | CM-3 | The token-based authentication utilizes static tokens to authenticate requests to the apiserver. The tokens are stored in clear-text in a file on the apiserver, and cannot be revoked or rotated without restarting the apiserver. Hence, do not use static token-based authentication. | |
| GKE: Argument address should be set to 127.0.0.1 for Controller Manager | GKE | CIS Level 1 | 7.1 7.2, 7.2.1, 7.2.2, 7.2.3 | CM-3 | The Controller Manager API service which runs on port 10252/TCP by default is used for health and metrics information and is available without authentication or encryption. As such it should only be bound to a localhost interface, to minimize the cluster's attack surface | |
| GKE: Argument profiling should be set to false for Controller Manager | GKE | CIS Level 1 | 7.1 7.2, 7.2.1, 7.2.2, 7.2.3 | CM-3 | Profiling allows for the identification of specific performance bottlenecks. It generates a significant amount of program data that could potentially be exploited to uncover system and program details. If you are not experiencing any bottlenecks and do not need the profiler for troubleshooting purposes, it is recommended to turn it off to reduce the potential attack surface. | |
| GKE: Argument root-ca-file should be set as appropriate for Controller Manager | GKE | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 6.5.4 6.5.8 | 164.312(a)(1),164.308(a)(3)(i),164.308(b)(1), 164.312(c)(1), 164.312(e)(1) | CM-3 | Processes running within pods that need to contact the API server must verify the API server's serving certificate. Failing to do so could be a subject to man-in-the-middle attacks. Providing the root certificate for the API server's serving certificate to the controller manager with the --root-ca-file argument allows the controller manager to inject the trusted bundle into pods so that they can verify TLS connections to the API server. |
| GKE: Argument RotateKubeletServerCertificate should be set to true for Controller Manager | GKE | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 6.5.4 6.5.8 | 164.312(a)(1),164.308(a)(3)(i),164.308(b)(1), 164.312(c)(1), 164.312(e)(1) | CM-3 | RotateKubeletServerCertificate causes the kubelet to both request a serving certificate after bootstrapping its client credentials and rotate the certificate as its existing credentials expire. This automated periodic rotation ensures that the there are no downtimes due to expired certificates and thus addressing availability in the CIA security triad. |
| GKE: Argument use-service-account-credentials should be set to true for Controller Manager | GKE | CIS Level 1 | 7.1 7.2, 7.2.1, 7.2.2, 7.2.3 | CM-3 | The controller manager creates a service account per controller in the kube-system namespace, generates a credential for it, and builds a dedicated API client with that service account credential for each controller loop to use. Setting the --use-service-accountcredentials to true runs each control loop within the controller manager using a separate service account credential. When used in combination with RBAC, this ensures that the control loops run with the minimum permissions required to perform their intended tasks. | |
| GKE: Argument service-account-private-key-file should be set as appropriate for Controller Manager | GKE | CIS Level 1 | 8.2.2 8.5 | CM-3 | To ensure that keys for service account tokens can be rotated as needed, a separate public/private key pair should be used for signing service account tokens. The private key should be specified to the controller manager with --service-account-private-key-file as appropriate. | |
| GKE: Argument terminated-pod-gc-threshold should be set as appropriate for Controller Manager | GKE | CIS Level 1 | 6.5.2 | 164.312(a)(2)(iii) | CM-3 | Garbage collection is important to ensure sufficient resource availability and avoiding degraded performance and availability. In the worst case, the system might crash or just be unusable for a long period of time. The current setting for garbage collection is 12,500 terminated pods which might be too high for your system to sustain. Based on your system resources and tests, choose an appropriate threshold value to activate garbage collection. |
| GKE: Argument address should be set to 127.0.0.1 for Scheduler | GKE | CIS Level 1 | 7.1 7.2, 7.2.1, 7.2.2, 7.2.3 | CM-3 | The Scheduler API service which runs on port 10251/TCP by default is used for health and metrics information and is available without authentication or encryption. As such it should only be bound to a localhost interface, to minimize the cluster's attack surface | |
| GKE: Argument profiling should be set to false for Scheduler | GKE | CIS Level 1 | 7.1 7.2, 7.2.1, 7.2.2, 7.2.3 | CM-3 | Profiling allows for the identification of specific performance bottlenecks. It generates a significant amount of program data that could potentially be exploited to uncover system and program details. If you are not experiencing any bottlenecks and do not need the profiler for troubleshooting purposes, it is recommended to turn it off to reduce the potential attack surface. | |
| GKE: Argument anonymous-auth should be set to false for Kubelet Server | GKE | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 6.5.8 7.2 | 164.312(a)(1),164.308(a)(3)(i),164.308(b)(1), 164.312(c)(1), 164.312(e)(1) | CM-3 | When enabled, requests that are not rejected by other configured authentication methods are treated as anonymous requests. These requests are then served by the Kubelet server. You should rely on authentication to authorize access and disallow anonymous requests. |
| GKE: Argument authorization-mode should not be set to AlwaysAllow for Kubelet Server | GKE | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 6.5.8 2.2.2 6.4.2 | 164.312(a)(1),164.308(a)(3)(i),164.308(b)(1), 164.312(c)(1), 164.312(e)(1) | CM_3 | Kubelets, by default, allow all authenticated requests (even anonymous ones) without needing explicit authorization checks from the apiserver. You should restrict this behavior and only allow explicitly authorized requests. |
| GKE: Argument client-ca-file should be set as appropriate for Kubelet Server | GKE | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 6.5.4 6.5.8 | 164.312(a)(1),164.308(a)(3)(i),164.308(b)(1), 164.312(c)(1), 164.312(e)(1) | CM-3 | The connections from the apiserver to the kubelet are used for fetching logs for pods, attaching (through kubectl) to running pods, and using the kubelet’s port-forwarding functionality. These connections terminate at the kubelet’s HTTPS endpoint. By default, the apiserver does not verify the kubelet’s serving certificate, which makes the connection subject to man-in-the-middle attacks, and unsafe to run over untrusted and/or public networks. Enabling Kubelet certificate authentication ensures that the apiserver could authenticate the Kubelet before submitting any requests. |
| GKE: Argument event-qps should be set to 0 or a level which ensures appropriate event capture for Kubelet Server | GKE | CIS Level 1 | 10.1 10.2.2, 10.2.4, 10.2.5, 10.2.7 10.3.1, 10.3.2, 10.3.3, 10.3.4, 10.3.5, 10.3.6 | 164.308(a)(5)(ii)(C), 164.312(b), 164.312(c)(2), 164.312(e)(2)(i), 164.308(a)(1)(ii)(D) | CM-3 | It is important to capture all events and not restrict event creation. Events are an important source of security information and analytics that ensure that your environment is consistently monitored using the event data. |
| GKE: Argument make-iptables-util-chains should be set to true for Kubelet Server | GKE | CIS Level 1 | 7.1 7.2, 7.2.1, 7.2.2, 7.2.3 | CM-3 | Kubelets can automatically manage the required changes to iptables based on how you choose your networking options for the pods. It is recommended to let kubelets manage the changes to iptables. This ensures that the iptables configuration remains in sync with pods networking configuration. Manually configuring iptables with dynamic pod network configuration changes might hamper the communication between pods/containers and to the outside world. You might have iptables rules too restrictive or too open. | |
| GKE: Argument protect-kernel-defaults should be set to true for Kubelet Server | GKE | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 | CM-3 | Kernel parameters are usually tuned and hardened by the system administrators before putting the systems into production. These parameters protect the kernel and the system. Your kubelet kernel defaults that rely on such parameters should be appropriately set to match the desired secured system state. Ignoring this could potentially lead to running pods with undesired kernel behavior | |
| GKE: Argument rotate-certificates should be set to true for Kubelet Server | GKE | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 8.2.4 | 164.312(a)(1),164.308(a)(3)(i),164.308(b)(1), 164.312(c)(1), 164.312(e)(1) | CM-3 | The --rotate-certificates setting causes the kubelet to rotate its client certificates by creating new CSRs as its existing credentials expire. This automated periodic rotation ensures that the there are no downtimes due to expired certificates and thus addressing availability in the CIA security triad. This recommendation only applies if you let kubelets get their certificates from the API server. In case your kubelet certificates come from an outside authority/tool (e.g. Vault) then you need to take care of rotation yourself |
| GKE: Argument RotateKubeletServerCertificate should be set to true for Kubelet Server | GKE | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 8.2.4 | 164.312(a)(1),164.308(a)(3)(i),164.308(b)(1), 164.312(c)(1), 164.312(e)(1) | CM-3 | RotateKubeletServerCertificate causes the kubelet to both request a serving certificate after bootstrapping its client credentials and rotate the certificate as its existing credentials expire. This automated periodic rotation ensures that the there are no downtimes due to expired certificates and thus addressing availability in the CIA security triad. This recommendation only applies if you let kubelets get their certificates from the API server. In case your kubelet certificates come from an outside authority/tool (e.g. Vault) then you need to take care of rotation yourself. |
| GKE: Argument streaming-connection-idle-timeout should not be set to 0 for Kubelet Server | GKE | CIS Level 1 | 8.1.8 | 164.312(a)(2)(iii) | CM-3 | Setting idle timeouts ensures that you are protected against Denial-of-Service attacks, inactive connections and running out of ephemeral ports. By default, --streaming-connection-idle-timeout is set to 4 hours which might be too high for your environment. Setting this as appropriate would additionally ensure that such streaming connections are timed out after serving legitimate use cases. |
| GKE: Arguments tls-cert-file and tls-private-key-file should be set as appropriate for Kubelet Server | GKE | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 6.5.4 6.5.8 | 164.312(e)(2)(ii),164.312(e)(1),164.312(c)(1), 164.312(a)(2)(iv) | CM-3 | Kubelet communication contains sensitive parameters that should remain encrypted in transit. Configure the Kubelets to serve only HTTPS traffic. |
| GKE: Kubelet should only use strong Cryptographic Ciphers | GKE | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 6.5.8 | 164.312(e)(2)(ii),164.312(e)(1),164.312(c)(1), 164.312(a)(2)(iv) | CM-3 | TLS ciphers have had a number of known vulnerabilities and weaknesses, which can reduce the protection provided by them. By default Kubernetes supports a number of TLS ciphersuites including some that have security concerns, weakening the protection provided. |
| GKE: Group container workloads onto hosts by sensitivity level | GKE | SC-3 | ||||
| GKE: Keeping containerized workloads isolated to container-specific hosts | GKE | SC-3 | ||||
| GKE: Cluster Node Permissions should be monitored | GKE | |||||
| GKE: Enable control plane logging during EKS cluster creation | GKE | 10.1 10.2.2, 10.2.4, 10.2.5, 10.2.7 10.3.1, 10.3.2, 10.3.3, 10.3.4, 10.3.5, 10.3.6 | CM-3 | |||
| GKE: Dedicated security group for each control plane (one per cluster) | GKE | |||||
| GKE: Minimum inbound traffic to control plane security groups | GKE | |||||
| GKE: End point public access should be disabled or monitored correctly | GKE | |||||
| GKE: Do Not Use Vendor-Supplied Defaults for System Passwords and Other Security Parameters | GKE | |||||
| GKE: Argument DenyServiceExternalIPs should not be set for API Server | GKE | CIS Level 1 | This admission controller rejects all net-new usage of the Service field externalIPs. This feature is very powerful (allows network traffic interception) and not well controlled by policy. When enabled, users of the cluster may not create new Services which use externalIPs and may not add new values to externalIPs on existing Service objects. Existing uses of externalIPs are not affected, and users may remove values from externalIPs on existing Service objects.\nMost users do not need this feature at all, and cluster admins should consider disabling it. Clusters that do need to use this feature should consider using some custom policy to manage usage of it. |
Azure Kubernetes Services (AKS)
The following Kubernetes policies apply to Azure Kubernetes Service (AKS).
Skyhigh CASB supports the CIS Kubernetes v1.23 Benchmark v1.0.0 - 02-04-2022 specification for auditing CSP managed clusters.
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
|
|---|---|---|---|---|---|---|
| AKS: Do not admit containers wishing to share the host process ID namespace in Pod Security Policies | AKS | CIS Level 1 | 1.2 2.2, 2.2.3, 2.2.4, 2.3 PCI_SSC_Cloud_guidelines_v3 E.7 | 164.312(a)(1),164.308(a)(3)(i),164.308(b)(1), 164.312(c)(1), 164.312(e)(1) | SC-4 | A container running in the host's PID namespace can inspect processes running outside the container. If the container also has access to ptrace capabilities this can be used to escalate privileges outside of the container. There should be at least one admission control policy defined which does not permit containers to share the host PID namespace. If you need to run containers which require hostPID, this should be defined in a separate policy and you should carefully check to ensure that only limited service accounts and users are given permission to use that policy. |
| AKS: Group container workloads onto hosts by sensitivity level | AKS | SC-3 | ||||
| AKS: Keeping containerized workloads isolated to container-specific hosts | AKS | SC-3 | ||||
| AKS: Argument AdvancedAuditing should not be set to false for API Server | AKS | CIS Level 1 | 10.1 10.2.2, 10.2.4, 10.2.5, 10.2.7 10.3.1, 10.3.2, 10.3.3, 10.3.4, 10.3.5, 10.3.6 | 164.308(a)(5)(ii)(C), 164.312(b), 164.312(c)(2), 164.312(e)(2)(i), 164.308(a)(1)(ii)(D) | CM-3 | AdvancedAuditing enables a much more general API auditing pipeline, which includes support for pluggable output backends and an audit policy specifying how different requests should be audited. Additionally, this enables auditing of failed authentication, authorization and login attempts which could prove crucial for protecting your production clusters. It is thus recommended not to disable advanced auditing |
| AKS: Admission control plugin AlwaysAdmit should not be set for API Server | AKS | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 6.5.8 7.2 | CM-3 | Setting admission control plugin AlwaysAdmit allows all requests and do not filter any requests. | |
| Admission control plugin AlwaysPullImages should be set for API Server | AKS | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 6.5.8 7.1 PCI_SSC_Cloud_guidelines_v3 | CM-3 | Setting admission control policy to AlwaysPullImages forces every new pod to pull the required images every time. In a multi-tenant cluster users can be assured that their private images can only be used by those who have the credentials to pull them. Without this admission control policy, once an image has been pulled to a node, any pod from any user can use it simply by knowing the image’s name, without any authorization check against the image ownership. When this plug-in is enabled, images are always pulled prior to starting containers, which means valid credentials are required. | |
| AKS: Argument anonymous-auth should be set to false for API Server | AKS | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 6.5.8 7.2 | 164.312(a)(1),164.308(a)(3)(i),164.308(b)(1), 164.312(c)(1), 164.312(e)(1) | CM-3 | When enabled, requests that are not rejected by other configured authentication methods are treated as anonymous requests. These requests are then served by the API server. You should rely on authentication to authorize access and disallow anonymous requests. |
| AKS: Argument audit-log-maxage should be set to 30 or as appropriate for API Server | AKS | CIS Level 1 | 10.7 | 164.308(a)(5)(ii)(C), 164.312(b), 164.312(c)(2), 164.312(e)(2)(i), 164.308(a)(1)(ii)(D) | CM-3 | Retaining logs for at least 30 days ensures that you can go back in time and investigate or correlate any events. Set your audit log retention period to 30 days or as per your business requirements. |
| AKS: Argument audit-log-maxbackup should be set to 10 or as appropriate for API Server | AKS | CIS Level 1 | 10.5.3 10.7 | 164.308(a)(5)(ii)(C), 164.312(b), 164.312(c)(2), 164.312(e)(2)(i), 164.308(a)(1)(ii)(D) | CM-3 | Kubernetes automatically rotates the log files. Retaining old log files ensures that you would have sufficient log data available for carrying out any investigation or correlation. For example, if you have set file size of 100 MB and the number of old log files to keep as 10, you would approximate have 1 GB of log data that you could potentially use for your analysis. |
| AKS: Argument audit-log-maxsize should be set to 100 or as appropriate for API Server | AKS | CIS Level 1 | 10.5.3 10.7 | 164.308(a)(5)(ii)(C), 164.312(b), 164.312(c)(2), 164.312(e)(2)(i), 164.308(a)(1)(ii)(D) | CM-3 | Kubernetes automatically rotates the log files. Retaining old log files ensures that you would have sufficient log data available for carrying out any investigation or correlation. If you have set file size of 100 MB and the number of old log files to keep as 10, you would approximate have 1 GB of log data that you could potentially use for your analysis. |
| AKS: Argument audit-log-path should be set as appropriate for API Server | AKS | CIS Level 1 | 10.1 10.2.2, 10.2.4, 10.2.5, 10.2.7 10.3.1, 10.3.2, 10.3.3, 10.3.4, 10.3.5, 10.3.6 | 164.308(a)(5)(ii)(C), 164.312(b), 164.312(c)(2), 164.312(e)(2)(i), 164.308(a)(1)(ii)(D) | CM-3 | Auditing the API Server provides a security-relevant chronological set of records documenting the sequence of activities that have affected system by individual users, administrators or other components of the system. Even though currently, Kubernetes provides only basic audit capabilities, it should be enabled. You can enable it by setting an appropriate audit log path. |
| AKS: Argument authorization-mode should not be set to AlwaysAllow for API Server | AKS | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 6.5.8 2.2.2 6.4.2 | 164.312(a)(1),164.308(a)(3)(i),164.308(b)(1), 164.312(c)(1), 164.312(e)(1) | CM-3 | The API Server, can be configured to allow all requests. This mode should not be used on any production cluster. |
| AKS: Argument authorization-mode should include Node for API Server | AKS | CIS Level 1 | 7.1 | 164.312(a)(1),164.308(a)(3)(i),164.308(b)(1), 164.312(c)(1), 164.312(e)(1) | CM-3 | The Node authorization mode only allows kubelets to read Secret, ConfigMap, PersistentVolume, and PersistentVolumeClaim objects associated with their nodes. |
| AKS: Argument authorization-mode should include RBAC for API Server | AKS | CIS Level 1 | 7.1 | 164.312(a)(1),164.308(a)(3)(i),164.308(b)(1), 164.312(c)(1), 164.312(e)(1) | CM-3 | Role Based Access Control (RBAC) allows fine-grained control over the operations that different entities can perform on different objects in the cluster. It is recommended to use the RBAC authorisation mode. |
| AKS: Argument basic-auth-file should not be set for API Server | AKS | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 6.5.3 | CM-3 | Basic authentication uses plaintext credentials for authentication. Currently, the basic authentication credentials last indefinitely, and the password cannot be changed without restarting API server. The basic authentication is currently supported for convenience. Hence, basic authentication should not be used. | |
| AKS: Argument client-ca-file should be set as appropriate for API Server | AKS | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 6.5.4 6.5.8 | 164.312(a)(1),164.308(a)(3)(i),164.308(b)(1), 164.312(c)(1), 164.312(e)(1) | CM-3 | API server communication contains sensitive parameters that should remain encrypted in transit. Configure the API server to serve only HTTPS traffic. If --client-ca-file argument is set, any request presenting a client certificate signed by one of the authorities in the client-ca-file is authenticated with an identity corresponding to the CommonName of the client certificate. |
| AKS: Argument encryption-provider-config should be set as appropriate for API Server | AKS | CIS Level 1 | 2.2 6.5.3 | 164.312(e)(2)(ii),164.312(e)(1),164.312(c)(1), 164.312(a)(2)(iv) | CM-3 | etcd is a highly available key-value store used by Kubernetes deployments for persistent storage of all of its REST API objects. These objects are sensitive in nature and should be encrypted at rest to avoid any disclosures. |
| AKS: Argument etcd-cafile should be set as appropriate for API Server | AKS | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 6.5.8 7.1 | 164.312(a)(1),164.308(a)(3)(i),164.308(b)(1), 164.312(c)(1), 164.312(e)(1) | CM-3 | etcd is a highly-available key value store used by Kubernetes deployments for persistent storage of all of its REST API objects. These objects are sensitive in nature and should be protected by client authentication. This requires the API server to identify itself to the etcd server using a SSL Certificate Authority file. |
| AKS: Arguments etcd-certfile and etcd-keyfile should be set as appropriate for API Server | AKS | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 6.5.8 7.1 PCI_SSC_Cloud_guidelines_v3 E.7 | 164.312(a)(1),164.308(a)(3)(i),164.308(b)(1), 164.312(c)(1), 164.312(e)(1) | CM-3 | etcd is a highly-available key value store used by Kubernetes deployments for persistent storage of all of its REST API objects. These objects are sensitive in nature and should be protected by client authentication. This requires the API server to identify itself to the etcd server using a client certificate and key |
| AKS: Admission control plugin EventRateLimit should be set for API Server | AKS | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 | 164.312(a)(2)(iii) | CM-3 | Using EventRateLimit admission control enforces a limit on the number of events that the API Server will accept in a given time slice. A misbehaving workload could overwhelm and DoS the API Server, making it unavailable. This particularly applies to a multi-tenant cluster, where there might be a small percentage of misbehaving tenants which could have a significant impact on the performance of the cluster overall. Hence, it is recommended to limit the rate of events that the API server will accept. |
| AKS: Argument insecure-bind-address should not be set for API Server | AKS | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 2.2.2 6.5.4 6.5.8 | 164.312(a)(1),164.308(a)(3)(i),164.308(b)(1), 164.312(c)(1), 164.312(e)(1) | CM-3 | If you bind the apiserver to an insecure address, basically anyone who could connect to it over the insecure port, would have unauthenticated and unencrypted access to your master node. The apiserver doesn't do any authentication checking for insecure binds and traffic to the Insecure API port is not encrpyted, allowing attackers to potentially read sensitive data in transit. |
| AKS: Argument insecure-port should be set to 0 for API Server | AKS | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 2.2.2 6.5.4 6.5.8 | 164.312(a)(1),164.308(a)(3)(i),164.308(b)(1), 164.312(c)(1), 164.312(e)(1) | CM-3 | Setting up the apiserver to serve on an insecure port would allow unauthenticated and unencrypted access to your master node. This would allow attackers who could access this port, to easily take control of the cluster. |
| AKS: Argument insecure-allow-any-token should not be set for API Server | AKS | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 6.5.4 10.5 | 164.312(a)(1),164.308(a)(3)(i),164.308(b)(1), 164.312(c)(1), 164.312(e)(1) | CM-3 | Accepting insecure tokens would allow any token without actually authenticating anything. User information is parsed from the token and connections are allowed. |
| AKS: Argument kubelet-certificate-authority should be set as appropriate for API Server | AKS | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 6.5.4 10.5 | 164.312(a)(1),164.308(a)(3)(i),164.308(b)(1), 164.312(c)(1), 164.312(e)(1) | CM-3 | The connections from the apiserver to the kubelet are used for fetching logs for pods, attaching (through kubectl) to running pods, and using the kubelet’s port-forwarding functionality. These connections terminate at the kubelet’s HTTPS endpoint. By default, the apiserver does not verify the kubelet’s serving certificate, which makes the connection subject to man-in-the-middle attacks, and unsafe to run over untrusted and/or public networks. |
| AKS: Arguments kubelet-client-certificate and kubelet-client-key should be set as appropriate for API Server | AKS | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 6.5.4 10.5 | 164.312(a)(1),164.308(a)(3)(i),164.308(b)(1), 164.312(c)(1), 164.312(e)(1) | CM-3 | The apiserver, by default, does not authenticate itself to the kubelet's HTTPS endpoints. The requests from the apiserver are treated anonymously. You should set up certificatebased kubelet authentication to ensure that the apiserver authenticates itself to kubelets when submitting requests. |
| AKS: Argument kubelet-https should be set to true for API Server | AKS | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 6.5.4 | 164.312(e)(2)(ii),164.312(e)(1),164.312(c)(1), 164.312(a)(2)(iv) | CM-3 | Connections from apiserver to kubelets could potentially carry sensitive data such as secrets and keys. It is thus important to use in-transit encryption for any communication between the apiserver and kubelets. |
| AKS: Admission control plugin NamespaceLifecycle should be set for API Server | AKS | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 PCI_SSC_Cloud_guidelines_v3 | CM-3 | Setting admission control policy to NamespaceLifecycle ensures that objects cannot be created in non-existent namespaces, and that namespaces undergoing termination are not used for creating the new objects. This is recommended to enforce the integrity of the namespace termination process and also for the availability of the newer objects | |
| AKS: Admission control plugin NodeRestriction should be set for API Server | AKS | CIS Level 1 | 7.1 | CM-3 | Using the NodeRestriction plug-in ensures that the kubelet is restricted to the Node and Pod objects that it could modify as defined. Such kubelets will only be allowed to modify their own Node API object, and only modify Pod API objects that are bound to their node. | |
| AKS: Admission control plugin PodSecurityPolicy should be set for API Server | AKS | CIS Level 1 | 1.2 | CM-3 | A Pod Security Policy is a cluster-level resource that controls the actions that a pod can perform and what it has the ability to access. The PodSecurityPolicy objects define a set of conditions that a pod must run with in order to be accepted into the system. Pod Security Policies are comprised of settings and strategies that control the security features a pod has access to and hence this must be used to control pod access permissions. | |
| AKS: Argument profiling should be set to false for API Server | AKS | CIS Level 1 | 7.1 7.2, 7.2.1, 7.2.2, 7.2.3 | CM-3 | Profiling allows for the identification of specific performance bottlenecks. It generates a significant amount of program data that could potentially be exploited to uncover system and program details. If you are not experiencing any bottlenecks and do not need the profiler for troubleshooting purposes, it is recommended to turn it off to reduce the potential attack surface. | |
| AKS: Argument repair-malformed-updates should be set to false for API Server | AKS | CIS Level 1 | 6.5.5 | CM-3 | The API Server will potentially attempt to fix the update requests to pass the validation even if the requests are malformed. Malformed requests are one of the potential ways to interact with a service without legitimate information. Such requests could potentially be used to sabotage API Server responses. | |
| AKS: Argument request-timeout should be set as appropriate for API Server | AKS | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 8.1.8 | 164.312(a)(2)(iii) | CM-3 | Kubernetes automatically rotates the log files. Retaining old log files ensures that you would have sufficient log data available for carrying out any investigation or correlation. If you have set file size of 100 MB and the number of old log files to keep as 10, you would approximate have 1 GB of log data that you could potentially use for your analysis. |
| AKS: Argument secure-port should not be set to 0 for API Server | AKS | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 6.5.4 6.5.8 | CM-3 | The secure port is used to serve https with authentication and authorization. If you disable it, no https traffic is served and all traffic is served unencrypted. | |
| AKS: Admission control plugin SecurityContextDeny should be set if PodSecurityPolicy is not used for API Server | AKS | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 PCI_SSC_Cloud_guidelines_v3 | CM-3 | SecurityContextDeny can be used to provide a layer of security for clusters which do not have PodSecurityPolicies enabled. | |
| AKS: Argument service-account-key-file should be set as appropriate for API Server | AKS | CIS Level 1 | 8.2.2 8.5 | CM-3 | By default, if no --service-account-key-file is specified to the apiserver, it uses the private key from the TLS serving certificate to verify service account tokens. To ensure that the keys for service account tokens could be rotated as needed, a separate public/private key pair should be used for signing service account tokens. Hence, the public key should be specified to the apiserver with --service-account-key-file. | |
| AKS: Argument service-account-lookup should be set to true for API Server | AKS | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 6.5.10 | CM-3 | If --service-account-lookup is not enabled, the apiserver only verifies that the authentication token is valid, and does not validate that the service account token mentioned in the request is actually present in etcd. This allows using a service account token even after the corresponding service account is deleted. This is an example of time of check to time of use security issue | |
| AKS: Admission control plugin ServiceAccount should be set for API Server | AKS | CIS Level 1 | 2.1 | CM-3 | When you create a pod, if you do not specify a service account, it is automatically assigned the default service account in the same namespace. You should create your own service account and let the API server manage its security tokens. | |
| AKS: Arguments tls-cert-file and tls-private-key-file should be set as appropriate for API Server | AKS | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 6.5.4 6.5.8 | 164.312(e)(2)(ii),164.312(e)(1),164.312(c)(1), 164.312(a)(2)(iv) | CM-3 | The connections from the apiserver to the kubelet are used for fetching logs for pods, attaching (through kubectl) to running pods, and using the kubelet’s port-forwarding functionality. These connections terminate at the kubelet’s HTTPS endpoint. By default, the apiserver does not verify the kubelet’s serving certificate, which makes the connection subject to man-in-the-middle attacks, and unsafe to run over untrusted and/or public networks. |
| AKS: API Server should only use Strong Cryptographic Ciphers | AKS | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 6.5.8 | 164.312(e)(2)(ii),164.312(e)(1),164.312(c)(1), 164.312(a)(2)(iv) | CM-3 | TLS ciphers have had a number of known vulnerabilities and weaknesses, which can reduce the protection provided by them. By default Kubernetes supports a number of TLS ciphersuites including some that have security concerns, weakening the protection provided. |
| AKS: Argument token-auth-file should not be set for API Server | AKS | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 6.5.3 8.2.1 | CM-3 | The token-based authentication utilizes static tokens to authenticate requests to the apiserver. The tokens are stored in clear-text in a file on the apiserver, and cannot be revoked or rotated without restarting the apiserver. Hence, do not use static token-based authentication. | |
| AKS: Argument address should be set to 127.0.0.1 for Controller Manager | AKS | CIS Level 1 | 7.1 7.2, 7.2.1, 7.2.2, 7.2.3 | CM-3 | The Controller Manager API service which runs on port 10252/TCP by default is used for health and metrics information and is available without authentication or encryption. As such it should only be bound to a localhost interface, to minimize the cluster's attack surface | |
| AKS: Argument profiling should be set to false for Controller Manager | AKS | CIS Level 1 | 7.1 7.2, 7.2.1, 7.2.2, 7.2.3 | CM-3 | Profiling allows for the identification of specific performance bottlenecks. It generates a significant amount of program data that could potentially be exploited to uncover system and program details. If you are not experiencing any bottlenecks and do not need the profiler for troubleshooting purposes, it is recommended to turn it off to reduce the potential attack surface. | |
| AKS: Argument root-ca-file should be set as appropriate for Controller Manager | AKS | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 6.5.4 6.5.8 | 164.312(a)(1),164.308(a)(3)(i),164.308(b)(1), 164.312(c)(1), 164.312(e)(1) | CM-3 | Processes running within pods that need to contact the API server must verify the API server's serving certificate. Failing to do so could be a subject to man-in-the-middle attacks. Providing the root certificate for the API server's serving certificate to the controller manager with the --root-ca-file argument allows the controller manager to inject the trusted bundle into pods so that they can verify TLS connections to the API server. |
| AKS: Argument RotateKubeletServerCertificate should be set to true for Controller Manager | AKS | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 6.5.4 6.5.8 | 164.312(a)(1),164.308(a)(3)(i),164.308(b)(1), 164.312(c)(1), 164.312(e)(1) | CM-3 | RotateKubeletServerCertificate causes the kubelet to both request a serving certificate after bootstrapping its client credentials and rotate the certificate as its existing credentials expire. This automated periodic rotation ensures that the there are no downtimes due to expired certificates and thus addressing availability in the CIA security triad. |
| AKS: Argument use-service-account-credentials should be set to true for Controller Manager | AKS | CIS Level 1 | 7.1 7.2, 7.2.1, 7.2.2, 7.2.3 | CM-3 | The controller manager creates a service account per controller in the kube-system namespace, generates a credential for it, and builds a dedicated API client with that service account credential for each controller loop to use. Setting the --use-service-accountcredentials to true runs each control loop within the controller manager using a separate service account credential. When used in combination with RBAC, this ensures that the control loops run with the minimum permissions required to perform their intended tasks. | |
| AKS: Argument service-account-private-key-file should be set as appropriate for Controller Manager | AKS | CIS Level 1 | 8.2.2 8.5 | CM-3 | To ensure that keys for service account tokens can be rotated as needed, a separate public/private key pair should be used for signing service account tokens. The private key should be specified to the controller manager with --service-account-private-key-file as appropriate. | |
| AKS: Argument terminated-pod-gc-threshold should be set as appropriate for Controller Manager | AKS | CIS Level 1 | 6.5.2 | 164.312(a)(2)(iii) | CM-3 | Garbage collection is important to ensure sufficient resource availability and avoiding degraded performance and availability. In the worst case, the system might crash or just be unusable for a long period of time. The current setting for garbage collection is 12,500 terminated pods which might be too high for your system to sustain. Based on your system resources and tests, choose an appropriate threshold value to activate garbage collection. |
| AKS: Argument address should be set to 127.0.0.1 for Scheduler | AKS | CIS Level 1 | 7.1 7.2, 7.2.1, 7.2.2, 7.2.3 | CM-3 | The Scheduler API service which runs on port 10251/TCP by default is used for health and metrics information and is available without authentication or encryption. As such it should only be bound to a localhost interface, to minimize the cluster's attack surface | |
| AKS: Argument profiling should be set to false for Scheduler | AKS | CIS Level 1 | 7.1 7.2, 7.2.1, 7.2.2, 7.2.3 | CM-3 | Profiling allows for the identification of specific performance bottlenecks. It generates a significant amount of program data that could potentially be exploited to uncover system and program details. If you are not experiencing any bottlenecks and do not need the profiler for troubleshooting purposes, it is recommended to turn it off to reduce the potential attack surface. | |
| AKS: Argument anonymous-auth should be set to false for Kubelet Server | AKS | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 6.5.8 7.2 | 164.312(a)(1),164.308(a)(3)(i),164.308(b)(1), 164.312(c)(1), 164.312(e)(1) | CM-3 | When enabled, requests that are not rejected by other configured authentication methods are treated as anonymous requests. These requests are then served by the Kubelet server. You should rely on authentication to authorize access and disallow anonymous requests. |
| AKS: Argument client-ca-file should be set as appropriate for Kubelet Server | AKS | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 6.5.4 6.5.8 | 164.312(a)(1),164.308(a)(3)(i),164.308(b)(1), 164.312(c)(1), 164.312(e)(1) | CM-3 | The connections from the apiserver to the kubelet are used for fetching logs for pods, attaching (through kubectl) to running pods, and using the kubelet’s port-forwarding functionality. These connections terminate at the kubelet’s HTTPS endpoint. By default, the apiserver does not verify the kubelet’s serving certificate, which makes the connection subject to man-in-the-middle attacks, and unsafe to run over untrusted and/or public networks. Enabling Kubelet certificate authentication ensures that the apiserver could authenticate the Kubelet before submitting any requests. |
| AKS: Argument event-qps should be set to 0 or a level which ensures appropriate event capture for Kubelet Server | AKS | CIS Level 1 | 10.1 10.2.2, 10.2.4, 10.2.5, 10.2.7 10.3.1, 10.3.2, 10.3.3, 10.3.4, 10.3.5, 10.3.6 | 164.308(a)(5)(ii)(C), 164.312(b), 164.312(c)(2), 164.312(e)(2)(i), 164.308(a)(1)(ii)(D) | CM-3 | It is important to capture all events and not restrict event creation. Events are an important source of security information and analytics that ensure that your environment is consistently monitored using the event data. |
| AKS: Argument make-iptables-util-chains should be set to true for Kubelet Server | AKS | CIS Level 1 | 7.1 7.2, 7.2.1, 7.2.2, 7.2.3 | CM-3 | Kubelets can automatically manage the required changes to iptables based on how you choose your networking options for the pods. It is recommended to let kubelets manage the changes to iptables. This ensures that the iptables configuration remains in sync with pods networking configuration. Manually configuring iptables with dynamic pod network configuration changes might hamper the communication between pods/containers and to the outside world. You might have iptables rules too restrictive or too open. | |
| AKS: Argument protect-kernel-defaults should be set to true for Kubelet Server | AKS | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 | CM-3 | Kernel parameters are usually tuned and hardened by the system administrators before putting the systems into production. These parameters protect the kernel and the system. Your kubelet kernel defaults that rely on such parameters should be appropriately set to match the desired secured system state. Ignoring this could potentially lead to running pods with undesired kernel behavior | |
| AKS: Argument rotate-certificates should be set to true for Kubelet Server | AKS | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 8.2.4 | 164.312(a)(1),164.308(a)(3)(i),164.308(b)(1), 164.312(c)(1), 164.312(e)(1) | CM-3 | The --rotate-certificates setting causes the kubelet to rotate its client certificates by creating new CSRs as its existing credentials expire. This automated periodic rotation ensures that the there are no downtimes due to expired certificates and thus addressing availability in the CIA security triad. This recommendation only applies if you let kubelets get their certificates from the API server. In case your kubelet certificates come from an outside authority/tool (e.g. Vault) then you need to take care of rotation yourself |
| AKS: Argument RotateKubeletServerCertificate should be set to true for Kubelet Server | AKS | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 8.2.4 | 164.312(a)(1),164.308(a)(3)(i),164.308(b)(1), 164.312(c)(1), 164.312(e)(1) | CM-3 | RotateKubeletServerCertificate causes the kubelet to both request a serving certificate after bootstrapping its client credentials and rotate the certificate as its existing credentials expire. This automated periodic rotation ensures that the there are no downtimes due to expired certificates and thus addressing availability in the CIA security triad. This recommendation only applies if you let kubelets get their certificates from the API server. In case your kubelet certificates come from an outside authority/tool (e.g. Vault) then you need to take care of rotation yourself. |
| AKS: Argument streaming-connection-idle-timeout should not be set to 0 for Kubelet Server | AKS | CIS Level 1 | 8.1.8 | 164.312(a)(2)(iii) | CM-3 | Setting idle timeouts ensures that you are protected against Denial-of-Service attacks, inactive connections and running out of ephemeral ports. By default, --streaming-connection-idle-timeout is set to 4 hours which might be too high for your environment. Setting this as appropriate would additionally ensure that such streaming connections are timed out after serving legitimate use cases. |
| AKS: Arguments tls-cert-file and tls-private-key-file should be set as appropriate for Kubelet Server | AKS | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 6.5.4 6.5.8 | 164.312(e)(2)(ii),164.312(e)(1),164.312(c)(1), 164.312(a)(2)(iv) | CM-3 | Kubelet communication contains sensitive parameters that should remain encrypted in transit. Configure the Kubelets to serve only HTTPS traffic. |
| AKS: Kubelet should only use strong Cryptographic Ciphers | AKS | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 6.5.8 | 164.312(e)(2)(ii),164.312(e)(1),164.312(c)(1), 164.312(a)(2)(iv) | CM-3 | TLS ciphers have had a number of known vulnerabilities and weaknesses, which can reduce the protection provided by them. By default Kubernetes supports a number of TLS ciphersuites including some that have security concerns, weakening the protection provided. |
| AKS: Do not admit containers with allowPrivilegeEscalation in Pod Security Policies | AKS | CIS Level 1 | 1.2 2.2, 2.2.3, 2.2.4, 2.3 PCI_SSC_Cloud_guidelines_v3 E.7 | 164.312(a)(1),164.308(a)(3)(i),164.308(b)(1), 164.312(c)(1), 164.312(e)(1) | CM-3 | A container running with the allowPrivilegeEscalation flag set to true may have processes that can gain more privileges than their parent. There should be at least one admission control policy defined which does not permit containers to allow privilege escalation. The option exists (and is defaulted to true) to permit set uid binaries to run. If you have need to run containers which use set uid binaries or require privilege escalation, this should be defined in a separate policy and you should carefully check to ensure that only limited service accounts and users are given permission to use that policy. |
| AKS: Do not admit containers wishing to share the host IPC namespace in Pod Security Policies | AKS | CIS Level 1 | 1.2 2.2, 2.2.3, 2.2.4, 2.3 PCI_SSC_Cloud_guidelines_v3 E.7 | CM-3 | A container running in the host's IPC namespace can use IPC to interact with processes outside the container. There should be at least one admission control policy defined which does not permit containers to share the host IPC namespace. If you need to run containers which require hostIPC, this should be definited in a separate policy and you should carefully check to ensure that only limited service accounts and users are given permission to use that policy. | |
| AKS: Do not admit containers wishing to share the host network namespace in Pod Security Policies | AKS | CIS Level 1 | 1.2 2.2, 2.2.3, 2.2.4, 2.3 PCI_SSC_Cloud_guidelines_v3 E | 164.312(a)(1),164.308(a)(3)(i),164.308(b)(1), 164.312(c)(1), 164.312(e)(1) | CM-3 | A container running in the host's network namespace could access the local loopback device, and could access network traffic to and from other pods. There should be at least one admission control policy defined which does not permit containers to share the host network namespace. If you need to run containers which require access to the host's network namesapces, this should be defined in a separate policy and you should carefully check to ensure that only limited service accounts and users are given permission to use that policy. |
| AKS: Do not admit privileged containers in Pod Security Policies | AKS | CIS Level 1 | 1.2 2.2, 2.2.3, 2.2.4, 2.3 PCI_SSC_Cloud_guidelines_v3 E.7 | 164.312(a)(1),164.308(a)(3)(i),164.308(b)(1), 164.312(c)(1), 164.312(e)(1) | CM-3 | Privileged containers have access to all Linux Kernel capabilities and devices. A container running with full privileges can do almost everything that the host can do. This flag exists to allow special use-cases, like manipulating the network stack and accessing devices. There should be at least one admission control policy defined which does not permit privileged containers. If you need to run privileged containers, this should be defined in a separate policy and you should carefully check to ensure that only limited service accounts and users are given permission to use that policy. |
| AKS: Do not generally permit containers to be run as the root user in Pod Security Policies | AKS | CIS Level 2 | 1.2 2.2, 2.2.3, 2.2.4, 2.3 PCI_SSC_Cloud_guidelines_v3 E.7 | 164.312(a)(1),164.308(a)(3)(i),164.308(b)(1), 164.312(c)(1), 164.312(e)(1) | CM-3 | Containers may run as any Linux user. Containers which run as the root user, whilst constrained by Container Runtime security features still have a escalated likelihood of container breakout. Ideally, all containers should run as a defined non-UID 0 user. There should be at least one admission control policy defined which does not permit root containers. If you need to run root containers, this should be defined in a separate policy and you should carefully check to ensure that only limited service accounts and users are given permission to use that policy. |
| AKS: Enable control plane logging during AKS cluster creation | AKS | 10.1 10.2.2, 10.2.4, 10.2.5, 10.2.7 10.3.1, 10.3.2, 10.3.3, 10.3.4, 10.3.5, 10.3.6 | CM-3 | |||
| AKS: Argument authorization-mode should not be set to AlwaysAllow for Kubelet Server | AKS | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 6.5.8 2.2.2 6.4.2 | 164.312(a)(1),164.308(a)(3)(i),164.308(b)(1), 164.312(c)(1), 164.312(e)(1) | CM_3 | Kubelets, by default, allow all authenticated requests (even anonymous ones) without needing explicit authorization checks from the apiserver. You should restrict this behavior and only allow explicitly authorized requests. |
| AKS: Cluster Node Permissions should be monitored | AKS | |||||
| AKS: Dedicated security group for each control plane (one per cluster) | AKS | |||||
| AKS: Minimum inbound traffic to control plane security groups | AKS | |||||
| AKS: End point public access should be disabled or monitored correctly | AKS | |||||
| AKS: Do Not Use Vendor-Supplied Defaults for System Passwords and Other Security Parameters | AKS | |||||
| AKS: Do not generally permit containers with capabilities assigned beyond the default set in Pod Security Policies | AKS | CIS Level 1 | Containers run with a default set of capabilities as assigned by the Container Runtime. Capabilities outside this set can be added to containers which could expose them to risks of container breakout attacks. There should be at least one policy defined which prevents containers with capabilities beyond the default set from launching. If you need to run containers with additional capabilities, this should be defined in a separate policy and you should carefully check to ensure that only limited service accounts and users are given permission to use that policy. | |||
| AKS: Argument DenyServiceExternalIPs should not be set for API Server | AKS | CIS Level 1 | This admission controller rejects all net-new usage of the Service field externalIPs. This feature is very powerful (allows network traffic interception) and not well controlled by policy. When enabled, users of the cluster may not create new Services which use externalIPs and may not add new values to externalIPs on existing Service objects. Existing uses of externalIPs are not affected, and users may remove values from externalIPs on existing Service objects.\nMost users do not need this feature at all, and cluster admins should consider disabling it. Clusters that do need to use this feature should consider using some custom policy to manage usage of it. |
Azure Container Registry (ACR)
Policy Templates for Container Security are used with Microsoft Azure Container Registry (ACR).
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 |
|---|---|---|---|---|---|---|
| ACR: Image Registry should not have more than 200 repositories | ACR | Yes | SC-6, Resource Availability | Image registry should have a limit on number of respositories | ||
| ACR: Repositories should not be exposed to everyone/ publicly for push actions | ACR | Yes | SI-7, Software, Firmware, and Information Integrity. | Repository policy push actions should be avoided | ||
| ACR: Repositories should not be exposed to everyone/ publicly for pull actions | ACR | Yes | SI-7, Software, Firmware, and Information Integrity. | Repository policy pull actions should be avoided | ||
| ACR: Repositories should not be exposed to everyone/ publicly for delete actions | ACR | Yes | SI-7, Software, Firmware, and Information Integrity. | Repository policy delete actions should be avoided | ||
| ACR: Image tag immutability should be set correctly for repository | ACR | Yes | SI-7, Software, Firmware, and Information Integrity. | Image Tag Immutability should be set correctly for the repository | ||
| ACR: Container Registries must not allow unrestricted network access | ACR | Yes | SI-7, Software, Firmware, and Information Integrity. | Azure container registries by default accept connections over the internet from hosts to any network. To protect your registries from potential threats, allow access from only specific private endpoints, public IP addresses, or address ranges. If your registry doesn't have network rules configured, it will appear in the unhealthy resources. |
AWS Fargate
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 Fargate: HEALTHCHECK instruction should be added to the container image in ECS Fargate cluster | ECS FARGATE | CIS Level 1 | CM-3 | Add HEALTHCHECK instruction in your docker container images to perform the health check on running containers. | ||
| ECS Fargate: A daemon wide custom seccomp profile should be applied in ECS Fargate cluster | ECS FARGATE | 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 Fargate: Incoming container traffic should be binded to a specific host interface in ECS Fargate cluster | ECS FARGATE | CIS Level 1 | SC-7 | 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 Fargate: Centralized and remote logging should be configured in ECS Fargate cluster | ECS FARGATE | 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 Fargate: Container CPU priority should be set appropriately in ECS Fargate cluster | ECS FARGATE | 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 Fargate: Content Trust should be enabled For Docker in ECS Fargate cluster | ECS FARGATE | CIS Level 2 | CM-3 | Content trust is disabled by default and should be enabled in line with organizational security policy.Content trust provides the ability to use digital signatures for data sent to and received from remote Docker registries. These signatures allow client-side verification of the identity and the publisher of specific image tags and ensures the provenance of container images. | ||
| ECS Fargate: Default seccomp profile should not be disabled in ECS Fargate cluster | ECS FARGATE | 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 Fargate: Docker Version should be kept up to date in ECS Fargate cluster | ECS FARGATE | 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 Fargate: Host devices should not be exposed directly to containers in ECS Fargate cluster | ECS FARGATE | CIS Level 1 | CM-3 | 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 Fargate: Memory usage for container should be limited in ECS Fargate cluster | ECS FARGATE | 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 Fargate: Docker socket should not be mounted inside any containers in ECS Fargate cluster | ECS FARGATE | 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 Fargate: Sensitive host system directories should not be mounted on containers in ECS Fargate cluster | ECS FARGATE | 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 Fargate: A non-root user should be created for the container in ECS Fargate cluster | ECS FARGATE | CIS Level 1 | SC-2 | Create a non-root user for the container in the Dockerfile for the container image. | ||
| ECS Fargate: Privileged ports should not be mapped within containers in ECS Fargate cluster | ECS FARGATE | 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 Fargate: Privileged containers should not be used in ECS Fargate cluster | ECS FARGATE | 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 Fargate: Container's file system should be mounted in read-only mode in ECS Fargate cluster | ECS FARGATE | 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 Fargate: Setuid and Setgid permissions should be removed in the images in ECS Fargate cluster | ECS FARGATE | CIS Level 1 | CM-3 | Removing setuid and setgid permissions in the images would prevent privilege escalation attacks in the containers. | ||
| ECS Fargate: Linux Kernel Capabilities should be restricted within containers in ECS Fargate cluster | ECS FARGATE | 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 Fargate: Container should be restricted from acquiring additional permissions in ECS Fargate cluster | ECS FARGATE | CIS Level 1 | CM-3 | Restrict the container from acquiring additional permissions via suid or sgid bits. | ||
| ECS Fargate: User namespace support should be enabled in ECS Fargate cluster | ECS FARGATE | 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 Fargate: SELinux security options should be verified in ECS Fargate cluster | ECS FARGATE | 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 Fargate: Container health should be checked at runtime in ECS Fargate cluster | ECS FARGATE | 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. | ||
| EKS Fargate: Arguments tls-cert-file and tls-private-key-file should be set as appropriate for Kubelet Server in FARGATE EKS cluster | EKS FARGATE | CIS Level 1 | Kubelet communication contains sensitive parameters that should remain encrypted in transit. Configure the Kubelets to serve only HTTPS traffic. | |||
| EKS Fargate: Argument anonymous-auth should be set to false for Kubelet Server in FARGATE EKS cluster | EKS FARGATE | CIS Level 1 | When enabled, requests that are not rejected by other configured authentication methods are treated as anonymous requests. These requests are then served by the Kubelet server. You should rely on authentication to authorize access and disallow anonymous requests. | |||
| EKS Fargate: Argument authorization-mode should not be set to AlwaysAllow for Kubelet Server in FARGATE EKS cluster | EKS FARGATE | CIS Level 1 | Kubelets, by default, allow all authenticated requests (even anonymous ones) without needing explicit authorization checks from the apiserver. You should restrict this behavior and only allow explicitly authorized requests. | |||
| EKS Fargate: Argument client-ca-file should be set as appropriate for Kubelet Server in FARGATE EKS cluster | EKS FARGATE | CIS Level 1 | The connections from the apiserver to the kubelet are used for fetching logs for pods, attaching (through kubectl) to running pods, and using the kubelet’s port-forwarding functionality. These connections terminate at the kubelet’s HTTPS endpoint. By default, the apiserver does not verify the kubelet’s serving certificate, which makes the connection subject to man-in-the-middle attacks, and unsafe to run over untrusted and/or public networks. Enabling Kubelet certificate authentication ensures that the apiserver could authenticate the Kubelet before submitting any requests. | |||
| EKS Fargate: Argument event-qps should be set to 0 for Kubelet Server in FARGATE EKS cluster | EKS FARGATE | CIS Level 1 | It is important to capture all events and not restrict event creation. Events are an important source of security information and analytics that ensure that your environment is consistently monitored using the event data. | |||
| EKS Fargate: Argument make-iptables-util-chains should be set to true for Kubelet Server in FARGATE EKS cluster | EKS FARGATE | CIS Level 1 | Kubelets can automatically manage the required changes to iptables based on how you choose your networking options for the pods. It is recommended to let kubelets manage the changes to iptables. This ensures that the iptables configuration remains in sync with pods networking configuration. Manually configuring iptables with dynamic pod network configuration changes might hamper the communication between pods/containers and to the outside world. You might have iptables rules too restrictive or too open. | |||
| EKS Fargate: Argument protect-kernel-defaults should be set to true for Kubelet Server in FARGATE EKS cluster | EKS FARGATE | CIS Level 1 | Kernel parameters are usually tuned and hardened by the system administrators before putting the systems into production. These parameters protect the kernel and the system. Your kubelet kernel defaults that rely on such parameters should be appropriately set to match the desired secured system state. Ignoring this could potentially lead to running pods with undesired kernel behavior | |||
| EKS Fargate: Argument read-only-port should be set to 0 for Kubelet Server in FARGATE EKS cluster | EKS FARGATE | CIS Level 1 | The Kubelet process provides a read-only API in addition to the main Kubelet API. Unauthenticated access is provided to this read-only API which could possibly retrieve potentially sensitive information about the cluster. | |||
| EKS Fargate: Argument rotate-certificates should be set to true for Kubelet Server in FARGATE EKS cluster | EKS FARGATE | CIS Level 1 | The --rotate-certificates setting causes the kubelet to rotate its client certificates by creating new CSRs as its existing credentials expire. This automated periodic rotation ensures that the there are no downtimes due to expired certificates and thus addressing availability in the CIA security triad. This recommendation only applies if you let kubelets get their certificates from the API server. In case your kubelet certificates come from an outside authority/tool (e.g. Vault) then you need to take care of rotation yourself | |||
| EKS Fargate: Argument RotateKubeletServerCertificate should be set to true for Kubelet Server in FARGATE EKS cluster | EKS FARGATE | CIS Level 1 | RotateKubeletServerCertificate causes the kubelet to both request a serving certificate after bootstrapping its client credentials and rotate the certificate as its existing credentials expire. This automated periodic rotation ensures that the there are no downtimes due to expired certificates and thus addressing availability in the CIA security triad. This recommendation only applies if you let kubelets get their certificates from the API server. In case your kubelet certificates come from an outside authority/tool (e.g. Vault) then you need to take care of rotation yourself. | |||
| EKS Fargate: Argument streaming-connection-idle-timeout should not be set to 0 for Kubelet Server in FARGATE EKS cluster | EKS FARGATE | CIS Level 1 | Setting idle timeouts ensures that you are protected against Denial-of-Service attacks, inactive connections and running out of ephemeral ports. By default, --streaming-connection-idle-timeout is set to 4 hours which might be too high for your environment. Setting this as appropriate would additionally ensure that such streaming connections are timed out after serving legitimate use cases. | |||
| EKS Fargate: Kubelet should only use strong Cryptographic Ciphers in FARGATE EKS cluster | EKS FARGATE | CIS Level 1 | TLS ciphers have had a number of known vulnerabilities and weaknesses, which can reduce the protection provided by them. By default Kubernetes supports a number of TLS ciphersuites including some that have security concerns, weakening the protection provided. |