# Security Hub CSPM controls for Amazon EKS
These Security Hub CSPM controls evaluate the Amazon Elastic Kubernetes Service (Amazon EKS) service and resources. The controls might not be available in all AWS Regions. For more information, see [Availability of controls by Region](securityhub-regions.md#securityhub-regions-control-support).
## [EKS.1] EKS cluster endpoints should not be publicly accessible
**Related requirements:** NIST.800-53.r5 AC-21, NIST.800-53.r5 AC-3, NIST.800-53.r5 AC-3(7), NIST.800-53.r5 AC-4, NIST.800-53.r5 AC-4(21), NIST.800-53.r5 AC-6, NIST.800-53.r5 SC-7, NIST.800-53.r5 SC-7(11), NIST.800-53.r5 SC-7(16), NIST.800-53.r5 SC-7(20), NIST.800-53.r5 SC-7(21), NIST.800-53.r5 SC-7(3), NIST.800-53.r5 SC-7(4), NIST.800-53.r5 SC-7(9), PCI DSS v4.0.1/1.4.4
**Category:** Protect > Secure network configuration > Resources not publicly accessible
**Severity:** High
**Resource type:** `AWS::EKS::Cluster`
**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/eks-endpoint-no-public-access.html](https://docs.aws.amazon.com/config/latest/developerguide/eks-endpoint-no-public-access.html)
**Schedule type:** Periodic
**Parameters:** None
This control checks whether an Amazon EKS cluster endpoint is publicly accessible. The control fails if an EKS cluster has an endpoint that is publicly accessible.
When you create a new cluster, Amazon EKS creates an endpoint for the managed Kubernetes API server that you use to communicate with your cluster. By default, this API server endpoint is publicly available to the internet. Access to the API server is secured using a combination of AWS Identity and Access Management (IAM) and native Kubernetes Role Based Access Control (RBAC). By removing public access to the endpoint, you can avoid unintentional exposure and access to your cluster.
### Remediation
To modify endpoint access for an existing EKS cluster, see [Modifying cluster endpoint access](https://docs.aws.amazon.com/eks/latest/userguide/cluster-endpoint.html#modify-endpoint-access) in the **Amazon EKS User Guide**. You can set up endpoint access for a new EKS cluster when creating it. For instructions on creating a new Amazon EKS cluster, see [Creating an Amazon EKS cluster](https://docs.aws.amazon.com/eks/latest/userguide/create-cluster.html) in the **Amazon EKS User Guide**.
## [EKS.2] EKS clusters should run on a supported Kubernetes version
**Related requirements:** NIST.800-53.r5 CA-9(1), NIST.800-53.r5 CM-2, NIST.800-53.r5 SI-2, NIST.800-53.r5 SI-2(2), NIST.800-53.r5 SI-2(4), NIST.800-53.r5 SI-2(5), PCI DSS v4.0.1/12.3.4
**Category:** Identify > Vulnerability, patch, and version management
**Severity:** High
**Resource type:** `AWS::EKS::Cluster`
**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/eks-cluster-supported-version.html](https://docs.aws.amazon.com/config/latest/developerguide/eks-cluster-supported-version.html)
**Schedule type:** Change triggered
**Parameters:**
+ `oldestVersionSupported`: `1.33` (not customizable)
This control checks whether an Amazon Elastic Kubernetes Service (Amazon EKS) cluster runs on a supported Kubernetes version. The control fails if the EKS cluster runs on an unsupported version.
If your application doesn't require a specific version of Kubernetes, we recommend that you use the latest available Kubernetes version that's supported by EKS for your clusters. For more information, see [Amazon EKS Kubernetes release calendar](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html#kubernetes-release-calendar) and [Understand the Kubernetes version lifecycle on Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html#version-deprecation) in the **Amazon EKS User Guide**.
### Remediation
To update an EKS cluster, see [Update an existing cluster to a new Kubernetes version](https://docs.aws.amazon.com/eks/latest/userguide/update-cluster.html) in the **Amazon EKS User Guide**.
## [EKS.3] EKS clusters should use encrypted Kubernetes secrets
**Related requirements:** NIST.800-53.r5 SC-8, NIST.800-53.r5 SC-12, NIST.800-53.r5 SC-13, NIST.800-53.r5 SC-28, PCI DSS v4.0.1/8.3.2
**Category:** Protect > Data Protection > Encryption of data-at-rest
**Severity:** Medium
**Resource type:** `AWS::EKS::Cluster`
**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/eks-cluster-secrets-encrypted.html](https://docs.aws.amazon.com/config/latest/developerguide/eks-cluster-secrets-encrypted.html)
**Schedule type:** Periodic
**Parameters:** None
This control checks whether an Amazon EKS cluster uses encrypted Kubernetes secrets. The control fails if the cluster's Kubernetes secrets aren't encrypted.
When you encrypt secrets, you can use AWS Key Management Service (AWS KMS) keys to provide envelope encryption of Kubernetes secrets stored in etcd for your cluster. This encryption is in addition to the EBS volume encryption that is enabled by default for all data (including secrets) that is stored in etcd as part of an EKS cluster. Using secrets encryption for your EKS cluster allows you to deploy a defense in depth strategy for Kubernetes applications by encrypting Kubernetes secrets with a KMS key that you define and manage.
### Remediation
To enable secrets encryption on an EKS cluster, see [Enabling secret encryption on an existing cluster](https://docs.aws.amazon.com/eks/latest/userguide/enable-kms.html) in the **Amazon EKS User Guide**.
## [EKS.6] EKS clusters should be tagged
**Category:** Identify > Inventory > Tagging
**Severity:** Low
**Resource type:** `AWS::EKS::Cluster`
**AWS Config rule:** `tagged-eks-cluster` (custom Security Hub CSPM rule)
**Schedule type:** Change triggered
**Parameters:**
| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value |
| --- | --- | --- | --- | --- |
| requiredTagKeys | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive. | StringList (maximum of 6 items) | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions). | No default value |
This control checks whether an Amazon EKS cluster has tags with the specific keys defined in the parameter `requiredTagKeys`. The control fails if the cluster doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredTagKeys`. If the parameter `requiredTagKeys` isn't provided, the control only checks for the existence of a tag key and fails if the cluster isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.
A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [What is ABAC for AWS?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.
**Note**
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Tagging your AWS resources](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *AWS General Reference*.
### Remediation
To add tags to an EKS cluster, see [Tagging your Amazon EKS resources](https://docs.aws.amazon.com/eks/latest/userguide/eks-using-tags.html) in the **Amazon EKS User Guide**.
## [EKS.7] EKS identity provider configurations should be tagged
**Category:** Identify > Inventory > Tagging
**Severity:** Low
**Resource type:** `AWS::EKS::IdentityProviderConfig`
**AWS Config rule:** `tagged-eks-identityproviderconfig` (custom Security Hub CSPM rule)
**Schedule type:** Change triggered
**Parameters:**
| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value |
| --- | --- | --- | --- | --- |
| requiredTagKeys | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive. | StringList (maximum of 6 items) | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions). | No default value |
This control checks whether an Amazon EKS identity provider configuration has tags with the specific keys defined in the parameter `requiredTagKeys`. The control fails if the configuration doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredTagKeys`. If the parameter `requiredTagKeys` isn't provided, the control only checks for the existence of a tag key and fails if the configuration isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.
A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [What is ABAC for AWS?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.
**Note**
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Tagging your AWS resources](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *AWS General Reference*.
### Remediation
To add tags to an EKS identity provider configurations, see [Tagging your Amazon EKS resources](https://docs.aws.amazon.com/eks/latest/userguide/eks-using-tags.html) in the **Amazon EKS User Guide**.
## [EKS.8] EKS clusters should have audit logging enabled
**Related requirements:** NIST.800-53.r5 AC-2(12), NIST.800-53.r5 AC-2(4), NIST.800-53.r5 AC-4(26), NIST.800-53.r5 AC-6(9), NIST.800-53.r5 AU-10, NIST.800-53.r5 AU-12, NIST.800-53.r5 AU-2, NIST.800-53.r5 AU-3, NIST.800-53.r5 AU-6(3), NIST.800-53.r5 AU-6(4), NIST.800-53.r5 AU-9(7), NIST.800-53.r5 CA-7, NIST.800-53.r5 SC-7(9), NIST.800-53.r5 SI-3(8), NIST.800-53.r5 SI-4, NIST.800-53.r5 SI-4(20), NIST.800-53.r5 SI-7(8), PCI DSS v4.0.1/10.2.1
**Category:** Identify > Logging
**Severity:** Medium
**Resource type:** `AWS::EKS::Cluster`
**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/eks-cluster-log-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/eks-cluster-log-enabled.html)
**Schedule type:** Change triggered
**Parameters:**
+ `logTypes: audit` (not customizable)
This control checks whether an Amazon EKS cluster has audit logging enabled. The control fails if audit logging isn't enabled for the cluster.
**Note**
This control doesn't check whether Amazon EKS audit logging is enabled through Amazon Security Lake for the AWS account.
EKS control plane logging provides audit and diagnostic logs directly from the EKS control plane to Amazon CloudWatch Logs in your account. You can select the log types you need, and logs are sent as log streams to a group for each EKS cluster in CloudWatch. Logging provides visibility into the access and performance of EKS clusters. By sending EKS control plane logs for your EKS clusters to CloudWatch Logs, you can record operations for audit and diagnostic purposes in a central location.
### Remediation
To enable audit logs for your EKS cluster, see [Enabling and disabling control plane logs ](https://docs.aws.amazon.com/eks/latest/userguide/control-plane-logs.html#enabling-control-plane-log-export) in the **Amazon EKS User Guide**.
## [EKS.9] EKS node groups should run on a supported Kubernetes version
**Category:** Identify > Vulnerability, patch, and version management
**Severity:** High
**Resource type:** `AWS::EKS::Nodegroup`
**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/eks-nodegroup-supported-version-check.html](https://docs.aws.amazon.com/config/latest/developerguide/eks-nodegroup-supported-version-check.html)
**Schedule type:** Change triggered
**Parameters:**
+ `oldestVersionSupported`: `1.33` (not customizable)
This control checks whether an Amazon EKS node group runs on a supported Kubernetes version. The control fails if the EKS node group runs on an unsupported version.
Running EKS node groups on unsupported Kubernetes versions means those nodes no longer receive security patches, bug fixes, or compatibility updates from AWS. Unsupported versions may contain known vulnerabilities that have been addressed in newer releases, and they may experience compatibility issues with updated AWS services, container images, and third-party tools in the Kubernetes ecosystem. If your application doesn't require a specific version of Kubernetes, we recommend that you use the latest available Kubernetes version that's supported by Amazon EKS for your node groups. For more information, see [Amazon EKS Kubernetes release calendar](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html#kubernetes-release-calendar) and [Understand each phase of node updates](https://docs.aws.amazon.com/eks/latest/userguide/managed-node-update-behavior.html) in the **Amazon EKS User Guide**.
### Remediation
To update an EKS node group, see [Update a managed node group for your cluster](https://docs.aws.amazon.com/eks/latest/userguide/update-managed-node-group.html) in the **Amazon EKS User Guide**.