Policy Templates for EKS
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. |
Deprecated Policies
Policy Name | Resource | Benchmark | PCI DSS | HIPAA | NIST 800-53 | Policy Description |
---|---|---|---|---|---|---|
EKS: Argument read-only-port should be set to 0 for Kubelet Server | EKS | CIS Level 1 | 7.1 7.2, 7.2.1, 7.2.2, 7.2.3 | 164.312(a)(1),164.308(a)(3)(i),164.308(b)(1), 164.312(c)(1), 164.312(e)(1) | CM-3 | 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. |