--- controls: version: "eks-1.5.0" id: 5 text: "Managed Services" type: "managedservices" groups: - id: 5.1 text: "Image Registry and Image Scanning" checks: - id: 5.1.1 text: "Ensure Image Vulnerability Scanning using Amazon ECR image scanning or a third party provider (Automated)" type: "manual" remediation: | To utilize AWS ECR for Image scanning please follow the steps below: To create a repository configured for scan on push (AWS CLI): aws ecr create-repository --repository-name $REPO_NAME --image-scanning-configuration scanOnPush=true --region $REGION_CODE To edit the settings of an existing repository (AWS CLI): aws ecr put-image-scanning-configuration --repository-name $REPO_NAME --image-scanning-configuration scanOnPush=true --region $REGION_CODE Use the following steps to start a manual image scan using the AWS Management Console. 1. Open the Amazon ECR console at https://console.aws.amazon.com/ecr/repositories. 2. From the navigation bar, choose the Region to create your repository in. 3. In the navigation pane, choose Repositories. 4. On the Repositories page, choose the repository that contains the image to scan. 5. On the Images page, select the image to scan and then choose Scan. scored: false - id: 5.1.2 text: "Minimize user access to Amazon ECR (Manual)" type: "manual" remediation: | Before you use IAM to manage access to Amazon ECR, you should understand what IAM features are available to use with Amazon ECR. To get a high-level view of how Amazon ECR and other AWS services work with IAM, see AWS Services That Work with IAM in the IAM User Guide. scored: false - id: 5.1.3 text: "Minimize cluster access to read-only for Amazon ECR (Manual)" type: "manual" remediation: | You can use your Amazon ECR images with Amazon EKS, but you need to satisfy the following prerequisites. The Amazon EKS worker node IAM role (NodeInstanceRole) that you use with your worker nodes must possess the following IAM policy permissions for Amazon ECR. { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ecr:BatchCheckLayerAvailability", "ecr:BatchGetImage", "ecr:GetDownloadUrlForLayer", "ecr:GetAuthorizationToken" ], "Resource": "*" } ] } scored: false - id: 5.1.4 text: "Minimize Container Registries to only those approved (Manual)" type: "manual" remediation: | To minimize AWS ECR container registries to only those approved, you can follow these steps: 1. Define your approval criteria: Determine the criteria that containers must meet to be considered approved. This can include factors such as security, compliance, compatibility, and other requirements. 2. Identify all existing ECR registries: Identify all ECR registries that are currently being used in your organization. 3. Evaluate ECR registries against approval criteria: Evaluate each ECR registry against your approval criteria to determine whether it should be approved or not. This can be done by reviewing the registry settings and configuration, as well as conducting security assessments and vulnerability scans. 4. Establish policies and procedures: Establish policies and procedures that outline how ECR registries will be approved, maintained, and monitored. This should include guidelines for developers to follow when selecting a registry for their container images. 5. Implement access controls: Implement access controls to ensure that only approved ECR registries are used to store and distribute container images. This can be done by setting up IAM policies and roles that restrict access to unapproved registries or create a whitelist of approved registries. 6. Monitor and review: Continuously monitor and review the use of ECR registries to ensure that they continue to meet your approval criteria. This can include scored: false - id: 5.2 text: "Identity and Access Management (IAM)" checks: - id: 5.2.1 text: "Prefer using dedicated Amazon EKS Service Accounts (Automated)" type: "manual" remediation: | With IAM roles for service accounts on Amazon EKS clusters, you can associate an IAM role with a Kubernetes service account. This service account can then provide AWS permissions to the containers in any pod that uses that service account. With this feature, you no longer need to provide extended permissions to the worker node IAM role so that pods on that node can call AWS APIs. Applications must sign their AWS API requests with AWS credentials. This feature provides a strategy for managing credentials for your applications, similar to the way that Amazon EC2 instance profiles provide credentials to Amazon EC2 instances. Instead of creating and distributing your AWS credentials to the containers or using the Amazon EC2 instance’s role, you can associate an IAM role with a Kubernetes service account. The applications in the pod’s containers can then use an AWS SDK or the AWS CLI to make API requests to authorized AWS services. The IAM roles for service accounts feature provides the following benefits: - Least privilege - By using the IAM roles for service accounts feature, you no longer need to provide extended permissions to the worker node IAM role so that pods on that node can call AWS APIs. You can scope IAM permissions to a service account, and only pods that use that service account have access to those permissions. This feature also eliminates the need for third-party solutions such as kiam or kube2iam. - Credential isolation - A container can only retrieve credentials for the IAM role that is associated with the service account to which it belongs. A container never has access to credentials that are intended for another container that belongs to another pod. - Audit-ability - Access and event logging is available through CloudTrail to help ensure retrospective auditing. scored: false - id: 5.3 text: "AWS EKS Key Management Service" checks: - id: 5.3.1 text: "Ensure Kubernetes Secrets are encrypted using Customer Master Keys (CMKs) managed in AWS KMS (Manual)" type: "manual" remediation: | This process can only be performed during Cluster Creation. Enable 'Secrets Encryption' during Amazon EKS cluster creation as described in the links within the 'References' section. scored: false - id: 5.4 text: "Cluster Networking" checks: - id: 5.4.1 text: "Restrict Access to the Control Plane Endpoint (Automated)" type: "manual" remediation: | By enabling private endpoint access to the Kubernetes API server, all communication between your nodes and the API server stays within your VPC. You can also limit the IP addresses that can access your API server from the internet, or completely disable internet access to the API server. With this in mind, you can update your cluster accordingly using the AWS CLI to ensure that Private Endpoint Access is enabled. If you choose to also enable Public Endpoint Access then you should also configure a list of allowable CIDR blocks, resulting in restricted access from the internet. If you specify no CIDR blocks, then the public API server endpoint is able to receive and process requests from all IP addresses by defaulting to ['0.0.0.0/0']. For example, the following command would enable private access to the Kubernetes API as well as limited public access over the internet from a single IP address (noting the /32 CIDR suffix): aws eks update-cluster-config --region $AWS_REGION --name $CLUSTER_NAME --resources-vpc-config endpointPrivateAccess=true,endpointPrivateAccess=true,publicAccessCidrs="203.0.113.5/32" Note: The CIDR blocks specified cannot include reserved addresses. There is a maximum number of CIDR blocks that you can specify. For more information, see the EKS Service Quotas link in the references section. For more detailed information, see the EKS Cluster Endpoint documentation link in the references section. scored: false - id: 5.4.2 text: "Ensure clusters are created with Private Endpoint Enabled and Public Access Disabled (Automated)" type: "manual" remediation: | By enabling private endpoint access to the Kubernetes API server, all communication between your nodes and the API server stays within your VPC. With this in mind, you can update your cluster accordingly using the AWS CLI to ensure that Private Endpoint Access is enabled. For example, the following command would enable private access to the Kubernetes API and ensure that no public access is permitted: aws eks update-cluster-config --region $AWS_REGION --name $CLUSTER_NAME --resources-vpc-config endpointPrivateAccess=true,endpointPublicAccess=false Note: For more detailed information, see the EKS Cluster Endpoint documentation link in the references section. scored: false - id: 5.4.3 text: "Ensure clusters are created with Private Nodes (Automated)" type: "manual" remediation: | aws eks update-cluster-config \ --region region-code \ --name my-cluster \ --resources-vpc-config endpointPublicAccess=true,publicAccessCidrs="203.0.113.5/32",endpointPrivateAccess=true scored: false - id: 5.4.4 text: "Ensure Network Policy is Enabled and set as appropriate (Automated)" type: "manual" remediation: | Utilize Calico or other network policy engine to segment and isolate your traffic. scored: false - id: 5.4.5 text: "Encrypt traffic to HTTPS load balancers with TLS certificates (Manual)" type: "manual" remediation: | Your load balancer vendor can provide details on configuring HTTPS with TLS. scored: false - id: 5.5 text: "Authentication and Authorization" checks: - id: 5.5.1 text: "Manage Kubernetes RBAC users with AWS IAM Authenticator for Kubernetes or Upgrade to AWS CLI v1.16.156 or greater (Manual)" type: "manual" remediation: | Refer to the 'Managing users or IAM roles for your cluster' in Amazon EKS documentation. Note: If using AWS CLI version 1.16.156 or later there is no need to install the AWS IAM Authenticator anymore. The relevant AWS CLI commands, depending on the use case, are: aws eks update-kubeconfig aws eks get-token scored: false