Skip to main content
McAfee Enterprise MVISION Cloud

Policy Templates for EKS

Amazon Elastic Kubernetes Services (EKS)

The following Kubernetes policies apply to Amazon Elastic Kubernetes Service (EKS). 

MVISION Cloud supports the CIS Kubernetes Benchmark v1.4.1-07-17-2019 specification for auditing CSP managed clusters.

 

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. In a large multi-tenant cluster, 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 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 SecurityContextDeny denies the pod level SecurityContext customization. Any attempts to customize the SecurityContexts that are not explicitly defined in the Pod Security Policy (PSP) are blocked. This ensures that all the pods adhere to the PSP defined by your organization and you have a uniform pod level security posture.
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 API server communication contains sensitive parameters that should remain encrypted in transit. Configure the API server to serve only HTTPS traffic.
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 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 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.
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 permissions than their parent. There should be at least one PodSecurityPolicy (PSP) defined which does not permit containers to allow privilege escalation. The option exists (and is defaulted to true) to permit setuid binaries to run.
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 PodSecurityPolicy (PSP) defined which does not permit containers to share the host IPC namespace.
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 PodSecurityPolicy (PSP) defined which does not permit containers to share the host network namespace.
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 permissions outside of the container. There should be at least one PodSecurityPolicy (PSP) defined which does not permit containers to share the host PID namespace.
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 permissions 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 PodSecurityPolicy (PSP) defined which does not permit privileged containers.
EKS: Do not admit containers with dangerous capabilities 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   CM-3 Containers run with a default set of capabilities as assigned by the Container Runtime. By default this can include potentially dangerous capabilities. By default 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 PodSecurityPolicy (PSP) defined which prevents containers with the NET_RAW capability from launching.
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 PodSecurityPolicy (PSP) defined which does not permit root users in a container.
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: AppArmor Profile should be enabled if applicable in AWS EKS cluster hosts EKS     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. 
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: CPU priority should be set appropriately on containers in AWS EKS cluster hosts EKS       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. 
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: An user for the container should be created 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 Containers should run as a non-root user. 
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: memory usage for containers should be limited in AWS EKS cluster hosts 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 Docker Host: Containers should be restricted from acquiring additional previleges 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 you should restrict containers from acquiring additional permissions via suid or sgid. 
EKS Docker Host: PIDs cgroup limit should be used in AWS EKS cluster hosts 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 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: The 'on-failure' container restart policy should be set to '5' in AWS EKS cluster hosts EKS       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.
EKS Docker Host: Linux Kernel Capabilities should be restricted within containers in AWS EKS cluster hosts EKS       CM-3, SC-39 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.
EKS Docker Host: Container's root filesystem should be mounted as read only in AWS EKS cluster hosts 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 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: SELinux security options should be enabled if applicable in AWS EKS cluster hosts EKS     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 Docker Host: TLS authentication should be configured for docker daemon in AWS EKS cluster hosts 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 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: Aufs storage driver should not be used in AWS EKS cluster hosts EKS     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.
EKS Docker Host: Base device size should not be changed until needed in AWS EKS cluster hosts 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 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: A separate partition for containers should be created in AWS EKS cluster hosts EKS     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. 
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 Daemon json file permissions should be set to 644 or more restrictive 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 verify that the file permissions on the docker daemonfile are correctly set to 644 or more restrictively. 
EKS Docker Host: Daemon.json file ownership should set to root:root 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 verify that the daemon.json file individual ownership and group ownership is correctly set to root. 
EKS Docker Host: Version of Docker should be kept up to date in AWS EKS cluster hosts EKS       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.
EKS Docker Host: Docker.socket file permissions should be set to 644 or more restrictive 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 verify that the file permissions on the docker.socket file are correctly set to 644 or more restrictively. 
EKS Docker Host: Docker.socket file ownership should be set to root 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 verify that the docker.socket file ownership and group ownership are correctly set to root. 
EKS Docker Host: Docker host socket should not be mounted inside any 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 Docker socket docker.sock should not be mounted inside a container.
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: Docker Host's IPC namespace should not be shared 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 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 Docker Host: Docker host's network namespace should not be shared 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 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. "
EKS Docker Host: host system directories should not be mounted on containers in AWS EKS cluster hosts EKS       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 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: Logging level should be set to info in AWS EKS cluster hosts EKS     164.308(a)(1)(ii)(D) CM-3, SC-39 Set Docker daemon log level to info. 
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 Docker Host: Trusted users should be allowed to control Docker daemon 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 Docker daemon currently requires access to the Docker socket which is, by default, owned by the user root and the group docker. 
EKS Docker Host: UTS namespace should not be shared in AWS EKS cluster hosts EKS       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. 
  • Was this article helpful?