{"id": "cis_eks", "policy": "CIS", "title": "Configuration Recommendations of an EKS System", "source": "https://www.cisecurity.org/cis-benchmarks/", "definition_location": "/aptdata/openscap/scap-security-guide/controls/cis_eks.yml", "controls": [{"id": "1", "levels": ["level_1"], "notes": "As noted, evaluating the security of the control plane is not the\nresponsibility of customers or deployers, but of Amazon instead. Thus, this\nprofile will not implement controls from Section 1.", "title": "1 Control Plane Components", "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:\n\nSecurity of the cloud \u2013 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.\n\nSecurity in the cloud \u2013 Your responsibility includes the following areas.\n\n    - 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\n\n    - The configuration of the worker nodes and the containers themselves\n\n    - The worker node guest operating system (including updates and security patches)\n        - Amazon EKS follows the shared responsibility model for CVEs and security patches on managed node groups. Because managed nodes run the Amazon\n          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.\n\n    - Other associated application software:\n\n      - Setting up and managing network controls, such as firewall rules\n\n      - Managing platform-level identity and access management, either with or in addition to IAM\n\n    - The sensitivity of your data, your company\u2019s requirements, and applicable laws and regulations\n\nAWS is responsible for securing the control plane, though you might be able to configure certain options based on your requirements.", "rationale": null, "automated": "no", "status": "not applicable", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "2.1.1", "levels": ["level_1"], "notes": "Automating this check requires access to AWS endpoints, the aws or\neksctl client, the EKS cluster name, and the cluster region. It's not\nfeasible to automate this check until we find a way to incorporate the\ninformation we need and use it to check AWS using the API. For now,\nthis must be checked manually.", "title": "2.1.1 Enable audit Logs", "description": "Description:\n\nThe audit logs are part of the EKS managed Kubernetes control plane logs that are managed\nby Amazon EKS. Amazon EKS is integrated with AWS CloudTrail, a service that provides a\nrecord of actions taken by a user, role, or an AWS service in Amazon EKS. CloudTrail\ncaptures all API calls for Amazon EKS as events. The calls captured include calls from the\nAmazon EKS console and code calls to the Amazon EKS API operations.\n\nRationale:\n\nExporting logs and metrics to a dedicated, persistent datastore such as CloudTrail ensures\navailability of audit data following a cluster security event, and provides a central location\nfor analysis of log and metric data collated from multiple sources.", "rationale": null, "automated": "no", "status": "manual", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "2.1", "levels": ["level_1"], "notes": "", "title": "2.1 Logging", "description": null, "rationale": null, "automated": "no", "status": "manual", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": ["2.1.1"]}, {"id": "2", "levels": ["level_1"], "notes": "", "title": "2 Control Plane Configuration", "description": "This section contains recommendations for Amazon EKS control plane logging\nconfiguration. Customers are able to configure logging for control plane in\nAmazon EKS.", "rationale": null, "automated": "no", "status": "manual", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": ["2.1.1", "2.1"]}, {"id": "3.1.1", "levels": ["level_1"], "notes": "The default permissions are acceptable based on the control's description\nand rationale.", "title": "3.1.1 Ensure that the kubeconfig file permissions are set to 644 or more restrictive", "description": "Description:\n\nIf kubelet is running, and if it is using a file-based kubeconfig file, ensure that the proxy\nkubeconfig file has permissions of 644 or more restrictive.\n\nRationale:\n\nThe kubelet kubeconfig file controls various parameters of the kubelet service in the\nworker node. You should restrict its file permissions to maintain the integrity of the file.\nThe file should be writable by only the administrators on the system.\nIt is possible to run kubelet with the kubeconfig parameters configured as a Kubernetes\nConfigMap instead of a file. In this case, there is no proxy kubeconfig file.", "rationale": null, "automated": "yes", "status": "automated", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "3.1.2", "levels": ["level_1"], "notes": "", "title": "3.1.2 Ensure that the kubelet kubeconfig file ownership is set to root:root", "description": "Description:\n\nIf kubelet is running, ensure that the file ownership of its kubeconfig file is set to\nroot:root.\n\nRationale:\n\nThe kubeconfig file for kubelet controls various parameters for the kubelet service in the\nworker node. You should set its file ownership to maintain the integrity of the file. The file\nshould be owned by root:root.", "rationale": null, "automated": "yes", "status": "automated", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "3.1.3", "levels": ["level_1"], "notes": "", "title": "3.1.3 Ensure that the kubelet configuration file has permissions set to 644 or more restrictive", "description": "Description:\n\nEnsure that if the kubelet refers to a configuration file with the --config argument, that file\nhas permissions of 644 or more restrictive.\n\nRationale:\n\nThe kubelet reads various parameters, including security settings, from a config file\nspecified by the --config argument. If this file is specified you should restrict its file\npermissions to maintain the integrity of the file. The file should be writable by only the\nadministrators on the system.", "rationale": null, "automated": "yes", "status": "automated", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "3.1.4", "levels": ["level_1"], "notes": "", "title": "3.1.4 Ensure that the kubelet configuration file ownership is set to root:root", "description": "Description:\nEnsure that if the kubelet refers to a configuration file with the --config argument, that file\nis owned by root:root.\n\nRationale:\n\nThe kubelet reads various parameters, including security settings, from a config file\nspecified by the --config argument. If this file is specified you should restrict its file\npermissions to maintain the integrity of the file. The file should be writable by only the\nadministrators on the system.", "rationale": null, "automated": "yes", "status": "automated", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "3.1", "levels": ["level_2"], "notes": "", "title": "3.1 Worker Node Configuration Files", "description": "This section covers recommendations for configuration files on Amazon EKS worker nodes.", "rationale": null, "automated": "yes", "status": "automated", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": ["3.1.1", "3.1.2", "3.1.3", "3.1.4"]}, {"id": "3.2.1", "levels": ["level_1"], "notes": "", "title": "3.2.1 Ensure that the --anonymous-auth argument is set to false", "description": "Description:\n\nDisable anonymous requests to the Kubelet server.\n\nRationale:\n\nWhen enabled, requests that are not rejected by other configured authentication methods\nare treated as anonymous requests. These requests are then served by the Kubelet server.\nYou should rely on authentication to authorize access and disallow anonymous requests.", "rationale": null, "automated": "yes", "status": "automated", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "3.2.2", "levels": ["level_1"], "notes": "", "title": "3.2.2 Ensure that the --authorization-mode argument is not set to AlwaysAllow", "description": "Description:\n\nDo not allow all requests. Enable explicit authorization.\n\nRationale:\n\nKubelets, by default, allow all authenticated requests (even anonymous ones) without\nneeding explicit authorization checks from the apiserver. You should restrict this behavior\nand only allow explicitly authorized requests.", "rationale": null, "automated": "yes", "status": "automated", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "3.2.3", "levels": ["level_1"], "notes": "", "title": "3.2.3 Ensure that the --client-ca-file argument is set as appropriate", "description": "Description:\n\nEnable Kubelet authentication using certificates.\n\nRationale:\n\nThe connections from the apiserver to the kubelet are used for fetching logs for pods,\nattaching (through kubectl) to running pods, and using the kubelet\u2019s port-forwarding\nfunctionality. These connections terminate at the kubelet\u2019s HTTPS endpoint. By default, the\napiserver does not verify the kubelet\u2019s serving certificate, which makes the connection\nsubject to man-in-the-middle attacks, and unsafe to run over untrusted and/or public\nnetworks. Enabling Kubelet certificate authentication ensures that the apiserver could authenticate the Kubelet before submitting any requests.", "rationale": null, "automated": "yes", "status": "automated", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "3.2.4", "levels": ["level_1"], "notes": "", "title": "3.2.4 Ensure that the --read-only-port is secured", "description": "Description:\n\nDisable the read-only port.\n\nRationale:\n\nThe Kubelet process provides a read-only API in addition to the main Kubelet API.\nUnauthenticated access is provided to this read-only API which could possibly retrieve\npotentially sensitive information about the cluster.", "rationale": null, "automated": "yes", "status": "automated", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "3.2.5", "levels": ["level_1"], "notes": "", "title": "3.2.5 Ensure that the --streaming-connection-idle-timeout argument is not set to 0", "description": "Description:\n\nDo not disable timeouts on streaming connections.\n\nRationale:\n\nSetting idle timeouts ensures that you are protected against Denial-of-Service attacks,\ninactive connections and running out of ephemeral ports.\nNote: By default, --streaming-connection-idle-timeout is set to 4 hours which might be\ntoo high for your environment. Setting this as appropriate would additionally ensure that\nsuch streaming connections are timed out after serving legitimate use cases.", "rationale": null, "automated": "yes", "status": "automated", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "3.2.6", "levels": ["level_1"], "notes": "", "title": "3.2.6 Ensure that the --protect-kernel-defaults argument is set to true", "description": "Description:\n\nProtect tuned kernel parameters from overriding kubelet default kernel parameter values.\n\nRationale:\n\nKernel parameters are usually tuned and hardened by the system administrators before\nputting the systems into production. These parameters protect the kernel and the system.\nYour kubelet kernel defaults that rely on such parameters should be appropriately set to\nmatch the desired secured system state. Ignoring this could potentially lead to running\npods with undesired kernel behavior.", "rationale": null, "automated": "yes", "status": "automated", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "3.2.7", "levels": ["level_1"], "notes": "", "title": "3.2.7 Ensure that the --make-iptables-util-chains argument is set to true", "description": "Description:\n\nAllow Kubelet to manage iptables.\n\nRationale:\n\nKubelets can automatically manage the required changes to iptables based on how you\nchoose your networking options for the pods. It is recommended to let kubelets manage\nthe changes to iptables. This ensures that the iptables configuration remains in sync with\npods networking configuration. Manually configuring iptables with dynamic pod network\nconfiguration changes might hamper the communication between pods/containers and to\nthe outside world. You might have iptables rules too restrictive or too open.", "rationale": null, "automated": "yes", "status": "automated", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "3.2.8", "levels": ["level_1"], "notes": "", "title": "3.2.8 Ensure that the --hostname-override argument is not set", "description": "Description:\n\nDo not override node hostnames.\n\nRationale:\n\nOverriding hostnames could potentially break TLS setup between the kubelet and the\napiserver. Additionally, with overridden hostnames, it becomes increasingly difficult to\nassociate logs with a particular node and process them for security analytics. Hence, you\nshould setup your kubelet nodes with resolvable FQDNs and avoid overriding the\nhostnames with IPs.", "rationale": null, "automated": "yes", "status": "automated", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "3.2.9", "levels": ["level_2"], "notes": "", "title": "3.2.9 Ensure that the --eventRecordQPS argument is set to 0 or a level which ensures appropriate event capture", "description": "Description:\n\nSecurity relevant information should be captured. The --eventRecordQPS flag on the\nKubelet can be used to limit the rate at which events are gathered. Setting this too low\ncould result in relevant events not being logged, however the unlimited setting of 0 could\nresult in a denial of service on the kubelet.\n\nRationale:\n\nIt is important to capture all events and not restrict event creation. Events are an important\nsource of security information and analytics that ensure that your environment is\nconsistently monitored using the event data.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "3.2.10", "levels": ["level_2"], "notes": "", "title": "3.2.10 Ensure that the --rotate-certificates argument is not set to false", "description": "Description:\n\nEnable kubelet client certificate rotation.\n\nRationale:\n\nThe --rotate-certificates setting causes the kubelet to rotate its client certificates by\ncreating new CSRs as its existing credentials expire. This automated periodic rotation\nensures that the there is no downtime due to expired certificates and thus addressing\navailability in the CIA security triad.", "rationale": null, "automated": "yes", "status": "automated", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "3.2.11", "levels": ["level_1"], "notes": "", "title": "3.2.11 Ensure that the RotateKubeletServerCertificate argument is set to true", "description": "Description:\n\nEnable kubelet server certificate rotation.\n\nRationale:\n\nRotateKubeletServerCertificate causes the kubelet to both request a serving certificate\nafter bootstrapping its client credentials and rotate the certificate as its existing credentials\nexpire. This automated periodic rotation ensures that the there are no downtimes due to\nexpired certificates and thus addressing availability in the CIA security triad.\n\nNote: This recommendation only applies if you let kubelets get their certificates from the\nAPI server. In case your kubelet certificates come from an outside authority/tool (e.g.\nVault) then you need to take care of rotation yourself.", "rationale": null, "automated": "yes", "status": "automated", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "3.2", "levels": ["level_2"], "notes": "", "title": "3.2 Kubelet", "description": "This section contains recommendations for kubelet configuration.\n\nKubelet settings may be configured using arguments on the running kubelet executable, or\nthey may be taken from a Kubelet config file. If both are specified, the executable argument\ntakes precedence.\n\nTo find the Kubelet config file, run the following command:\n\n    ps -ef | grep kubelet | grep config\n\nIf the --config argument is present, this gives the location of the Kubelet config file. This\nconfig file could be in JSON or YAML format depending on your distribution.", "rationale": null, "automated": "yes", "status": "automated", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": ["3.2.1", "3.2.2", "3.2.3", "3.2.4", "3.2.5", "3.2.6", "3.2.7", "3.2.8", "3.2.9", "3.2.10", "3.2.11"]}, {"id": "3", "levels": ["level_2"], "notes": "", "title": "3 Worker Nodes", "description": "This section consists of security recommendations for the components that run on Amazon\nEKS worker nodes.", "rationale": null, "automated": "yes", "status": "automated", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": ["3.1.1", "3.1.2", "3.1.3", "3.1.4", "3.1", "3.2.1", "3.2.2", "3.2.3", "3.2.4", "3.2.5", "3.2.6", "3.2.7", "3.2.8", "3.2.9", "3.2.10", "3.2.11", "3.2"]}, {"id": "4.1.1", "levels": ["level_1"], "notes": "This check is manual because it requires deployment-specific knowledge\nabout users and their authorization.", "title": "4.1.1 Ensure that the cluster-admin role is only used where required", "description": "Description:\n\n  The RBAC role cluster-admin provides wide-ranging powers over the\n  environment and should be used only where and when needed.\n\nRationale:\n\n  Kubernetes provides a set of default roles where RBAC is used. Some\n  of these roles such as cluster-admin provide wide-ranging privileges\n  which should only be applied where absolutely necessary. Roles such\n  as cluster-admin allow super-user access to perform any action on any\n  resource. When used in a ClusterRoleBinding, it gives full control\n  over every resource in the cluster and in all namespaces. When used\n  in a RoleBinding, it gives full control over every resource in the\n  rolebinding's namespace, including the namespace itself.", "rationale": null, "automated": "no", "status": "manual", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "4.1.2", "levels": ["level_1"], "notes": "This check is manual because it requires deployment-specific knowledge\nabout users and their authorization.", "title": "4.1.2 Minimize access to secrets", "description": "Description:\n\n  The Kubernetes API stores secrets, which may be service account\n  tokens for the Kubernetes API or credentials used by workloads in the\n  cluster. Access to these secrets should be restricted to the smallest\n  possible group of users to reduce the risk of privilege escalation.\n\nRationale:\n\n  Inappropriate access to secrets stored within the Kubernetes cluster\n  can allow for an attacker to gain additional access to the Kubernetes\n  cluster or external resources whose credentials are stored as\n  secrets.", "rationale": null, "automated": "no", "status": "manual", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "4.1.3", "levels": ["level_1"], "notes": "This check is manual because it requires deployment-specific knowledge\nto audit effectively. The Compliance Operator also uses wildcards for\nthe compliance-operator roles.", "title": "4.1.3 Minimize wildcard use in Roles and ClusterRoles", "description": "Description:\n\n  Kubernetes Roles and ClusterRoles provide access to resources based\n  on sets of objects and actions that can be taken on those objects. It\n  is possible to set either of these to be the wildcard \"*\" which\n  matches all items. Use of wildcards is not optimal from a security\n  perspective as it may allow for inadvertent access to be granted when\n  new resources are added to the Kubernetes API either as CRDs or in\n  later versions of the product.\n\nRationale:\n\n  The principle of least privilege recommends that users are provided\n  only the access required for their role and nothing more. The use of\n  wildcard rights grants is likely to provide excessive rights to the\n  Kubernetes API.", "rationale": null, "automated": "no", "status": "manual", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "4.1.4", "levels": ["level_1"], "notes": "This check is manual because it requires deployment-specific knowledge\nabout users and their authorization.", "title": "4.1.4 Minimize access to create pods", "description": "Description:\n\n  The ability to create pods in a namespace can provide a number of\n  opportunities for privilege escalation, such as assigning privileged\n  service accounts to these pods or mounting hostPaths with access to\n  sensitive data (unless Pod Security Policies are implemented to\n  restrict this access) As such, access to create new pods should be\n  restricted to the smallest possible group of users.\n\nRationale:\n\n  The ability to create pods in a cluster opens up possibilities for\n  privilege escalation and should be restricted, where possible.", "rationale": null, "automated": "no", "status": "manual", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "4.1.5", "levels": ["level_1"], "notes": "This check is manual because it requires deployment-specific knowledge\nabout each namespace in the deployment.", "title": "4.1.5 Ensure that default service accounts are not actively used.", "description": "Description:\n\n  The default service account should not be used to ensure that rights\n  granted to applications can be more easily audited and reviewed.\n\nRationale:\n\n  Kubernetes provides a default service account which is used by\n  cluster workloads where no specific service account is assigned to\n  the pod. Where access to the Kubernetes API from a pod is required, a\n  specific service account should be created for that pod, and rights\n  granted to that service account. The default service account should\n  be configured such that it does not provide a service account token\n  and does not have any explicit rights assignments.", "rationale": null, "automated": "no", "status": "manual", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "4.1.6", "levels": ["level_1"], "notes": "This check is manual because it requires deployment-specific knowledge\nabout each namespace and pod in the deployment.", "title": "4.1.6 Ensure that Service Account Tokens are only mounted where necessary", "description": "Description:\n\n  Service accounts tokens should not be mounted in pods except where\n  the workload running in the pod explicitly needs to communicate with\n  the API server\n\nRationale:\n\n  Mounting service account tokens inside pods can provide an avenue for\n  privilege escalation attacks where an attacker is able to compromise\n  a single pod in the cluster. Avoiding mounting these tokens removes\n  this attack avenue.", "rationale": null, "automated": "no", "status": "manual", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "4.1", "levels": ["level_2"], "notes": "", "title": "4.1 RBAC and Service Accounts", "description": null, "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": ["4.1.1", "4.1.2", "4.1.3", "4.1.4", "4.1.5", "4.1.6"]}, {"id": "4.2.1", "levels": ["level_1"], "notes": "", "title": "4.2.1 Minimize the admission of privileged containers", "description": null, "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "4.2.2", "levels": ["level_1"], "notes": "", "title": "4.2.2 Minimize the admission of containers wishing to share the host process ID namespace", "description": null, "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "4.2.3", "levels": ["level_1"], "notes": "", "title": "4.2.3 Minimize the admission of containers wishing to share the host IPC namespace", "description": null, "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "4.2.4", "levels": ["level_1"], "notes": "", "title": "4.2.4 Minimize the admission of containers wishing to share the host network namespace", "description": null, "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "4.2.5", "levels": ["level_1"], "notes": "", "title": "4.2.5 Minimize the admission of containers with allowPrivilegeEscalation", "description": null, "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "4.2.6", "levels": ["level_2"], "notes": "", "title": "4.2.6 Minimize the admission of root containers", "description": null, "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "4.2.7", "levels": ["level_1"], "notes": "", "title": "4.2.7 Minimize the admission of containers with the NET_RAW capability", "description": null, "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "4.2.8", "levels": ["level_1"], "notes": "", "title": "4.2.8 Minimize the admission of containers with added capabilities", "description": null, "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "4.2.9", "levels": ["level_2"], "notes": "", "title": "4.2.9 Minimize the admission of containers with capabilities assigned", "description": null, "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "4.2", "levels": ["level_2"], "notes": "", "title": "4.2 Pod Security Policies", "description": null, "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": ["4.2.1", "4.2.2", "4.2.3", "4.2.4", "4.2.5", "4.2.6", "4.2.7", "4.2.8", "4.2.9"]}, {"id": "4.3.1", "levels": ["level_1"], "notes": "", "title": "4.3.1 Ensure latest CNI version is used", "description": null, "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "4.3.2", "levels": ["level_2"], "notes": "We can verify this with the Compliance Operator and check that all\nnamespaces have at least a NetworkPolicy defined.", "title": "4.3.2 Ensure that all Namespaces have Network Policies defined", "description": "Description:\n\nUse network policies to isolate traffic in your cluster network.\n\nRationale:\n\nRunning different applications on the same Kubernetes cluster creates a risk of one\ncompromised application attacking a neighboring application. Network segmentation is\nimportant to ensure that containers can communicate only with those they are supposed\nto. A network policy is a specification of how selections of pods are allowed to\ncommunicate with each other and other network endpoints.\n\nNetwork Policies are namespace scoped. When a network policy is introduced to a given\nnamespace, all traffic not allowed by the policy is denied. However, if there are no network\npolicies in a namespace all traffic will be allowed into and out of the pods in that\nnamespace.", "rationale": null, "automated": "yes", "status": "automated", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "4.3", "levels": ["level_2"], "notes": "", "title": "4.3 CNI Plugin", "description": null, "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": ["4.3.1", "4.3.2"]}, {"id": "4.4.1", "levels": ["level_2"], "notes": "", "title": "4.4.1 Prefer using secrets as files over secrets as environment variables", "description": null, "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "4.4.2", "levels": ["level_2"], "notes": "", "title": "4.4.2 Consider external secret storage", "description": null, "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "4.4", "levels": ["level_2"], "notes": "", "title": "4.4 Secrets Management", "description": null, "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": ["4.4.1", "4.4.2"]}, {"id": "4.5.1", "levels": ["level_2"], "notes": "", "title": "4.5.1 Configure Image Provenance using ImagePolicyWebhook admission controller", "description": null, "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "4.5", "levels": ["level_2"], "notes": "", "title": "4.5 Extensible Admission Control", "description": null, "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": ["4.5.1"]}, {"id": "4.6.1", "levels": ["level_1"], "notes": "", "title": "4.6.1 Create administrative boundaries between resources using namespaces", "description": null, "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "4.6.2", "levels": ["level_2"], "notes": "", "title": "4.6.2 Apply Security Context to Your Pods and Containers", "description": null, "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "4.6.3", "levels": ["level_2"], "notes": "", "title": "4.6.3 The default namespace should not be used", "description": null, "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "4.6", "levels": ["level_2"], "notes": "", "title": "4.6 General Policies", "description": null, "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": ["4.6.1", "4.6.2", "4.6.3"]}, {"id": "4", "levels": ["level_2"], "notes": "", "title": "4 Policies", "description": "This section contains recommendations for various Kubernetes policies which\nare important to the security of Amazon EKS customer environment.", "rationale": null, "automated": "no", "status": "manual", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": ["4.1.1", "4.1.2", "4.1.3", "4.1.4", "4.1.5", "4.1.6", "4.1", "4.2.1", "4.2.2", "4.2.3", "4.2.4", "4.2.5", "4.2.6", "4.2.7", "4.2.8", "4.2.9", "4.2", "4.3.1", "4.3.2", "4.3", "4.4.1", "4.4.2", "4.4", "4.5.1", "4.5", "4.6.1", "4.6.2", "4.6.3", "4.6"]}, {"id": "5.1.1", "levels": ["level_1"], "notes": "", "title": "5.1.1 Ensure Image Vulnerability Scanning using Amazon ECR image scanning or a third party provider", "description": "Description:\n\nScan images being deployed to Amazon EKS for vulnerabilities.\n\nRationale:\n\nVulnerabilities in software packages can be exploited by hackers or\nmalicious users to obtain unauthorized access to local cloud resources.\nAmazon ECR and other third party products allow images to be scanned\nfor known vulnerabilities.", "rationale": null, "automated": "no", "status": "manual", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "5.1.2", "levels": ["level_1"], "notes": "", "title": "5.1.2 Minimize user access to Amazon ECR", "description": "Description:\n\nRestrict user access to Amazon ECR, limiting interaction with build\nimages to only authorized personnel and service accounts.\n\nRationale:\n\nWeak access control to Amazon ECR may allow malicious users to replace\nbuilt images with vulnerable containers.", "rationale": null, "automated": "no", "status": "manual", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "5.1.3", "levels": ["level_1"], "notes": "", "title": "5.1.3 Minimize cluster access to read-only for Amazon ECR", "description": "Description:\n\n  Configure the Cluster Service Account with Storage Object Viewer Role\n  to only allow read- only access to Amazon ECR.\n\nRationale:\n\n  The Cluster Service Account does not require administrative access to\n  Amazon ECR, only requiring pull access to containers to deploy onto\n  Amazon EKS. Restricting permissions follows the principles of least\n  privilege and prevents credentials from being abused beyond the\n  required role.", "rationale": null, "automated": "no", "status": "manual", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "5.1.4", "levels": ["level_2"], "notes": "", "title": "5.1.4 Minimize Container Registries to only those approved", "description": "Description:\n  Use approved container registries.\n\nRationale:\n\n  Allowing unrestricted access to external container registries\n  provides the opportunity for malicious or unapproved containers to be\n  deployed into the cluster. Allowlisting only approved container\n  registries reduces this risk.", "rationale": null, "automated": "no", "status": "manual", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "5.1", "levels": ["level_2"], "notes": "", "title": "5.1 Image Registry and Image Scanning", "description": "This section contains recommendations relating to container image\nregistries and securing images in those registries, such as Amazon\nElastic Container Registry (ECR).", "rationale": null, "automated": "no", "status": "manual", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": ["5.1.1", "5.1.2", "5.1.3", "5.1.4"]}, {"id": "5.2.1", "levels": ["level_1"], "notes": "This must be checked manually since it requires deployment-specific\nknowledge and requires network access to the AWS IAM endpoint.\nRe-evaluate this if or when we have the ability to use network\nconnections in rules.", "title": "5.2.1 Prefer using dedicated EKS Service Accounts", "description": "Description:\n\n  Kubernetes workloads should not use cluster node service accounts to\n  authenticate to Amazon EKS APIs. Each Kubernetes workload that needs\n  to authenticate to other AWS services using AWS IAM should be\n  provisioned with a dedicated Service account.\n\nRationale:\n\n  Manual approaches for authenticating Kubernetes workloads running on\n  Amazon EKS against AWS APIs are: storing service account keys as a\n  Kubernetes secret (which introduces manual key rotation and potential\n  for key compromise); or use of the underlying nodes' IAM Service\n  account, which violates the principle of least privilege on a\n  multi-tenanted node, when one pod needs to have access to a service,\n  but every other pod on the node that uses the Service account does\n  not.", "rationale": null, "automated": "no", "status": "manual", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "5.2", "levels": ["level_1"], "notes": "", "title": "5.2 Identity and Access Management (IAM)", "description": null, "rationale": null, "automated": "no", "status": "manual", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": ["5.2.1"]}, {"id": "5.3.1", "levels": ["level_1"], "notes": "This check is manual because it requires deployment-specific knowledge\nand access to the AWS KMS endpoint. Re-evaluate this if or when we have\nthe ability to use network connections in rules.", "title": "5.3.1 Ensure Kubernetes Secrets are encrypted using Customer Master Keys (CMKs) managed in AWS KMS", "description": "Description:\n\n  Encrypt Kubernetes secrets, stored in etcd, using secrets encryption\n  feature during Amazon EKS cluster creation.\n\nRationale:\n\n  Kubernetes can store secrets that pods can access via a mounted\n  volume. Today, Kubernetes secrets are stored with Base64 encoding,\n  but encrypting is the recommended approach. Amazon EKS clusters\n  version 1.13 and higher support the capability of encrypting your\n  Kubernetes secrets using AWS Key Management Service (KMS) Customer\n  Managed Keys (CMK). The only requirement is to enable the encryption\n  provider support during EKS cluster creation. Use AWS Key Management\n  Service (KMS) keys to provide envelope encryption of Kubernetes\n  secrets stored in Amazon EKS. Implementing envelope encryption is\n  considered a security best practice for applications that store\n  sensitive data and is part of a defense in depth security strategy.\n  Application-layer Secrets Encryption provides an additional layer of\n  security for sensitive data, such as user defined Secrets and Secrets\n  required for the operation of the cluster, such as service account\n  keys, which are all stored in etcd. Using this functionality, you can\n  use a key, that you manage in AWS KMS, to encrypt data at the\n  application layer. This protects against attackers in the event that\n  they manage to gain access to etcd.\n", "rationale": null, "automated": "no", "status": "manual", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "5.3", "levels": ["level_1"], "notes": "", "title": "5.3 AWS Key Management Service (KMS)", "description": null, "rationale": null, "automated": "no", "status": "manual", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": ["5.3.1"]}, {"id": "5.4.1", "levels": ["level_1"], "notes": "This check is manual because it requires deployment-specific knowledge\nand access to the AWS EKS endpoint. Re-evaluate this if or when we have\nthe ability to use network connections in rules.", "title": "5.4.1 Restrict Access to the Control Plane Endpoint", "description": "Description:\n\n  Enable Endpoint Private Access to restrict access to the cluster's\n  control plane to only an allowlist of authorized IPs.\n\nRationale:\n\n  Authorized networks are a way of specifying a restricted range of IP\n  addresses that are permitted to access your cluster's control plane.\n  Kubernetes Engine uses both Transport Layer Security (TLS) and\n  authentication to provide secure access to your cluster's control\n  plane from the public internet. This provides you the flexibility to\n  administer your cluster from anywhere; however, you might want to\n  further restrict access to a set of IP addresses that you control.\n  You can set this restriction by specifying an authorized network.\n  Restricting access to an authorized network can provide additional\n  security benefits for\n  your container cluster, including:\n    * Better protection from outsider attacks: Authorized networks\n      provide an additional layer of security by limiting external\n      access to a specific set of addresses you designate, such as\n      those that originate from your premises. This helps protect\n      access to your cluster in the case of a vulnerability in the\n      cluster's authentication or authorization mechanism.\n    * Better protection from insider attacks: Authorized networks help\n      protect your cluster from accidental leaks of master certificates\n      from your company's premises. Leaked certificates used from\n      outside Amazon EC2 and outside the authorized IP ranges (for\n      example, from addresses outside your company) are still denied\n      access.", "rationale": null, "automated": "no", "status": "manual", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "5.4.2", "levels": ["level_2"], "notes": "This check is manual because it requires deployment-specific knowledge\nand access to AWS endpoints. Re-evaluate this if or when we have the\nability to use network connections in rules.", "title": "5.4.2 Ensure clusters are created with Private Endpoint Enabled and Public Access Disabled", "description": "Description:\n\n  Disable access to the Kubernetes API from outside the node network if\n  it is not required.\n\nRationale:\n\n  In a private cluster, the master node has two endpoints, a private\n  and public endpoint. The private endpoint is the internal IP address\n  of the master, behind an internal load balancer in the master's VPC\n  network. Nodes communicate with the master using the private\n  endpoint. The public endpoint enables the Kubernetes API to be\n  accessed from outside the master's VPC network. Although Kubernetes\n  API requires an authorized token to perform sensitive actions, a\n  vulnerability could potentially expose the Kubernetes publicly with\n  unrestricted access. Additionally, an attacker may be able to\n  identify the current cluster and Kubernetes API version and determine\n  whether it is vulnerable to an attack. Unless required, disabling\n  public endpoint will help prevent such threats, and require the\n  attacker to be on the master's VPC network to perform any attack on\n  the Kubernetes API.", "rationale": null, "automated": "no", "status": "manual", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "5.4.3", "levels": ["level_1"], "notes": "This check is manual because it requires deployment-specific knowledge\nand access to AWS endpoints. Re-evaluate this if or when we have the\nability to use network connections in rules.", "title": "5.4.3 Ensure clusters are created with Private Nodes", "description": "Description:\n\n  Disable public IP addresses for cluster nodes, so that they only have\n  private IP addresses. Private Nodes are nodes with no public IP\n  addresses.\n\nRationale:\n\n  Disabling public IP addresses on cluster nodes restricts access to\n  only internal networks, forcing attackers to obtain local network\n  access before attempting to compromise the underlying Kubernetes\n  hosts.", "rationale": null, "automated": "no", "status": "manual", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "5.4.4", "levels": ["level_1"], "notes": "This check is manual because it requires deployment-specific knowledge.", "title": "5.4.4 Ensure Network Policy is Enabled and set as appropriate", "description": "Description:\n\n  Use Network Policy to restrict pod to pod traffic within a cluster\n  and segregate workloads.\n\nRationale:\n\n  By default, all pod to pod traffic within a cluster is allowed.\n  Network Policy creates a pod-level firewall that can be used to\n  restrict traffic between sources. Pod traffic is restricted by having\n  a Network Policy that selects it (through the use of labels). Once\n  there is any Network Policy in a namespace selecting a particular\n  pod, that pod will reject any connections that are not allowed by any\n  Network Policy. Other pods in the namespace that are not selected by\n  any Network Policy will continue to accept all traffic. Network\n  Policies are managed via the Kubernetes Network Policy API and\n  enforced by a network plugin, simply creating the resource without a\n  compatible network plugin to implement it will have no effect. EKS\n  supports Network Policy enforcement through the use of Calico.", "rationale": null, "automated": "no", "status": "manual", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "5.4.5", "levels": ["level_2"], "notes": "This check is manual because it requires access to the Kubernetes API\nserver configuration, which requires access to the Kubernetes API or\nthe AWS EKS configuration.", "title": "5.4.5 Encrypt traffic to HTTPS load balancers with TLS certificates", "description": "Description:\n\n  Encrypt traffic to HTTPS load balancers using TLS certificates.\n\nRationale:\n\n  Encrypting traffic between users and your Kubernetes workload is\n  fundamental to protecting data sent over the web.", "rationale": null, "automated": "no", "status": "manual", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "5.4", "levels": ["level_2"], "notes": "", "title": "5.4 Cluster Networking", "description": null, "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": ["5.4.1", "5.4.2", "5.4.3", "5.4.4", "5.4.5"]}, {"id": "5.5.1", "levels": ["level_2"], "notes": "This check is manual because it requires deployment-specific knowledge\nabout the namespaces to audit it effectively.", "title": "5.5.1 Manage Kubernetes RBAC users with AWS IAM Authenticator for Kubernetes", "description": "Description:\n\n  Amazon EKS uses IAM to provide authentication to your Kubernetes\n  cluster through the AWS IAM Authenticator for Kubernetes. You can\n  configure the stock kubectl client to work with Amazon EKS by\n  installing the AWS IAM Authenticator for Kubernetes and modifying\n  your kubectl configuration file to use it for authentication.\n\nRationale:\n\n  On- and off-boarding users is often difficult to automate and prone\n  to error. Using a single source of truth for user permissions reduces\n  the number of locations that an individual must be off-boarded from,\n  and prevents users gaining unique permissions sets that increase the\n  cost of audit.", "rationale": null, "automated": "no", "status": "manual", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "5.5", "levels": ["level_2"], "notes": "", "title": "5.5 Authentication and Authorization", "description": null, "rationale": null, "automated": "no", "status": "manual", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": ["5.5.1"]}, {"id": "5.6.1", "levels": ["level_2"], "notes": "This check is manual because it requires access to the AWS Fargate\nendpoint to audit and remediate.", "title": "5.6.1 Consider Fargate for running untrusted workloads", "description": "Description:\n\n  It is Best Practice to restrict or fence untrusted workloads when\n  running in a multi-tenant environment.\n\nRationale:\n\n  AWS Fargate is a technology that provides on-demand, right-sized\n  compute capacity for containers. With AWS Fargate, you no longer have\n  to provision, configure, or scale groups of virtual machines to run\n  containers. This removes the need to choose server types, decide when\n  to scale your node groups, or optimize cluster packing. You can\n  control which pods start on Fargate and how they run with Fargate\n  profiles, which are defined as part of your Amazon EKS cluster.\n  Amazon EKS integrates Kubernetes with AWS Fargate by using\n  controllers that are built by AWS using the upstream, extensible\n  model provided by Kubernetes. These controllers run as part of the\n  Amazon EKS managed Kubernetes control plane and are responsible for\n  scheduling native Kubernetes pods onto Fargate. The Fargate\n  controllers include a new scheduler that runs alongside the default\n  Kubernetes scheduler in addition to several mutating and validating\n  admission controllers. When you start a pod that meets the criteria\n  for running on Fargate, the Fargate controllers running in the\n  cluster recognize, update, and schedule the pod onto Fargate. Each\n  pod running on Fargate has its own isolation boundary and does not\n  share the underlying kernel, CPU resources, memory resources, or\n  elastic network interface with another pod.", "rationale": null, "automated": "no", "status": "manual", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "5.6", "levels": ["level_1"], "notes": "", "title": "5.6 Other Cluster Configurations", "description": null, "rationale": null, "automated": "no", "status": "manual", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": ["5.6.1"]}, {"id": "5", "levels": ["level_2"], "notes": "", "title": "5 Managed services", "description": "This section consists of security recommendations for the Amazon EKS. These\nrecommendations are applicable for configurations that Amazon EKS customers\nown and manage.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": ["5.1.1", "5.1.2", "5.1.3", "5.1.4", "5.1", "5.2.1", "5.2", "5.3.1", "5.3", "5.4.1", "5.4.2", "5.4.3", "5.4.4", "5.4.5", "5.4", "5.5.1", "5.5", "5.6.1", "5.6"]}], "levels": [{"id": "level_1", "inherits_from": null}, {"id": "level_2", "inherits_from": ["level_1"]}]}