Skip to main content

Check out Interactive Visual Stories to gain hands-on experience with the SSE product features. Click here.

Skyhigh Security

Policy Templates for CSPM

Policy Templates for CSPM are used with: 

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.

 

  • Was this article helpful?