**Help improve this page** 

To contribute to this user guide, choose the **Edit this page on GitHub** link that is located in the right pane of every page.

# Security considerations for Amazon Elastic Kubernetes Service
<a name="security-eks"></a>

The following are considerations for security of the cloud, as they affect Amazon EKS.

**Topics**
+ [

# Infrastructure security in Amazon EKS
](infrastructure-security.md)
+ [

# Understand resilience in Amazon EKS clusters
](disaster-recovery-resiliency.md)
+ [

# Cross-service confused deputy prevention in Amazon EKS
](cross-service-confused-deputy-prevention.md)

# Infrastructure security in Amazon EKS
<a name="infrastructure-security"></a>

As a managed service, Amazon Elastic Kubernetes Service is protected by AWS global network security. For information about AWS security services and how AWS protects infrastructure, see [AWS Cloud Security](https://aws.amazon.com/security/). To design your AWS environment using the best practices for infrastructure security, see [Infrastructure Protection](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/infrastructure-protection.html) in *Security Pillar AWS Well‐Architected Framework*.

You use AWS published API calls to access Amazon EKS through the network. Clients must support the following:
+ Transport Layer Security (TLS). We require TLS 1.2 and recommend TLS 1.3.
+ Cipher suites with perfect forward secrecy (PFS) such as DHE (Ephemeral Diffie-Hellman) or ECDHE (Elliptic Curve Ephemeral Diffie-Hellman). Most modern systems such as Java 7 and later support these modes.

Additionally, requests must be signed by using an access key ID and a secret access key that is associated with an IAM principal. Or you can use the [AWS Security Token Service](https://docs.aws.amazon.com/STS/latest/APIReference/welcome.html) (AWS STS) to generate temporary security credentials to sign requests.

When you create an Amazon EKS cluster, you specify the VPC subnets for your cluster to use. Amazon EKS requires subnets in at least two Availability Zones. We recommend a VPC with public and private subnets so that Kubernetes can create public load balancers in the public subnets that load balance traffic to Pods running on nodes that are in private subnets.

For more information about VPC considerations, see [View Amazon EKS networking requirements for VPC and subnets](network-reqs.md).

If you create your VPC and node groups with the AWS CloudFormation templates provided in the [Get started with Amazon EKS](getting-started.md) walkthrough, then your control plane and node security groups are configured with our recommended settings.

For more information about security group considerations, see [View Amazon EKS security group requirements for clusters](sec-group-reqs.md).

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 (using Kubernetes management tools such as `kubectl`). By default, this API server endpoint is public to the internet, and access to the API server is secured using a combination of AWS Identity and Access Management (IAM) and native Kubernetes [Role Based Access Control](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) (RBAC).

You can enable private access to the Kubernetes API server so that all communication between your nodes and the API server stays within your VPC. You can limit the IP addresses that can access your API server from the internet, or completely disable internet access to the API server.

For more information about modifying cluster endpoint access, see [Modifying cluster endpoint access](cluster-endpoint.md#modify-endpoint-access).

You can implement Kubernetes *network policies* with the Amazon VPC CNI or third-party tools such as [Project Calico](https://docs.tigera.io/calico/latest/about/). For more information about using the Amazon VPC CNI for network policies, see [Limit Pod traffic with Kubernetes network policies](cni-network-policy.md). Project Calico is a third party open source project. For more information, see the [Project Calico documentation](https://docs.tigera.io/calico/latest/getting-started/kubernetes/managed-public-cloud/eks/).

# Access Amazon EKS using AWS PrivateLink
<a name="vpc-interface-endpoints"></a>

You can use AWS PrivateLink to create a private connection between your VPC and Amazon Elastic Kubernetes Service. You can access Amazon EKS as if it were in your VPC, without the use of an internet gateway, NAT device, VPN connection, or AWS Direct Connect connection. Instances in your VPC don’t need public IP addresses to access Amazon EKS.

You establish this private connection by creating an interface endpoint powered by AWS PrivateLink. We create an endpoint network interface in each subnet that you enable for the interface endpoint. These are requester-managed network interfaces that serve as the entry point for traffic destined for Amazon EKS.

For more information, see [Access AWS services through AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/privatelink-access-aws-services.html) in the * AWS PrivateLink Guide*.

## Before you begin
<a name="vpc-endpoint-prerequisites"></a>

Before you start, make sure you have performed the following tasks:
+ Review [Access an AWS service using an interface VPC endpoint](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#considerations-interface-endpoints) in the * AWS PrivateLink Guide* 

## Considerations
<a name="vpc-endpoint-considerations"></a>
+  **Support and Limitations**: Amazon EKS interface endpoints enable secure access to all Amazon EKS API actions from your VPC but come with specific limitations: they do not support access to Kubernetes APIs, as these have a separate private endpoint, you cannot configure Amazon EKS to be accessible only through the interface endpoint.
+  **Pricing**: Using interface endpoints for Amazon EKS incurs standard AWS PrivateLink charges: hourly charges for each endpoint provisioned in each Availability Zone, data processing charges for traffic through the endpoint. To learn more, see [AWS PrivateLink pricing](https://aws.amazon.com/privatelink/pricing/).
+  **Security and Access Control**: We recommend enhancing security and controlling access with these additional configurations—use VPC endpoint policies to control access to Amazon EKS through the interface endpoint, associate security groups with endpoint network interfaces to manage traffic, use VPC flow logs to capture and monitor IP traffic to and from the interface endpoints, with logs publishable to Amazon CloudWatch or Amazon S3. To learn more, see [Control access to VPC endpoints using endpoint policies](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-access.html) and [Logging IP traffic using VPC Flow Logs](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html).
+  **Connectivity Options**: Interface endpoints offer flexible connectivity options using **on-premises access** (connect your on-premises data center to a VPC with the interface endpoint using AWS Direct Connect or AWS Site-to-Site VPN) or via **inter-VPC connectivity** (use AWS Transit Gateway or VPC peering to connect other VPCs to the VPC with the interface endpoint, keeping traffic within the AWS network).
+  **IP Version Support**: Endpoints created before August 2024 support only IPv4 using eks.region.amazonaws.com. New endpoints created after August 2024 support dual-stack IPv4 and IPv6 (e.g., eks.region.amazonaws.com, eks.region.api.aws).
+  **Regional Availability**: AWS PrivateLink for the EKS API is not available in Asia Pacific (Malaysia) (ap-southeast-5), Asia Pacific (Thailand) (ap-southeast-7), Mexico (Central) (mx-central-1), and Asia Pacific (Taipei) (ap-east-2) regions. AWS PrivateLink support for eks-auth (EKS Pod Identity) is available in the Asia Pacific (Malaysia) (ap-southeast-5) region.

## Create an interface endpoint for Amazon EKS
<a name="vpc-endpoint-create"></a>

You can create an interface endpoint for Amazon EKS using either the Amazon VPC console or the AWS Command Line Interface (AWS CLI). For more information, see [Create a VPC endpoint](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#create-interface-endpoint-aws) in the * AWS PrivateLink Guide*.

Create an interface endpoint for Amazon EKS using the following service names:

### EKS API
<a name="_eks_api"></a>
+ com.amazonaws.region-code.eks
+ com.amazonaws.region-code.eks-fips (for FIPS-compliant endpoints)

### EKS Auth API (EKS Pod Identity)
<a name="_eks_auth_api_eks_pod_identity"></a>
+ com.amazonaws.region-code.eks-auth

## Private DNS feature for Amazon EKS interface endpoints
<a name="vpc-endpoint-private-dns"></a>

The private DNS feature, enabled by default for interface endpoints of Amazon EKS and other AWS services, facilitates secure and private API requests using default Regional DNS names. This feature ensures that API calls are routed through the interface endpoint over the private AWS network, enhancing security and performance.

The private DNS feature activates automatically when you create an interface endpoint for Amazon EKS or other AWS services. To enable, you need to configure your VPC correctly by setting specific attributes:
+  **enableDnsHostnames**: Allows instances within the VPC to have DNS hostnames.
+  **enableDnsSupport**: Enables DNS resolution throughout the VPC.

For step-by-step instructions to check or modify these settings, see [View and update DNS attributes for your VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-dns-updating).

### DNS names and IP address types
<a name="_dns_names_and_ip_address_types"></a>

With the private DNS feature enabled, you can use specific DNS names to connect to Amazon EKS, and these options evolve over time:
+  **eks.region.amazonaws.com**: The traditional DNS name, resolving only to IPv4 addresses before August 2024. For existing endpoints updated to dual-stack, this name resolves to both IPv4 and IPv6 addresses.
+  **eks.region.api.aws**: Available for new endpoints created after August 2024, this dual-stack DNS name resolves to both IPv4 and IPv6 addresses.

After August 2024, new interface endpoints come with two DNS names, and you can opt for the dual-stack IP address type. For existing endpoints, updating to dual-stack modifies **eks.region.amazonaws.com** to support both IPv4 and IPv6.

### Using the Private DNS feature
<a name="_using_the_private_dns_feature"></a>

Once configured, the private DNS feature can be integrated into your workflows, offering the following capabilities:
+  **API Requests**: Use the default Regional DNS names, either `eks.region.amazonaws.com` or `eks.region.api.aws`, based on your endpoint’s setup to make API requests to Amazon EKS.
+  **Application Compatibility**: Your existing applications that call EKS APIs require no changes to leverage this feature.
+  ** AWS CLI with Dual-Stack**: To use the dual-stack endpoints with the AWS CLI, see the [Dual-stack and FIPS endpoints](https://docs.aws.amazon.com/sdkref/latest/guide/feature-endpoints.html) configuration in the * AWS SDKs and Tools Reference Guide*.
+  **Automatic Routing**: Any call to the Amazon EKS default service endpoint is automatically directed through the interface endpoint, ensuring private and secure connectivity.

# Understand resilience in Amazon EKS clusters
<a name="disaster-recovery-resiliency"></a>

The AWS global infrastructure is built around AWS Regions and Availability Zones. AWS Regions provide multiple physically separated and isolated Availability Zones, which are connected with low-latency, high-throughput, and highly redundant networking. With Availability Zones, you can design and operate applications and databases that automatically fail over between Availability Zones without interruption. Availability Zones are more highly available, fault tolerant, and scalable than traditional single or multiple data center infrastructures.

Amazon EKS runs and scales the Kubernetes control plane across multiple AWS Availability Zones to ensure high availability. Amazon EKS automatically scales control plane instances based on load, detects and replaces unhealthy control plane instances, and automatically patches the control plane. After you initiate a version update, Amazon EKS updates your control plane for you, maintaining high availability of the control plane during the update.

This control plane consists of at least two API server instances and three `etcd` instances that run across three Availability Zones within an AWS Region. Amazon EKS:
+ Actively monitors the load on control plane instances and automatically scales them to ensure high performance.
+ Automatically detects and replaces unhealthy control plane instances, restarting them across the Availability Zones within the AWS Region as needed.
+ Leverages the architecture of AWS Regions in order to maintain high availability. Because of this, Amazon EKS is able to offer an [SLA for API server endpoint availability](https://aws.amazon.com/eks/sla).

For more information about AWS Regions and Availability Zones, see [AWS global infrastructure](https://aws.amazon.com/about-aws/global-infrastructure/).

# Cross-service confused deputy prevention in Amazon EKS
<a name="cross-service-confused-deputy-prevention"></a>

The confused deputy problem is a security issue where an entity that doesn’t have permission to perform an action can coerce a more-privileged entity to perform the action. In AWS, cross-service impersonation can result in the confused deputy problem. Cross-service impersonation can occur when one service (the *calling service*) calls another service (the *called service*). The calling service can be manipulated to use its permissions to act on another customer’s resources in a way it should not otherwise have permission to access. To prevent this, AWS provides tools that help you protect your data for all services with service principals that have been given access to resources in your account.

We recommend using the [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn), [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount) global condition context keys in resource policies to limit the permissions that Amazon Elastic Kubernetes Service (Amazon EKS) gives another service to the resource.

 `aws:SourceArn`   
Use `aws:SourceArn` to associate only one resource with cross-service access.

 `aws:SourceAccount`   
Use `aws:SourceAccount` to let any resource in that account be associated with the cross-service use.

The most effective way to protect against the confused deputy problem is to use the `aws:SourceArn` global condition context key with the full ARN of the resource. If you don’t know the full ARN of the resource or if you are specifying multiple resources, use the `aws:SourceArn` global context condition key with wildcard characters (\$1) for the unknown portions of the ARN. For example, ` arn:aws:<servicename>:*:<123456789012>:*`.

If the `aws:SourceArn` value does not contain the account ID, such as an Amazon S3 bucket ARN, you must use both `aws:SourceAccount` and `aws:SourceArn` to limit permissions.

## Amazon EKS cluster role cross-service confused deputy prevention
<a name="cross-service-confused-deputy-cluster-role"></a>

An Amazon EKS cluster IAM role is required for each cluster. Kubernetes clusters managed by Amazon EKS use this role to manage nodes and the [legacy Cloud Provider](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/guide/service/annotations/#legacy-cloud-provider) uses this role to create load balancers with Elastic Load Balancing for services. These cluster actions can only affect the same account, so we recommend that you limit each cluster role to that cluster and account. This is a specific application of the AWS recommendation to follow the *principle of least privilege* in your account.

 **Source ARN format** 

The value of `aws:SourceArn` must be the ARN of an EKS cluster in the format ` arn:aws:eks:region:account:cluster/cluster-name `. For example, ` arn:aws:eks:us-west-2:123456789012:cluster/my-cluster` .

 **Trust policy format for EKS cluster roles** 

The following example shows how you can use the `aws:SourceArn` and `aws:SourceAccount` global condition context keys in Amazon EKS to prevent the confused deputy problem.

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "eks.amazonaws.com"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "ArnLike": {
          "aws:SourceArn": "arn:aws:eks:us-west-2:123456789012:cluster/my-cluster"
          },
        "StringEquals": {
            "aws:SourceAccount": "123456789012"
        }
      }
    }
  ]
}
```