CIS Amazon Elastic Kubernetes Service (EKS) Benchmark
Overview
Center for Internet Security (CIS) provides set of best practices and security recommendations which is referred to as Elastic Kubernetes Service (EKS) Benchmark. These benchmarks are designed to strengthen the security posture of Amazon EKS clusters. Since the organizations are increasingly adopting the container orchestration platforms like EKS, it becomes essential to ensure that these environments are configured securely to mitigate security risks and protect sensitive data.
Purpose
The primary purposes of this benchmark are:
Security Enhancement: The benchmark equips organizations with a set of well-defined security guidelines and best practices to proactively identify and address security vulnerabilities, misconfigurations, and potential threats within Amazon EKS clusters.
Compliance Alignment: In a landscape with evolving compliance requirements, the benchmark enables organizations to align with industry and regulatory standards by providing clear and actionable security recommendations.
Standardization: By offering universally recognized best practices, the benchmark encourages the adoption of standardized security procedures across Amazon EKS environments, ensuring consistency and uniformity in security configurations.
Importance
Securing Amazon EKS clusters is of paramount importance for several reasons:
Data Protection: EKS clusters often host critical applications and workloads that handle sensitive data. Insufficient security measures can lead to data breaches and loss.
Operational Continuity: Security incidents can disrupt operations and result in downtime, making a secure EKS environment crucial for maintaining business continuity.
Reputation and Trust: Security incidents can damage an organization's reputation and erode trust among customers and partners. The implementation of robust security measures is vital for preserving trust and integrity.
Legal and Regulatory Compliance: Many industries and jurisdictions have stringent data protection and security regulations. Non-compliance can lead to legal consequences and liabilities.
By adhering to the recommendations outlined in the CIS Amazon EKS Benchmark, organizations can significantly enhance the security of their Amazon EKS clusters, safeguard their assets, and mitigate potential security threats effectively.
How BOS targets CIS EKS Benchmarks v1.3.0
| Benchmark Index | CIS Benchmark Recommendation | BOS Env Template Supports | BOS Pipeline Template Supports | BOS Default | Comments |
|---|---|---|---|---|---|
| 2.1 | Logging | ||||
| 2.1.1 | Enable audit Logs | Yes | No | Yes | We have enabled audit logs for the EKS Cluster. |
| 3.1 | Worker Node Configuration Files | ||||
| 3.1.1 | Ensure that the kubeconfig file permissions are set to 644 or more restrictive | NA | NA | Yes | We are making use of managed EKS Cluster. The worker nodes are auto created by EKS with default configs. These controls are satisfied in the worker nodes. The worker nodes are running with the AMI AL2_x86_64 |
| 3.1.2 | Ensure that the kubelet kubeconfig file ownership is set to root:root | NA | NA | Yes | We are making use of managed EKS Cluster. The worker nodes are auto created by EKS with default configs. These controls are satisfied in the worker nodes. The worker nodes are running with the AMI AL2_x86_64 |
| 3.1.3 | Ensure that the kubelet configuration file has permissions set to 644 or more restrictive | NA | NA | Yes | We are making use of managed EKS Cluster. The worker nodes are auto created by EKS with default configs. These controls are satisfied in the worker nodes. The worker nodes are running with the AMI AL2_x86_64 |
| 3.1.4 | Ensure that the kubelet configuration file ownership is set to root:root | NA | NA | Yes | We are making use of managed EKS Cluster. The worker nodes are auto created by EKS with default configs. These controls are satisfied in the worker nodes. The worker nodes are running with the AMI AL2_x86_64 |
| 3.2 | Kubelet | We are making use of managed EKS Cluster. The worker nodes are auto created by EKS with default configs. These controls are satisfied in the worker nodes. The worker nodes are running with the AMI AL2_x86_64 | |||
| 3.2.1 | Ensure that the Anonymous Auth is Not Enabled | NA | NA | Yes | We are making use of managed EKS Cluster. The worker nodes are auto created by EKS with default configs. These controls are satisfied in the worker nodes. The worker nodes are running with the AMI AL2_x86_64 |
| 3.2.10 | Ensure that the RotateKubeletServerCertificate argument is set to true | NA | NA | Yes | We are making use of managed EKS Cluster. The worker nodes are auto created by EKS with default configs. These controls are satisfied in the worker nodes. The worker nodes are running with the AMI AL2_x86_64 |
| 3.2.2 | Ensure that the --authorization-mode argument is not set to AlwaysAllow | NA | NA | Yes | We are making use of managed EKS Cluster. The worker nodes are auto created by EKS with default configs. These controls are satisfied in the worker nodes. The worker nodes are running with the AMI AL2_x86_64 |
| 3.2.3 | Ensure that a Client CA File is Configured | NA | NA | Yes | We are making use of managed EKS Cluster. The worker nodes are auto created by EKS with default configs. These controls are satisfied in the worker nodes. The worker nodes are running with the AMI AL2_x86_64 |
| 3.2.4 | Ensure that the --read-only-port is disabled | NA | NA | Yes | We are making use of managed EKS Cluster. The worker nodes are auto created by EKS with default configs. These controls are satisfied in the worker nodes. The worker nodes are running with the AMI AL2_x86_64 |
| 3.2.5 | Ensure that the --streaming-connection-idle-timeout argument is not set to 0 | NA | NA | Yes | We are making use of managed EKS Cluster. The worker nodes are auto created by EKS with default configs. These controls are satisfied in the worker nodes. The worker nodes are running with the AMI AL2_x86_64 |
| 3.2.6 | Ensure that the --make-iptables-util-chains argument is set to true | NA | NA | Yes | We are making use of managed EKS Cluster. The worker nodes are auto created by EKS with default configs. These controls are satisfied in the worker nodes. The worker nodes are running with the AMI AL2_x86_64 |
| 3.2.7 | Ensure that the --hostname-override argument is not set | NA | NA | Yes | We are making use of managed EKS Cluster. The worker nodes are auto created by EKS with default configs. These controls are satisfied in the worker nodes. The worker nodes are running with the AMI AL2_x86_64 |
| 3.2.8 | Ensure that the --eventRecordQPS argument is set to 0 or a level which ensures appropriate event capture | NA | NA | Yes | We are making use of managed EKS Cluster. The worker nodes are auto created by EKS with default configs. These controls are satisfied in the worker nodes. The worker nodes are running with the AMI AL2_x86_64 |
| 3.2.9 | Ensure that the --rotate-certificates argument is not present or is set to true | NA | NA | Yes | We are making use of managed EKS Cluster. The worker nodes are auto created by EKS with default configs. These controls are satisfied in the worker nodes. The worker nodes are running with the AMI AL2_x86_64 |
| 3.3 | Container Optimized OS | ||||
| 3.3.1 | Prefer using a container-optimized OS when possible | Yes | No | Yes | We are making use of recommended AL2_x86_64 AMI |
| 4.1 | RBAC and Service Accounts | ||||
| 4.1.1 | Ensure that the cluster-admin role is only used where required | No | Yes | Yes | We are not making use of any additional Kubernetes Roles or Cluster Roles apart from default |
| 4.1.2 | Minimize access to secrets | No | Yes | Yes | No explicit access to secrets is given. |
| 4.1.3 | Minimize wildcard use in Roles and ClusterRoles | No | Yes | Yes | No Wildcards are being used. |
| 4.1.4 | Minimize access to create pods | No | Yes | Yes | No explicit access to given to create pods. Pods cannot be created without authentication |
| 4.1.5 | Ensure that default service accounts are not actively used. | No | NA | NA | We are making use of AWS Roles to authenticate with API server. and deploy containers |
| 4.1.6 | Ensure that Service Account Tokens are only mounted where necessary | No | NA | NA | We are making use of AWS Roles to authenticate with API server. and deploy containers |
| 4.1.7 | Avoid use of system:masters group | No | No | Yes | We are not making use of system:masters group |
| 4.1.8 | Limit use of the Bind, Impersonate and Escalate permissions in the Kubernetes cluster | No | Yes | Yes | We are making use of securityContext in our pipeline template, we are defining the privilege permission, PrivilegeEscalation, root permissions, capabilities for each pods and container in a given namespace |
| 4.2 | Pod Security Standards | We are making use of securityContext in our pipeline template, we are defining the privilege permission, PrivilegeEscalation, root permissions, capabilities for each pods and container in a given namespace | |||
| 4.2.1 | Minimize the admission of privileged containers | No | Yes | Yes | We are making use of securityContext in our pipeline template, we are defining the privilege permission, PrivilegeEscalation, root permissions, capabilities for each pods and container in a given namespace |
| 4.2.2 | Minimize the admission of containers wishing to share the host process ID namespace | No | Yes | Yes | We are making use of securityContext in our pipeline template, we are defining the privilege permission, PrivilegeEscalation, root permissions, capabilities for each pods and container in a given namespace |
| 4.2.3 | Minimize the admission of containers wishing to share the host IPC namespace | No | Yes | Yes | We are making use of securityContext in our pipeline template, we are defining the privilege permission, PrivilegeEscalation, root permissions, capabilities for each pods and container in a given namespace |
| 4.2.4 | Minimize the admission of containers wishing to share the host network namespace | No | Yes | Yes | We are making use of securityContext in our pipeline template, we are defining the privilege permission, PrivilegeEscalation, root permissions, capabilities for each pods and container in a given namespace |
| 4.2.5 | Minimize the admission of containers with allowPrivilegeEscalation | No | Yes | Yes | We are making use of securityContext in our pipeline template, we are defining the privilege permission, PrivilegeEscalation, root permissions, capabilities for each pods and container in a given namespace |
| 4.2.6 | Minimize the admission of root containers | No | Yes | Yes | We are making use of securityContext in our pipeline template, we are defining the privilege permission, PrivilegeEscalation, root permissions, capabilities for each pods and container in a given namespace |
| 4.2.7 | Minimize the admission of containers with added capabilities | No | Yes | Yes | We are making use of securityContext in our pipeline template, we are defining the privilege permission, PrivilegeEscalation, root permissions, capabilities for each pods and container in a given namespace |
| 4.2.8 | Minimize the admission of containers with capabilities assigned | No | Yes | Yes | We are making use of securityContext in our pipeline template, we are defining the privilege permission, PrivilegeEscalation, root permissions, capabilities for each pods and container in a given namespace |
| 4.3 | CNI Plugin | ||||
| 4.3.1 | Ensure CNI plugin supports network policies. | Yes | No | Yes | We are making use of Amazon VPC CNI |
| 4.3.2 | Ensure that all Namespaces have Network Policies defined | No | Yes | Yes | Our Pipeline template creates network policies for each namespace |
| 4.4 | Secrets Management | ||||
| 4.4.1 | Prefer using secrets as files over secrets as environment variables | NA | NA | NA | Secret Management with amazon secret manager will be used. |
| 4.4.2 | Consider external secret storage | NA | NA | NA | Secret Management with amazon secret manager will be used. |
| 4.5 | General Policies | ||||
| 4.5.1 | Create administrative boundaries between resources using namespaces | No | Yes | Yes | We are making use of different namespaces for each application |
| 4.5.2 | Apply Security Context to Your Pods and Containers | No | Yes | Yes | We are making use of security context in our Pipeline Template |
| 4.5.3 | The default namespace should not be used | No | Yes | Yes | We are not making use of Default Namespace for any deployment |
| 5.1 | Image Registry and Image Scanning | ||||
| 5.1.1 | Ensure Image Vulnerability Scanning using Amazon ECR image scanning or a third party provider | Yes | No | Yes | We have enabled image scanning in ECR |
| 5.1.2 | Minimize user access to Amazon ECR | Yes | No | Yes | ECR cannot be accessed with a valid role |
| 5.1.3 | Minimize cluster access to read-only for Amazon ECR | Yes | No | Yes | EKS has only read access to ECR |
| 5.1.4 | Minimize Container Registries to only those approved | Yes | No | Yes | EKS only runs applications whose images are hosted in ECR |
| 5.2 | Identity and Access Management (IAM) | ||||
| 5.2.1 | Prefer using dedicated EKS Service Accounts | NA | NA | NA | We are making use of AWS Roles to authenticate with API server. and deploy containers |
| 5.3 | AWS EKS Key Management Service | ||||
| 5.3.1 | Ensure Kubernetes Secrets are encrypted using Customer Master Keys (CMKs) managed in AWS KMS | Yes | No | Yes | Secret encryption is on with CMK in KMS |
| 5.4 | Cluster Networking | ||||
| 5.4.1 | Restrict Access to the Control Plane Endpoint | Yes | No | No | Configurable with ENV Template parameters |
| 5.4.2 | Ensure clusters are created with Private Endpoint Enabled and Public Access Disabled | Yes | No | No | Configurable with ENV Template parameters |
| 5.4.3 | Ensure clusters are created with Private Nodes | Yes | No | Yes | Nodes only have private IPs |
| 5.4.4 | Ensure Network Policy is Enabled and set as appropriate | Yes | No | Yes | We are enabling the Network Policy on the EKS level as well as on the namespace level. |
| 5.4.5 | Encrypt traffic to HTTPS load balancers with TLS certificates | No | Yes | Yes | We are making use of certs for HTTPs |
| 5.5 | Authentication and Authorization | ||||
| 5.5.1 | Manage Kubernetes RBAC users with AWS IAM Authenticator for Kubernetes or Upgrade to AWS CLI v1.16.156 or greater | Yes | No | Yes | We are making use of AWS Roles to authenticate with API server. and deploy containers |
| 5.6 | Other Cluster Configurations | ||||
| 5.6.1 | Consider Fargate for running untrusted workloads | Yes | No | No | Not applied in default config to limit cost |