Description: Security is a shared responsibility between AWS and the Amazon EKS customer. The shared responsibility model describes this as security of the cloud and security in the cloud: Security of the cloud – AWS is responsible for protecting the infrastructure that runs AWS services in the AWS Cloud. For Amazon EKS, AWS is responsible for the Kubernetes control plane, which includes the control plane nodes and etcd database. Third-party auditors regularly test and verify the effectiveness of our security as part of the AWS compliance programs. To learn about the compliance programs that apply to Amazon EKS, see AWS Services in Scope by Compliance Program. Security in the cloud – Your responsibility includes the following areas. - The security configuration of the data plane, including the configuration of the security groups that allow traffic to pass from the Amazon EKS control plane into the customer VPC - The configuration of the worker nodes and the containers themselves - The worker node guest operating system (including updates and security patches) - Amazon EKS follows the shared responsibility model for CVEs and security patches on managed node groups. Because managed nodes run the Amazon EKS-optimized AMIs, Amazon EKS is responsible for building patched versions of these AMIs when bugs or issues are reported and we are able to publish a fix. However, customers are responsible for deploying these patched AMI versions to your managed node groups. - Other associated application software: - Setting up and managing network controls, such as firewall rules - Managing platform-level identity and access management, either with or in addition to IAM - The sensitivity of your data, your company’s requirements, and applicable laws and regulations AWS is responsible for securing the control plane, though you might be able to configure certain options based on your requirements.
Levels:Automated: no
No rules selected
Description: Description: The audit logs are part of the EKS managed Kubernetes control plane logs that are managed by Amazon EKS. Amazon EKS is integrated with AWS CloudTrail, a service that provides a record of actions taken by a user, role, or an AWS service in Amazon EKS. CloudTrail captures all API calls for Amazon EKS as events. The calls captured include calls from the Amazon EKS console and code calls to the Amazon EKS API operations. Rationale: Exporting logs and metrics to a dedicated, persistent datastore such as CloudTrail ensures availability of audit data following a cluster security event, and provides a central location for analysis of log and metric data collated from multiple sources.
Levels:Automated: no
Selections:Description: None
Levels:Automated: no
Selections:Description: This section contains recommendations for Amazon EKS control plane logging configuration. Customers are able to configure logging for control plane in Amazon EKS.
Levels:Automated: no
Selections:Description: Description: If kubelet is running, and if it is using a file-based kubeconfig file, ensure that the proxy kubeconfig file has permissions of 644 or more restrictive. Rationale: The kubelet kubeconfig file controls various parameters of the kubelet service in the worker node. You should restrict its file permissions to maintain the integrity of the file. The file should be writable by only the administrators on the system. It is possible to run kubelet with the kubeconfig parameters configured as a Kubernetes ConfigMap instead of a file. In this case, there is no proxy kubeconfig file.
Levels:Automated: yes
Selections:Description: Description: If kubelet is running, ensure that the file ownership of its kubeconfig file is set to root:root. Rationale: The kubeconfig file for kubelet controls various parameters for the kubelet service in the worker node. You should set its file ownership to maintain the integrity of the file. The file should be owned by root:root.
Levels:Automated: yes
Selections:Description: Description: Ensure that if the kubelet refers to a configuration file with the --config argument, that file has permissions of 644 or more restrictive. Rationale: The kubelet reads various parameters, including security settings, from a config file specified by the --config argument. If this file is specified you should restrict its file permissions to maintain the integrity of the file. The file should be writable by only the administrators on the system.
Levels:Automated: yes
Selections:Description: Description: Ensure that if the kubelet refers to a configuration file with the --config argument, that file is owned by root:root. Rationale: The kubelet reads various parameters, including security settings, from a config file specified by the --config argument. If this file is specified you should restrict its file permissions to maintain the integrity of the file. The file should be writable by only the administrators on the system.
Levels:Automated: yes
Selections:Description: This section covers recommendations for configuration files on Amazon EKS worker nodes.
Levels:Automated: yes
Selections:Description: Description: Disable anonymous requests to the Kubelet server. Rationale: 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.
Levels:Automated: yes
Selections:Description: Description: Do not allow all requests. Enable explicit authorization. Rationale: 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.
Levels:Automated: yes
Selections:Description: Description: Enable Kubelet authentication using certificates. Rationale: 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.
Levels:Automated: yes
Selections:Description: Description: Disable the read-only port. Rationale: 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.
Levels:Automated: yes
Selections:Description: Description: Do not disable timeouts on streaming connections. Rationale: Setting idle timeouts ensures that you are protected against Denial-of-Service attacks, inactive connections and running out of ephemeral ports. Note: 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.
Levels:Automated: yes
Selections:Description: Description: Protect tuned kernel parameters from overriding kubelet default kernel parameter values. Rationale: 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.
Levels:Automated: yes
Selections:Description: Description: Allow Kubelet to manage iptables. Rationale: 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.
Levels:Automated: yes
Selections:Description: Description: Do not override node hostnames. Rationale: Overriding hostnames could potentially break TLS setup between the kubelet and the apiserver. Additionally, with overridden hostnames, it becomes increasingly difficult to associate logs with a particular node and process them for security analytics. Hence, you should setup your kubelet nodes with resolvable FQDNs and avoid overriding the hostnames with IPs.
Levels:Automated: yes
Selections:Description: Description: Security relevant information should be captured. The --eventRecordQPS flag on the Kubelet can be used to limit the rate at which events are gathered. Setting this too low could result in relevant events not being logged, however the unlimited setting of 0 could result in a denial of service on the kubelet. Rationale: 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.
Levels:Automated: no
No rules selected
Description: Description: Enable kubelet client certificate rotation. Rationale: 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 is no downtime due to expired certificates and thus addressing availability in the CIA security triad.
Levels:Automated: yes
Selections:Description: Description: Enable kubelet server certificate rotation. Rationale: 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. Note: 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.
Levels:Automated: yes
Selections:Description: This section contains recommendations for kubelet configuration. Kubelet settings may be configured using arguments on the running kubelet executable, or they may be taken from a Kubelet config file. If both are specified, the executable argument takes precedence. To find the Kubelet config file, run the following command: ps -ef | grep kubelet | grep config If the --config argument is present, this gives the location of the Kubelet config file. This config file could be in JSON or YAML format depending on your distribution.
Levels:Automated: yes
Selections:Description: This section consists of security recommendations for the components that run on Amazon EKS worker nodes.
Levels:Automated: yes
Selections:Description: Description: The RBAC role cluster-admin provides wide-ranging powers over the environment and should be used only where and when needed. Rationale: Kubernetes provides a set of default roles where RBAC is used. Some of these roles such as cluster-admin provide wide-ranging privileges which should only be applied where absolutely necessary. Roles such as cluster-admin allow super-user access to perform any action on any resource. When used in a ClusterRoleBinding, it gives full control over every resource in the cluster and in all namespaces. When used in a RoleBinding, it gives full control over every resource in the rolebinding's namespace, including the namespace itself.
Levels:Automated: no
No rules selected
Description: Description: The Kubernetes API stores secrets, which may be service account tokens for the Kubernetes API or credentials used by workloads in the cluster. Access to these secrets should be restricted to the smallest possible group of users to reduce the risk of privilege escalation. Rationale: Inappropriate access to secrets stored within the Kubernetes cluster can allow for an attacker to gain additional access to the Kubernetes cluster or external resources whose credentials are stored as secrets.
Levels:Automated: no
No rules selected
Description: Description: Kubernetes Roles and ClusterRoles provide access to resources based on sets of objects and actions that can be taken on those objects. It is possible to set either of these to be the wildcard "*" which matches all items. Use of wildcards is not optimal from a security perspective as it may allow for inadvertent access to be granted when new resources are added to the Kubernetes API either as CRDs or in later versions of the product. Rationale: The principle of least privilege recommends that users are provided only the access required for their role and nothing more. The use of wildcard rights grants is likely to provide excessive rights to the Kubernetes API.
Levels:Automated: no
No rules selected
Description: Description: The ability to create pods in a namespace can provide a number of opportunities for privilege escalation, such as assigning privileged service accounts to these pods or mounting hostPaths with access to sensitive data (unless Pod Security Policies are implemented to restrict this access) As such, access to create new pods should be restricted to the smallest possible group of users. Rationale: The ability to create pods in a cluster opens up possibilities for privilege escalation and should be restricted, where possible.
Levels:Automated: no
No rules selected
Description: Description: The default service account should not be used to ensure that rights granted to applications can be more easily audited and reviewed. Rationale: Kubernetes provides a default service account which is used by cluster workloads where no specific service account is assigned to the pod. Where access to the Kubernetes API from a pod is required, a specific service account should be created for that pod, and rights granted to that service account. The default service account should be configured such that it does not provide a service account token and does not have any explicit rights assignments.
Levels:Automated: no
No rules selected
Description: Description: Service accounts tokens should not be mounted in pods except where the workload running in the pod explicitly needs to communicate with the API server Rationale: Mounting service account tokens inside pods can provide an avenue for privilege escalation attacks where an attacker is able to compromise a single pod in the cluster. Avoiding mounting these tokens removes this attack avenue.
Levels:Automated: no
No rules selected
Description: None
Levels:Automated: no
No rules selected
Description: None
Levels:Automated: no
No rules selected
Description: None
Levels:Automated: no
No rules selected
Description: None
Levels:Automated: no
No rules selected
Description: None
Levels:Automated: no
No rules selected
Description: None
Levels:Automated: no
No rules selected
Description: None
Levels:Automated: no
No rules selected
Description: None
Levels:Automated: no
No rules selected
Description: None
Levels:Automated: no
No rules selected
Description: None
Levels:Automated: no
No rules selected
Description: None
Levels:Automated: no
No rules selected
Description: None
Levels:Automated: no
No rules selected
Description: Description: Use network policies to isolate traffic in your cluster network. Rationale: Running different applications on the same Kubernetes cluster creates a risk of one compromised application attacking a neighboring application. Network segmentation is important to ensure that containers can communicate only with those they are supposed to. A network policy is a specification of how selections of pods are allowed to communicate with each other and other network endpoints. Network Policies are namespace scoped. When a network policy is introduced to a given namespace, all traffic not allowed by the policy is denied. However, if there are no network policies in a namespace all traffic will be allowed into and out of the pods in that namespace.
Levels:Automated: yes
Selections:Description: None
Levels:Automated: no
Selections:Description: None
Levels:Automated: no
No rules selected
Description: None
Levels:Automated: no
No rules selected
Description: None
Levels:Automated: no
No rules selected
Description: None
Levels:Automated: no
No rules selected
Description: None
Levels:Automated: no
No rules selected
Description: None
Levels:Automated: no
No rules selected
Description: None
Levels:Automated: no
No rules selected
Description: None
Levels:Automated: no
No rules selected
Description: None
Levels:Automated: no
No rules selected
Description: This section contains recommendations for various Kubernetes policies which are important to the security of Amazon EKS customer environment.
Levels:Automated: no
Selections:Description: Description: Scan images being deployed to Amazon EKS for vulnerabilities. Rationale: Vulnerabilities in software packages can be exploited by hackers or malicious users to obtain unauthorized access to local cloud resources. Amazon ECR and other third party products allow images to be scanned for known vulnerabilities.
Levels:Automated: no
Selections:Description: Description: Restrict user access to Amazon ECR, limiting interaction with build images to only authorized personnel and service accounts. Rationale: Weak access control to Amazon ECR may allow malicious users to replace built images with vulnerable containers.
Levels:Automated: no
Selections:Description: Description: Configure the Cluster Service Account with Storage Object Viewer Role to only allow read- only access to Amazon ECR. Rationale: The Cluster Service Account does not require administrative access to Amazon ECR, only requiring pull access to containers to deploy onto Amazon EKS. Restricting permissions follows the principles of least privilege and prevents credentials from being abused beyond the required role.
Levels:Automated: no
Selections:Description: Description: Use approved container registries. Rationale: Allowing unrestricted access to external container registries provides the opportunity for malicious or unapproved containers to be deployed into the cluster. Allowlisting only approved container registries reduces this risk.
Levels:Automated: no
Selections:Description: This section contains recommendations relating to container image registries and securing images in those registries, such as Amazon Elastic Container Registry (ECR).
Levels:Automated: no
Selections:Description: Description: Kubernetes workloads should not use cluster node service accounts to authenticate to Amazon EKS APIs. Each Kubernetes workload that needs to authenticate to other AWS services using AWS IAM should be provisioned with a dedicated Service account. Rationale: Manual approaches for authenticating Kubernetes workloads running on Amazon EKS against AWS APIs are: storing service account keys as a Kubernetes secret (which introduces manual key rotation and potential for key compromise); or use of the underlying nodes' IAM Service account, which violates the principle of least privilege on a multi-tenanted node, when one pod needs to have access to a service, but every other pod on the node that uses the Service account does not.
Levels:Automated: no
Selections:Description: None
Levels:Automated: no
Selections:Description: Description: Encrypt Kubernetes secrets, stored in etcd, using secrets encryption feature during Amazon EKS cluster creation. Rationale: Kubernetes can store secrets that pods can access via a mounted volume. Today, Kubernetes secrets are stored with Base64 encoding, but encrypting is the recommended approach. Amazon EKS clusters version 1.13 and higher support the capability of encrypting your Kubernetes secrets using AWS Key Management Service (KMS) Customer Managed Keys (CMK). The only requirement is to enable the encryption provider support during EKS cluster creation. Use AWS Key Management Service (KMS) keys to provide envelope encryption of Kubernetes secrets stored in Amazon EKS. Implementing envelope encryption is considered a security best practice for applications that store sensitive data and is part of a defense in depth security strategy. Application-layer Secrets Encryption provides an additional layer of security for sensitive data, such as user defined Secrets and Secrets required for the operation of the cluster, such as service account keys, which are all stored in etcd. Using this functionality, you can use a key, that you manage in AWS KMS, to encrypt data at the application layer. This protects against attackers in the event that they manage to gain access to etcd.
Levels:Automated: no
Selections:Description: None
Levels:Automated: no
Selections:Description: Description: Enable Endpoint Private Access to restrict access to the cluster's control plane to only an allowlist of authorized IPs. Rationale: Authorized networks are a way of specifying a restricted range of IP addresses that are permitted to access your cluster's control plane. Kubernetes Engine uses both Transport Layer Security (TLS) and authentication to provide secure access to your cluster's control plane from the public internet. This provides you the flexibility to administer your cluster from anywhere; however, you might want to further restrict access to a set of IP addresses that you control. You can set this restriction by specifying an authorized network. Restricting access to an authorized network can provide additional security benefits for your container cluster, including: * Better protection from outsider attacks: Authorized networks provide an additional layer of security by limiting external access to a specific set of addresses you designate, such as those that originate from your premises. This helps protect access to your cluster in the case of a vulnerability in the cluster's authentication or authorization mechanism. * Better protection from insider attacks: Authorized networks help protect your cluster from accidental leaks of master certificates from your company's premises. Leaked certificates used from outside Amazon EC2 and outside the authorized IP ranges (for example, from addresses outside your company) are still denied access.
Levels:Automated: no
Selections:Description: Description: Disable access to the Kubernetes API from outside the node network if it is not required. Rationale: In a private cluster, the master node has two endpoints, a private and public endpoint. The private endpoint is the internal IP address of the master, behind an internal load balancer in the master's VPC network. Nodes communicate with the master using the private endpoint. The public endpoint enables the Kubernetes API to be accessed from outside the master's VPC network. Although Kubernetes API requires an authorized token to perform sensitive actions, a vulnerability could potentially expose the Kubernetes publicly with unrestricted access. Additionally, an attacker may be able to identify the current cluster and Kubernetes API version and determine whether it is vulnerable to an attack. Unless required, disabling public endpoint will help prevent such threats, and require the attacker to be on the master's VPC network to perform any attack on the Kubernetes API.
Levels:Automated: no
Selections:Description: Description: Disable public IP addresses for cluster nodes, so that they only have private IP addresses. Private Nodes are nodes with no public IP addresses. Rationale: Disabling public IP addresses on cluster nodes restricts access to only internal networks, forcing attackers to obtain local network access before attempting to compromise the underlying Kubernetes hosts.
Levels:Automated: no
Selections:Description: Description: Use Network Policy to restrict pod to pod traffic within a cluster and segregate workloads. Rationale: By default, all pod to pod traffic within a cluster is allowed. Network Policy creates a pod-level firewall that can be used to restrict traffic between sources. Pod traffic is restricted by having a Network Policy that selects it (through the use of labels). Once there is any Network Policy in a namespace selecting a particular pod, that pod will reject any connections that are not allowed by any Network Policy. Other pods in the namespace that are not selected by any Network Policy will continue to accept all traffic. Network Policies are managed via the Kubernetes Network Policy API and enforced by a network plugin, simply creating the resource without a compatible network plugin to implement it will have no effect. EKS supports Network Policy enforcement through the use of Calico.
Levels:Automated: no
Selections:Description: Description: Encrypt traffic to HTTPS load balancers using TLS certificates. Rationale: Encrypting traffic between users and your Kubernetes workload is fundamental to protecting data sent over the web.
Levels:Automated: no
Selections:Description: None
Levels:Automated: no
Selections:Description: Description: Amazon EKS uses IAM to provide authentication to your Kubernetes cluster through the AWS IAM Authenticator for Kubernetes. You can configure the stock kubectl client to work with Amazon EKS by installing the AWS IAM Authenticator for Kubernetes and modifying your kubectl configuration file to use it for authentication. Rationale: On- and off-boarding users is often difficult to automate and prone to error. Using a single source of truth for user permissions reduces the number of locations that an individual must be off-boarded from, and prevents users gaining unique permissions sets that increase the cost of audit.
Levels:Automated: no
Selections:Description: None
Levels:Automated: no
Selections:Description: Description: It is Best Practice to restrict or fence untrusted workloads when running in a multi-tenant environment. Rationale: AWS Fargate is a technology that provides on-demand, right-sized compute capacity for containers. With AWS Fargate, you no longer have to provision, configure, or scale groups of virtual machines to run containers. This removes the need to choose server types, decide when to scale your node groups, or optimize cluster packing. You can control which pods start on Fargate and how they run with Fargate profiles, which are defined as part of your Amazon EKS cluster. Amazon EKS integrates Kubernetes with AWS Fargate by using controllers that are built by AWS using the upstream, extensible model provided by Kubernetes. These controllers run as part of the Amazon EKS managed Kubernetes control plane and are responsible for scheduling native Kubernetes pods onto Fargate. The Fargate controllers include a new scheduler that runs alongside the default Kubernetes scheduler in addition to several mutating and validating admission controllers. When you start a pod that meets the criteria for running on Fargate, the Fargate controllers running in the cluster recognize, update, and schedule the pod onto Fargate. Each pod running on Fargate has its own isolation boundary and does not share the underlying kernel, CPU resources, memory resources, or elastic network interface with another pod.
Levels:Automated: no
Selections:Description: None
Levels:Automated: no
Selections:Description: This section consists of security recommendations for the Amazon EKS. These recommendations are applicable for configurations that Amazon EKS customers own and manage.
Levels:Automated: no
Selections: