Security Hub controls for Amazon EKS - AWS Security Hub
[EKS.1] EKS cluster endpoints should not be publicly accessible[EKS.2] EKS clusters should run on a supported Kubernetes version[EKS.3] EKS clusters should use encrypted Kubernetes secrets[EKS.6] EKS clusters should be tagged[EKS.7] EKS identity provider configurations should be tagged[EKS.8] EKS clusters should have audit logging enabled

Security Hub controls for Amazon EKS

These Security Hub controls evaluate the Amazon Elastic Kubernetes Service (Amazon EKS) service and resources.

These controls may not be available in all AWS Regions. For more information, see Availability of controls by Region.

[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)

Category: Protect > Secure network configuration > Resources not publicly accessible

Severity: High

Resource type: AWS::EKS::Cluster

AWS Config rule: eks-endpoint-no-public-access

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 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 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)

Category: Identify > Vulnerability, patch, and version management

Severity: High

Resource type: AWS::EKS::Cluster

AWS Config rule: eks-cluster-supported-version

Schedule type: Change triggered

Parameters:

  • oldestVersionSupported: 1.28 (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 and Amazon EKS version support and FAQ in the Amazon EKS User Guide.

Remediation

To update an EKS cluster, Updating an Amazon EKS cluster Kubernetes version 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 SI-28

Category: Protect > Data Protection > Encryption of data-at-rest

Severity: Medium

Resource type: AWS::EKS::Cluster

AWS Config rule: eks-secrets-encrypted

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 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 Configrule: tagged-eks-cluster (custom Security Hub rule)

Schedule type: Change triggered

Parameters:

Parameter Description Type Allowed custom values Security Hub default value
requiredTagKeys List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive. StringList List of tags that meet AWS requirements 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? 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 in the AWS General Reference.

Remediation

To add tags to an EKS cluster, see Tagging your Amazon EKS resources 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 Configrule: tagged-eks-identityproviderconfig (custom Security Hub rule)

Schedule type: Change triggered

Parameters:

Parameter Description Type Allowed custom values Security Hub default value
requiredTagKeys List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive. StringList List of tags that meet AWS requirements 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? 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 in the AWS General Reference.

Remediation

To add tags to an EKS identity provider configurations, see Tagging your Amazon EKS resources 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)

Category: Identify > Logging

Severity: Medium

Resource type: AWS::EKS::Cluster

AWS Config rule: eks-cluster-log-enabled

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 in the Amazon EKS User Guide.