---
policy: CIS
title: Configuration Recommendations of an EKS System
id: cis_eks
version: '1.0.1'
source: https://www.cisecurity.org/cis-benchmarks/

levels:
    - id: level_1
    - id: level_2
      inherits_from:
          - level_1

controls:
    - id: '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:

          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.
      notes: |-
          As noted, evaluating the security of the control plane is not the
          responsibility of customers or deployers, but of Amazon instead. Thus, this
          profile will not implement controls from Section 1.
      status: not applicable
      rules: []

    - id: '2'
      title: '2 Control Plane Configuration'
      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:
          - level_1
      status: manual
      controls:
          - id: '2.1'
            title: '2.1 Logging'
            status: manual
            levels:
                - level_1
            controls:
                - id: 2.1.1
                  title: '2.1.1 Enable audit Logs'
                  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.
      # TODO: Evaluate if it's feasible to do an automated check for this
      # control. This might require that the Compliance Operator acquire the
      # ability to probe AWS endpoints (like the EKS one) to be able to do such
      # checks.
                  notes: |-
                      Automating this check requires access to AWS endpoints, the aws or
                      eksctl client, the EKS cluster name, and the cluster region. It's not
                      feasible to automate this check until we find a way to incorporate the
                      information we need and use it to check AWS using the API. For now,
                      this must be checked manually.
                  status: manual
                  levels:
                      - level_1
                  rules:
                      - audit_logging
    - id: '3'
      title: '3 Worker Nodes'
      description: |-
          This section consists of security recommendations for the components that run on Amazon
          EKS worker nodes.
      levels:
          - level_2
      status: automated
      controls:
          - id: '3.1'
            title: '3.1 Worker Node Configuration Files'
            description: |-
                This section covers recommendations for configuration files on Amazon EKS worker nodes.
            status: automated
            levels:
                - level_2
            controls:
                - id: 3.1.1
                  title: >-
                      3.1.1 Ensure that the kubeconfig file permissions are set to 644 or
                      more restrictive
                  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.
                  status: automated
                  notes: |-
                      The default permissions are acceptable based on the control's description
                      and rationale.
                  rules:
                      - file_permissions_worker_kubeconfig
                - id: 3.1.2
                  title: >-
                      3.1.2 Ensure that the kubelet kubeconfig file ownership is set to
                      root:root
                  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.
                  status: automated
                  rules:
                      - file_owner_worker_kubeconfig
                      - file_groupowner_worker_kubeconfig
                - id: 3.1.3
                  title: >-
                      3.1.3 Ensure that the kubelet configuration file has permissions set to 644 or
                      more restrictive
                  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.
                  status: automated
                  levels:
                      - level_1
                  rules:
                      - file_permissions_kubelet_conf
                - id: 3.1.4
                  title: >-
                      3.1.4 Ensure that the kubelet configuration file ownership is set to root:root
                  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.
                  status: automated
                  levels:
                      - level_1
                  rules:
                      - file_groupowner_kubelet_conf
                      - file_owner_kubelet_conf
          - id: '3.2'
            title: >-
                3.2 Kubelet
            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.
            status: automated
            levels:
                - level_2
            controls:
                - id: 3.2.1
                  title: >-
                      3.2.1 Ensure that the --anonymous-auth argument is set to false
                  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.
                  status: automated
                  levels:
                      - level_1
                  rules:
                      - kubelet_anonymous_auth
                - id: 3.2.2
                  title: >-
                      3.2.2 Ensure that the --authorization-mode argument is not set to AlwaysAllow
                  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.
                  status: automated
                  levels:
                      - level_1
                  rules:
                      - kubelet_authorization_mode
                - id: 3.2.3
                  title: >-
                      3.2.3 Ensure that the --client-ca-file argument is set as appropriate
                  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.
                  status: automated
                  levels:
                      - level_1
                  rules:
                      - kubelet_configure_client_ca
                - id: 3.2.4
                  title: >-
                      3.2.4 Ensure that the --read-only-port is secured
                  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.
                  status: automated
                  levels:
                      - level_1
                  rules:
                      - kubelet_read_only_port_secured
                - id: 3.2.5
                  title: >-
                      3.2.5 Ensure that the --streaming-connection-idle-timeout argument is not set to
                      0
                  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.
                  status: automated
                  levels:
                      - level_1
                  rules:
                      - kubelet_enable_streaming_connections
                - id: 3.2.6
                  title: >-
                      3.2.6 Ensure that the --protect-kernel-defaults argument is set to true
                  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.
                  status: automated
                  levels:
                      - level_1
                  rules:
                      - kubelet_enable_protect_kernel_defaults
                - id: 3.2.7
                  title: >-
                      3.2.7 Ensure that the --make-iptables-util-chains argument is set to true
                  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.
                  status: automated
                  levels:
                      - level_1
                  rules:
                      - kubelet_enable_iptables_util_chains
                - id: 3.2.8
                  title: >-
                      3.2.8 Ensure that the --hostname-override argument is not set
                  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.
                  status: automated
                  levels:
                      - level_1
                  rules:
                      - kubelet_disable_hostname_override
                - id: 3.2.9
                  title: >-
                      3.2.9 Ensure that the --eventRecordQPS argument is set to 0 or a level which ensures
                      appropriate event capture
      # TODO(jaosorior): I'm unsure how to check this as the value is not
      # set in EKS, but the result of evaluating the dynamic config
      # endpoint gives out a correct value... so it seems that it
      # just passes by default.
                  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.
                  status: pending
                  levels:
                      - level_2
                  rules: []
                - id: 3.2.10
                  title: >-
                      3.2.10 Ensure that the --rotate-certificates argument is not set to false
                  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.
                  status: automated
                  levels:
                      - level_2
                  rules:
                      - kubelet_enable_client_cert_rotation
                      - kubelet_enable_cert_rotation
                - id: 3.2.11
                  title: >-
                      3.2.11 Ensure that the RotateKubeletServerCertificate argument is set to true
                  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.
                  status: automated
                  levels:
                      - level_1
                  rules:
                      - kubelet_enable_server_cert_rotation
    - id: '4'
      title: >-
          4 Policies
      description: |-
          This section contains recommendations for various Kubernetes policies which
          are important to the security of Amazon EKS customer environment.
      status: manual
      levels:
          - level_2
      controls:
          - id: '4.1'
            title: >-
                4.1 RBAC and Service Accounts
            status: pending
            levels:
                - level_2
            controls:
                - id: 4.1.1
                  title: >-
                      4.1.1 Ensure that the cluster-admin role is only used where required
                  status: manual
                  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.
                  notes: |-
                      This check is manual because it requires deployment-specific knowledge
                      about users and their authorization.
                  levels:
                      - level_1
                  rules: []
                - id: 4.1.2
                  title: >-
                      4.1.2 Minimize access to secrets
                  status: manual
                  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.
                  notes: |-
                      This check is manual because it requires deployment-specific knowledge
                      about users and their authorization.
                  levels:
                      - level_1
                  rules: []
                - id: 4.1.3
                  title: >-
                      4.1.3 Minimize wildcard use in Roles and ClusterRoles
                  status: manual
                  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.
                  notes: |-
                      This check is manual because it requires deployment-specific knowledge
                      to audit effectively. The Compliance Operator also uses wildcards for
                      the compliance-operator roles.
                  levels:
                      - level_1
                  rules: []
                - id: 4.1.4
                  title: >-
                      4.1.4 Minimize access to create pods
                  status: manual
                  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.
                  notes: |-
                      This check is manual because it requires deployment-specific knowledge
                      about users and their authorization.
                  levels:
                      - level_1
                  rules: []
                - id: 4.1.5
                  title: >-
                      4.1.5 Ensure that default service accounts are not actively used.
                  status: manual
                  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.
                  notes: |-
                      This check is manual because it requires deployment-specific knowledge
                      about each namespace in the deployment.
                  levels:
                      - level_1
                  rules: []
                - id: 4.1.6
                  title: >-
                      4.1.6 Ensure that Service Account Tokens are only mounted where necessary
                  status: manual
                  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.
                  notes: |-
                      This check is manual because it requires deployment-specific knowledge
                      about each namespace and pod in the deployment.
                  levels:
                      - level_1
                  rules: []
          - id: '4.2'
            title: >-
                4.2 Pod Security Policies
            status: pending
            levels:
                - level_2
            controls:
                - id: 4.2.1
                  title: >-
                      4.2.1 Minimize the admission of privileged containers
                  status: pending
                  levels:
                      - level_1
                  rules: []
                - id: 4.2.2
                  title: >-
                      4.2.2 Minimize the admission of containers wishing to share the host process ID
                      namespace
                  status: pending
                  levels:
                      - level_1
                  rules: []
                - id: 4.2.3
                  title: >-
                      4.2.3 Minimize the admission of containers wishing to share the host IPC namespace
                  status: pending
                  levels:
                      - level_1
                  rules: []
                - id: 4.2.4
                  title: >-
                      4.2.4 Minimize the admission of containers wishing to share the host network namespace
                  status: pending
                  levels:
                      - level_1
                  rules: []
                - id: 4.2.5
                  title: >-
                      4.2.5 Minimize the admission of containers with allowPrivilegeEscalation
                  status: pending
                  levels:
                      - level_1
                  rules: []
                - id: 4.2.6
                  title: >-
                      4.2.6 Minimize the admission of root containers
                  status: pending
                  levels:
                      - level_2
                  rules: []
                - id: 4.2.7
                  title: >-
                      4.2.7 Minimize the admission of containers with the NET_RAW capability
                  status: pending
                  levels:
                      - level_1
                  rules: []
                - id: 4.2.8
                  title: >-
                      4.2.8 Minimize the admission of containers with added capabilities
                  status: pending
                  levels:
                      - level_1
                  rules: []
                - id: 4.2.9
                  title: >-
                      4.2.9 Minimize the admission of containers with capabilities assigned
                  status: pending
                  levels:
                      - level_2
                  rules: []
          - id: '4.3'
            title: >-
                4.3 CNI Plugin
            status: pending
            levels:
                - level_2
            controls:
                - id: 4.3.1
                  title: >-
                      4.3.1 Ensure latest CNI version is used
                  status: pending
                  levels:
                      - level_1
                  rules: []
                - id: 4.3.2
                  title: >-
                      4.3.2 Ensure that all Namespaces have Network Policies defined
                  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.
                  notes: |-
                      We can verify this with the Compliance Operator and check that all
                      namespaces have at least a NetworkPolicy defined.
                  status: automated
                  levels:
                      - level_2
                  rules:
                      - configure_network_policies_namespaces
          - id: '4.4'
            title: >-
                4.4 Secrets Management
            status: pending
            levels:
                - level_2
            controls:
                - id: 4.4.1
                  title: >-
                      4.4.1 Prefer using secrets as files over secrets as environment variables
                  status: pending
                  levels:
                      - level_2
                  rules: []
                - id: 4.4.2
                  title: >-
                      4.4.2 Consider external secret storage
                  status: pending
                  levels:
                      - level_2
                  rules: []
          - id: '4.5'
            title: >-
                4.5 Extensible Admission Control
            status: pending
            levels:
                - level_2
            controls:
                - id: 4.5.1
                  title: >-
                      4.5.1 Configure Image Provenance using ImagePolicyWebhook admission controller
                  status: pending
                  levels:
                      - level_2
                  rules: []
          - id: '4.6'
            title: >-
                4.6 General Policies
            status: pending
            levels:
                - level_2
            controls:
                - id: 4.6.1
                  title: >-
                      4.6.1 Create administrative boundaries between resources using namespaces
                  status: pending
                  levels:
                      - level_1
                  rules: []
                - id: 4.6.2
                  title: >-
                      4.6.2 Apply Security Context to Your Pods and Containers
                  status: pending
                  levels:
                      - level_2
                  rules: []
                - id: 4.6.3
                  title: >-
                      4.6.3 The default namespace should not be used
                  status: pending
                  levels:
                      - level_2
                  rules: []
    - id: '5'
      title: >-
          5 Managed services
      status: pending
      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:
          - level_2
      controls:
          - id: '5.1'
            title: >-
                5.1 Image Registry and Image Scanning
            status: manual
            description: |-
                This section contains recommendations relating to container image
                registries and securing images in those registries, such as Amazon
                Elastic Container Registry (ECR).
            levels:
                - level_2
            controls:
                - id: 5.1.1
                  title: >-
                      5.1.1 Ensure Image Vulnerability Scanning using Amazon ECR image scanning or a
                      third party provider
      # NOTE(lbragstad): We're unable to automate this check because it
      # requires access to an AWS endpoint. We should re-evaluate this if it
      # becomes possible to write rules that use network connections.
                  status: manual
                  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:
                      - level_1
                  rules:
                      - image_scanning
                - id: 5.1.2
                  title: >-
                      5.1.2 Minimize user access to Amazon ECR
      # NOTE(lbragstad): We're unable to automate this check because it
      # requires access to an AWS endpoint. We should re-evaluate this if it
      # becomes possible to write rules that use network connections.
                  status: manual
                  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:
                      - level_1
                  rules:
                      - registry_access
                - id: 5.1.3
                  title: >-
                      5.1.3 Minimize cluster access to read-only for Amazon ECR
      # NOTE(lbragstad): We're unable to automate this check because it
      # requires access to an AWS endpoint. We should re-evaluate this if it
      # becomes possible to write rules that use network connections.
                  status: manual
                  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:
                      - level_1
                  rules:
                      - read_only_registry_access
                - id: 5.1.4
                  title: >-
                      5.1.4 Minimize Container Registries to only those approved
      # NOTE(lbragstad): We're unable to automate this check because it
      # requires access to an AWS endpoint. We should re-evaluate this if it
      # becomes possible to write rules that use network connections.
                  status: manual
                  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:
                      - level_2
                  rules:
                      - approved_registries
          - id: '5.2'
            title: >-
                5.2 Identity and Access Management (IAM)
            status: manual
            levels:
                - level_1
            controls:
                - id: 5.2.1
                  title: >-
                      5.2.1 Prefer using dedicated EKS Service Accounts
                  status: manual
                  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.
                  notes: |-
                      This must be checked manually since it requires deployment-specific
                      knowledge and requires network access to the AWS IAM endpoint.
                      Re-evaluate this if or when we have the ability to use network
                      connections in rules.
                  levels:
                      - level_1
                  rules:
                      - dedicated_service_accounts
          - id: '5.3'
            title: >-
                5.3 AWS Key Management Service (KMS)
            status: manual
            levels:
                - level_1
            controls:
                - id: 5.3.1
                  title: >-
                      5.3.1 Ensure Kubernetes Secrets are encrypted using Customer Master Keys (CMKs)
                      managed in AWS KMS
                  status: manual
                  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.
                  notes: |-
                      This check is manual because it requires deployment-specific knowledge
                      and access to the AWS KMS endpoint. Re-evaluate this if or when we have
                      the ability to use network connections in rules.
                  levels:
                      - level_1
                  rules:
                      - secret_encryption
          - id: '5.4'
            title: >-
                5.4 Cluster Networking
            status: pending
            levels:
                - level_2
            controls:
                - id: 5.4.1
                  title: >-
                      5.4.1 Restrict Access to the Control Plane Endpoint
                  status: manual
                  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.
                  notes: |-
                      This check is manual because it requires deployment-specific knowledge
                      and access to the AWS EKS endpoint. Re-evaluate this if or when we have
                      the ability to use network connections in rules.
                  levels:
                      - level_1
                  rules:
                      - control_plane_access
                - id: 5.4.2
                  title: >-
                      5.4.2 Ensure clusters are created with Private Endpoint Enabled and Public Access
                      Disabled
                  status: manual
                  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.
                  notes: |-
                      This check is manual because it requires deployment-specific knowledge
                      and access to AWS endpoints. Re-evaluate this if or when we have the
                      ability to use network connections in rules.
                  levels:
                      - level_2
                  rules:
                      - endpoint_configuration
                - id: 5.4.3
                  title: >-
                      5.4.3 Ensure clusters are created with Private Nodes
                  status: manual
                  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.
                  notes: |-
                      This check is manual because it requires deployment-specific knowledge
                      and access to AWS endpoints. Re-evaluate this if or when we have the
                      ability to use network connections in rules.
                  levels:
                      - level_1
                  rules:
                      - private_nodes
                - id: 5.4.4
                  title: >-
                      5.4.4 Ensure Network Policy is Enabled and set as appropriate
                  status: manual
                  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.
                  notes: |-
                      This check is manual because it requires deployment-specific knowledge.
                  levels:
                      - level_1
                  rules:
                      - configure_network_policy
                - id: 5.4.5
                  title: >-
                      5.4.5 Encrypt traffic to HTTPS load balancers with TLS certificates
                  status: manual
                  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.
                  notes: |-
                      This check is manual because it requires access to the Kubernetes API
                      server configuration, which requires access to the Kubernetes API or
                      the AWS EKS configuration.
                  levels:
                      - level_2
                  rules:
                      - configure_tls
          - id: '5.5'
            title: >-
                5.5 Authentication and Authorization
            status: manual
            levels:
                - level_2
            controls:
                - id: 5.5.1
                  title: >-
                      5.5.1 Manage Kubernetes RBAC users with AWS IAM Authenticator for Kubernetes
                  status: manual
                  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.
                  notes: |-
                      This check is manual because it requires deployment-specific knowledge
                      about the namespaces to audit it effectively.
                  levels:
                      - level_2
                  rules:
                      - iam_integration
          - id: '5.6'
            title: >-
                5.6 Other Cluster Configurations
            status: manual
            levels:
                - level_1
            controls:
                - id: 5.6.1
                  title: >-
                      5.6.1 Consider Fargate for running untrusted workloads
                  status: manual
                  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.
                  notes: |-
                      This check is manual because it requires access to the AWS Fargate
                      endpoint to audit and remediate.
                  levels:
                      - level_2
                  rules:
                      - fargate