**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 in Amazon EKS
Cloud security at AWS is the highest priority. As an AWS customer, you benefit from a data center and network architecture that is built to meet the requirements of the most security-sensitive organizations.
Security is a shared responsibility between AWS and you. The [shared responsibility model](https://aws.amazon.com/compliance/shared-responsibility-model/) describes this as security *of* the cloud and security *in* the cloud:
+ **Security of the cloud** – AWS is responsible for protecting the infrastructure that runs AWS services in the AWS Cloud. For Amazon EKS, AWS is responsible for the Kubernetes control plane, which includes the control plane nodes and `etcd` database. Third-party auditors regularly test and verify the effectiveness of our security as part of the [AWS compliance programs](https://aws.amazon.com/compliance/programs/). To learn about the compliance programs that apply to Amazon EKS, see [AWS Services in Scope by Compliance Program](https://aws.amazon.com/compliance/services-in-scope/).
+ **Security in the cloud** – Your responsibility includes the following areas.
+ The security configuration of the data plane, including the configuration of the security groups that allow traffic to pass from the Amazon EKS control plane into the customer VPC
+ The configuration of the nodes and the containers themselves
+ The node’s operating system (including updates and security patches)
+ Other associated application software:
+ Setting up and managing network controls, such as firewall rules
+ Managing platform-level identity and access management, either with or in addition to IAM
+ The sensitivity of your data, your company’s requirements, and applicable laws and regulations
Amazon EKS is certified by multiple compliance programs for regulated and sensitive applications. Amazon EKS is compliant with [SOC](https://aws.amazon.com/compliance/soc-faqs/), [PCI](https://aws.amazon.com/compliance/pci-dss-level-1-faqs/), [ISO](https://aws.amazon.com/compliance/iso-certified/), [FedRAMP-Moderate](https://aws.amazon.com/compliance/fedramp/), [IRAP](https://aws.amazon.com/compliance/irap/), [C5](https://aws.amazon.com/compliance/bsi-c5/), [K-ISMS](https://aws.amazon.com/compliance/k-isms/), [ENS High](https://aws.amazon.com/compliance/esquema-nacional-de-seguridad/), [OSPAR](https://aws.amazon.com/compliance/OSPAR/), [HITRUST CSF](https://aws.amazon.com/compliance/hitrust/), and is a [HIPAA](https://aws.amazon.com/compliance/hipaa-compliance/) eligible service. For more information, see [Learn how access control works in Amazon EKS](cluster-auth.md).
This documentation helps you understand how to apply the shared responsibility model when using Amazon EKS. The following topics show you how to configure Amazon EKS to meet your security and compliance objectives. You also learn how to use other AWS services that help you to monitor and secure your Amazon EKS resources.
**Note**
Linux containers are made up of control groups (cgroups) and namespaces that help limit what a container can access, but all containers share the same Linux kernel as the host Amazon EC2 instance. Running a container as the root user (UID 0) or granting a container access to host resources or namespaces such as the host network or host PID namespace are strongly discouraged, because doing so reduces the effectiveness of the isolation that containers provide.
**Topics**
+ [
# Secure Amazon EKS clusters with best practices
](security-best-practices.md)
+ [
# Analyze vulnerabilities in Amazon EKS
](configuration-vulnerability-analysis.md)
+ [
# Compliance validation for Amazon EKS clusters
](compliance.md)
+ [
# Security considerations for Amazon Elastic Kubernetes Service
](security-eks.md)
+ [
# Security considerations for Kubernetes
](security-k8s.md)
+ [
# Security considerations for Amazon EKS Auto Mode
](auto-security.md)
+ [
# Security considerations for EKS Capabilities
](capabilities-security.md)
+ [
# Identity and access management for Amazon EKS
](security-iam.md)
# Secure Amazon EKS clusters with best practices
The Amazon EKS security best practices are in the [Best Practices for Security](https://docs.aws.amazon.com/eks/latest/best-practices/security.html) in the *Amazon EKS Best Practices Guide*.
# Analyze vulnerabilities in Amazon EKS
Security is a critical consideration for configuring and maintaining Kubernetes clusters and applications. The following lists resources for you to analyze the security configuration of your EKS clusters, resources for you to check for vulnerabilities, and integrations with AWS services that can do that analysis for you.
## The Center for Internet Security (CIS) benchmark for Amazon EKS
The [Center for Internet Security (CIS) Kubernetes Benchmark](https://www.cisecurity.org/benchmark/kubernetes/) provides guidance for Amazon EKS security configurations. The benchmark:
+ Is applicable to Amazon EC2 nodes (both managed and self-managed) where you are responsible for security configurations of Kubernetes components.
+ Provides a standard, community-approved way to ensure that you have configured your Kubernetes cluster and nodes securely when using Amazon EKS.
+ Consists of four sections; control plane logging configuration, node security configurations, policies, and managed services.
+ Supports all of the Kubernetes versions currently available in Amazon EKS and can be run using [kube-bench](https://github.com/aquasecurity/kube-bench), a standard open source tool for checking configuration using the CIS benchmark on Kubernetes clusters.
To learn more, see [Introducing The CIS Amazon EKS Benchmark](https://aws.amazon.com/blogs/containers/introducing-cis-amazon-eks-benchmark).
For an automated `aws-sample` pipeline to update your node group with a CIS benchmarked AMI, see [EKS-Optimized AMI Hardening Pipeline](https://github.com/aws-samples/pipeline-for-hardening-eks-nodes-and-automating-updates).
## Amazon EKS platform versions
Amazon EKS *platform versions* represent the capabilities of the cluster control plane, including which Kubernetes API server flags are enabled and the current Kubernetes patch version. New clusters are deployed with the latest platform version. For details, see [EKS platform-versions](https://docs.aws.amazon.com/eks/latest/userguide/platform-versions.html).
You can [update an Amazon EKS cluster](update-cluster.md) to newer Kubernetes versions. As new Kubernetes versions become available in Amazon EKS, we recommend that you proactively update your clusters to use the latest available version. For more information about Kubernetes versions in EKS, see [Amazon EKS supported versions](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html).
## Operating system vulnerability list
### AL2023 vulnerability list
Track security or privacy events for Amazon Linux 2023 at the [Amazon Linux Security Center](https://alas.aws.amazon.com/alas2023.html) or subscribe to the associated [RSS feed](https://alas.aws.amazon.com/AL2023/alas.rss). Security and privacy events include an overview of the issue affected, packages, and instructions for updating your instances to correct the issue.
### Amazon Linux 2 vulnerability list
Track security or privacy events for Amazon Linux 2 at the [Amazon Linux Security Center](https://alas.aws.amazon.com/alas2.html) or subscribe to the associated [RSS feed](https://alas.aws.amazon.com/AL2/alas.rss). Security and privacy events include an overview of the issue affected, packages, and instructions for updating your instances to correct the issue.
## Node detection with Amazon Inspector
You can use [Amazon Inspector](https://docs.aws.amazon.com/inspector/latest/userguide/inspector_introduction.html) to check for unintended network accessibility of your nodes and for vulnerabilities on those Amazon EC2 instances.
## Cluster and node detection with Amazon GuardDuty
Amazon GuardDuty threat detection service that helps protect your accounts, containers, workloads, and the data within your AWS environment. Among other features, GuardDuty offers the following two features that detect potential threats to your EKS clusters: *EKS Protection* and *Runtime Monitoring*.
For more information, see [Detect threats with Amazon GuardDuty](integration-guardduty.md).
# Compliance validation for Amazon EKS clusters
To learn whether an AWS service is within the scope of specific compliance programs, see [AWS services in Scope by Compliance Program](https://aws.amazon.com/compliance/services-in-scope/) and choose the compliance program that you are interested in. For general information, see [AWS Compliance Programs](https://aws.amazon.com/compliance/programs/).
You can download third-party audit reports using AWS Artifact. For more information, see [Downloading Reports in AWS Artifact](https://docs.aws.amazon.com/artifact/latest/ug/downloading-documents.html).
Your compliance responsibility when using AWS services is determined by the sensitivity of your data, your company’s compliance objectives, and applicable laws and regulations. AWS provides the following resources to help with compliance:
+ [Security Compliance & Governance](https://aws.amazon.com/solutions/security/security-compliance-governance/) – These solution implementation guides discuss architectural considerations and provide steps for deploying security and compliance features.
+ [HIPAA Eligible Services Reference](https://aws.amazon.com/compliance/hipaa-eligible-services-reference/) – Lists HIPAA eligible services. Not all AWS services are HIPAA eligible.
+ [AWS Compliance Resources](https://aws.amazon.com/compliance/resources/) – This collection of workbooks and guides might apply to your industry and location.
+ [AWS Customer Compliance Guides](https://d1.awsstatic.com/whitepapers/compliance/AWS_Customer_Compliance_Guides.pdf) – Understand the shared responsibility model through the lens of compliance. The guides summarize the best practices for securing AWS services and map the guidance to security controls across multiple frameworks (including National Institute of Standards and Technology (NIST), Payment Card Industry Security Standards Council (PCI), and International Organization for Standardization (ISO)).
+ [Evaluating Resources with Rules](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html) in the * AWS Config Developer Guide* – The AWS Config service assesses how well your resource configurations comply with internal practices, industry guidelines, and regulations.
+ [AWS Security Hub](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html) – This AWS service provides a comprehensive view of your security state within AWS. Security Hub uses security controls to evaluate your AWS resources and to check your compliance against security industry standards and best practices. For a list of supported services and controls, see [Security Hub controls reference](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-controls-reference.html).
+ [Amazon GuardDuty](https://docs.aws.amazon.com/guardduty/latest/ug/what-is-guardduty.html) – This AWS service detects potential threats to your AWS accounts, workloads, containers, and data by monitoring your environment for suspicious and malicious activities. GuardDuty can help you address various compliance requirements, like PCI DSS, by meeting intrusion detection requirements mandated by certain compliance frameworks.
+ [AWS Audit Manager](https://docs.aws.amazon.com/audit-manager/latest/userguide/what-is.html) – This AWS service helps you continuously audit your AWS usage to simplify how you manage risk and compliance with regulations and industry standards.
# Security considerations for Amazon Elastic Kubernetes Service
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
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
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
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
+ **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
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
+ com.amazonaws.region-code.eks
+ com.amazonaws.region-code.eks-fips (for FIPS-compliant endpoints)
### EKS Auth API (EKS Pod Identity)
+ com.amazonaws.region-code.eks-auth
## Private DNS feature for Amazon EKS interface endpoints
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
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
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
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
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::*:<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
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"
}
}
}
]
}
```
# Security considerations for Kubernetes
The following are considerations for security in the cloud, as they affect Kubernetes in Amazon EKS clusters. For an in-depth review of security controls and practices in Kubernetes, see [Cloud Native Security and Kubernetes](https://kubernetes.io/docs/concepts/security/cloud-native-security/) in the Kubernetes documentation.
**Topics**
+ [
# Secure workloads with Kubernetes certificates
](cert-signing.md)
+ [
# Understand Amazon EKS created RBAC roles and users
](default-roles-users.md)
+ [
# Encrypt Kubernetes secrets with KMS on existing clusters
](enable-kms.md)
+ [
# Use AWS Secrets Manager secrets with Amazon EKS Pods
](manage-secrets.md)
+ [
# Default envelope encryption for all Kubernetes API Data
](envelope-encryption.md)
+ [
# Harden Kubernetes RBAC in Amazon EKS
](rbac-hardening.md)
# Secure workloads with Kubernetes certificates
The Kubernetes Certificates API automates [X.509](https://www.itu.int/rec/T-REC-X.509) credential provisioning. The API features a command line interface for Kubernetes API clients to request and obtain [X.509 certificates](https://kubernetes.io/docs/tasks/tls/managing-tls-in-a-cluster/) from a Certificate Authority (CA). You can use the `CertificateSigningRequest` (CSR) resource to request that a denoted signer sign the certificate. Your requests are either approved or denied before they’re signed. Kubernetes supports both built-in signers and custom signers with well-defined behaviors. This way, clients can predict what happens to their CSRs. To learn more about certificate signing, see [signing requests](https://kubernetes.io/docs/reference/access-authn-authz/certificate-signing-requests/).
One of the built-in signers is `kubernetes.io/legacy-unknown`. The `v1beta1` API of CSR resource honored this legacy-unknown signer. However, the stable `v1` API of CSR doesn’t allow the `signerName` to be set to `kubernetes.io/legacy-unknown`.
If you want to use Amazon EKS CA for generating certificates on your clusters, you must use a custom signer. To use the CSR `v1` API version and generate a new certificate, you must migrate any existing manifests and API clients. Existing certificates that were created with the existing `v1beta1` API are valid and function until the certificate expires. This includes the following:
+ Trust distribution: None. There’s no standard trust or distribution for this signer in a Kubernetes cluster.
+ Permitted subjects: Any
+ Permitted x509 extensions: Honors subjectAltName and key usage extensions and discards other extensions
+ Permitted key usages: Must not include usages beyond ["key encipherment", "digital signature", "server auth"]
**Note**
Client certificate signing is not supported.
+ Expiration/certificate lifetime: 1 year (default and maximum)
+ CA bit allowed/disallowed: Not allowed
## Example CSR generation with signerName
These steps shows how to generate a serving certificate for DNS name `myserver.default.svc` using `signerName: beta.eks.amazonaws.com/app-serving`. Use this as a guide for your own environment.
1. Run the `openssl genrsa -out myserver.key 2048` command to generate an RSA private key.
```
openssl genrsa -out myserver.key 2048
```
1. Run the following command to generate a certificate request.
```
openssl req -new -key myserver.key -out myserver.csr -subj "/CN=myserver.default.svc"
```
1. Generate a `base64` value for the CSR request and store it in a variable for use in a later step.
```
base_64=$(cat myserver.csr | base64 -w 0 | tr -d "
")
```
1. Run the following command to create a file named `mycsr.yaml`. In the following example, `beta.eks.amazonaws.com/app-serving` is the `signerName`.
```
cat >mycsr.yaml < myserver.crt
```
# Understand Amazon EKS created RBAC roles and users
When you create a Kubernetes cluster, several default Kubernetes identities are created on that cluster for the proper functioning of Kubernetes. Amazon EKS creates Kubernetes identities for each of its default components. The identities provide Kubernetes role-based authorization control (RBAC) for the cluster components. For more information, see [Using RBAC Authorization](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) in the Kubernetes documentation.
When you install optional [add-ons](eks-add-ons.md) to your cluster, additional Kubernetes identities might be added to your cluster. For more information about identities not addressed by this topic, see the documentation for the add-on.
You can view the list of Amazon EKS created Kubernetes identities on your cluster using the AWS Management Console or `kubectl` command line tool. All of the user identities appear in the `kube` audit logs available to you through Amazon CloudWatch.
## AWS Management Console
### Prerequisite
The [IAM principal](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) that you use must have the permissions described in [Required permissions](view-kubernetes-resources.md#view-kubernetes-resources-permissions).
### To view Amazon EKS created identities using the AWS Management Console
1. Open the [Amazon EKS console](https://console.aws.amazon.com/eks/home#/clusters).
1. In the **Clusters** list, choose the cluster that contains the identities that you want to view.
1. Choose the **Resources** tab.
1. Under **Resource types**, choose **Authorization**.
1. Choose, **ClusterRoles**, **ClusterRoleBindings**, **Roles**, or **RoleBindings**. All resources prefaced with **eks** are created by Amazon EKS. Additional Amazon EKS created identity resources are:
+ The **ClusterRole** and **ClusterRoleBinding** named **aws-node**. The **aws-node** resources support the [Amazon VPC CNI plugin for Kubernetes](managing-vpc-cni.md), which Amazon EKS installs on all clusters.
+ A **ClusterRole** named **vpc-resource-controller-role** and a **ClusterRoleBinding** named **vpc-resource-controller-rolebinding**. These resources support the [Amazon VPC resource controller](https://github.com/aws/amazon-vpc-resource-controller-k8s), which Amazon EKS installs on all clusters.
In addition to the resources that you see in the console, the following special user identities exist on your cluster, though they’re not visible in the cluster’s configuration:
+ ** `eks:cluster-bootstrap` ** – Used for `kubectl` operations during cluster bootstrap.
+ ** `eks:support-engineer` ** – Used for cluster management operations.
1. Choose a specific resource to view details about it. By default, you’re shown information in **Structured view**. In the top-right corner of the details page you can choose **Raw view** to see all information for the resource.
## Kubectl
### Prerequisite
The entity that you use (AWS Identity and Access Management (IAM) or OpenID Connect (OIDC)) to list the Kubernetes resources on the cluster must be authenticated by IAM or your OIDC identity provider. The entity must be granted permissions to use the Kubernetes `get` and `list` verbs for the `Role`, `ClusterRole`, `RoleBinding`, and `ClusterRoleBinding` resources on your cluster that you want the entity to work with. For more information about granting IAM entities access to your cluster, see [Grant IAM users and roles access to Kubernetes APIs](grant-k8s-access.md). For more information about granting entities authenticated by your own OIDC provider access to your cluster, see [Grant users access to Kubernetes with an external OIDC provider](authenticate-oidc-identity-provider.md).
### To view Amazon EKS created identities using `kubectl`
Run the command for the type of resource that you want to see. All returned resources that are prefaced with **eks** are created by Amazon EKS. In addition to the resources returned in the output from the commands, the following special user identities exist on your cluster, though they’re not visible in the cluster’s configuration:
+ ** `eks:cluster-bootstrap` ** – Used for `kubectl` operations during cluster bootstrap.
+ ** `eks:support-engineer` ** – Used for cluster management operations.
**ClusterRoles** – `ClusterRoles` are scoped to your cluster, so any permission granted to a role applies to resources in any Kubernetes namespace on the cluster.
The following command returns all of the Amazon EKS created Kubernetes `ClusterRoles` on your cluster.
```
kubectl get clusterroles | grep eks
```
In addition to the `ClusterRoles` returned in the output that are prefaced with, the following `ClusterRoles` exist.
+ ** `aws-node` ** – This `ClusterRole` supports the [Amazon VPC CNI plugin for Kubernetes](managing-vpc-cni.md), which Amazon EKS installs on all clusters.
+ ** `vpc-resource-controller-role` ** – This `ClusterRole` supports the [Amazon VPC resource controller](https://github.com/aws/amazon-vpc-resource-controller-k8s), which Amazon EKS installs on all clusters.
To see the specification for a `ClusterRole`, replace *eks:k8s-metrics* in the following command with a `ClusterRole` returned in the output of the previous command. The following example returns the specification for the *eks:k8s-metrics* `ClusterRole`.
```
kubectl describe clusterrole eks:k8s-metrics
```
An example output is as follows.
```
Name: eks:k8s-metrics
Labels:
Annotations:
PolicyRule:
Resources Non-Resource URLs Resource Names Verbs
--------- ----------------- -------------- -----
[/metrics] [] [get]
endpoints [] [] [list]
nodes [] [] [list]
pods [] [] [list]
deployments.apps [] [] [list]
```
**ClusterRoleBindings** – `ClusterRoleBindings` are scoped to your cluster.
The following command returns all of the Amazon EKS created Kubernetes `ClusterRoleBindings` on your cluster.
```
kubectl get clusterrolebindings | grep eks
```
In addition to the `ClusterRoleBindings` returned in the output, the following `ClusterRoleBindings` exist.
+ ** `aws-node` ** – This `ClusterRoleBinding` supports the [Amazon VPC CNI plugin for Kubernetes](managing-vpc-cni.md), which Amazon EKS installs on all clusters.
+ ** `vpc-resource-controller-rolebinding` ** – This `ClusterRoleBinding` supports the [Amazon VPC resource controller](https://github.com/aws/amazon-vpc-resource-controller-k8s), which Amazon EKS installs on all clusters.
To see the specification for a `ClusterRoleBinding`, replace *eks:k8s-metrics* in the following command with a `ClusterRoleBinding` returned in the output of the previous command. The following example returns the specification for the *eks:k8s-metrics* `ClusterRoleBinding`.
```
kubectl describe clusterrolebinding eks:k8s-metrics
```
An example output is as follows.
```
Name: eks:k8s-metrics
Labels:
Annotations:
Role:
Kind: ClusterRole
Name: eks:k8s-metrics
Subjects:
Kind Name Namespace
---- ---- ---------
User eks:k8s-metrics
```
**Roles** – `Roles` are scoped to a Kubernetes namespace. All Amazon EKS created `Roles` are scoped to the `kube-system` namespace.
The following command returns all of the Amazon EKS created Kubernetes `Roles` on your cluster.
```
kubectl get roles -n kube-system | grep eks
```
To see the specification for a `Role`, replace *eks:k8s-metrics* in the following command with the name of a `Role` returned in the output of the previous command. The following example returns the specification for the *eks:k8s-metrics* `Role`.
```
kubectl describe role eks:k8s-metrics -n kube-system
```
An example output is as follows.
```
Name: eks:k8s-metrics
Labels:
Annotations:
PolicyRule:
Resources Non-Resource URLs Resource Names Verbs
--------- ----------------- -------------- -----
daemonsets.apps [] [aws-node] [get]
deployments.apps [] [vpc-resource-controller] [get]
```
**RoleBindings** – `RoleBindings` are scoped to a Kubernetes namespace. All Amazon EKS created `RoleBindings` are scoped to the `kube-system` namespace.
The following command returns all of the Amazon EKS created Kubernetes `RoleBindings` on your cluster.
```
kubectl get rolebindings -n kube-system | grep eks
```
To see the specification for a `RoleBinding`, replace *eks:k8s-metrics* in the following command with a `RoleBinding` returned in the output of the previous command. The following example returns the specification for the *eks:k8s-metrics* `RoleBinding`.
```
kubectl describe rolebinding eks:k8s-metrics -n kube-system
```
An example output is as follows.
```
Name: eks:k8s-metrics
Labels:
Annotations:
Role:
Kind: Role
Name: eks:k8s-metrics
Subjects:
Kind Name Namespace
---- ---- ---------
User eks:k8s-metrics
```
# Encrypt Kubernetes secrets with KMS on existing clusters
**Important**
This procedure only applies to EKS clusters running Kubernetes version 1.27 or lower. If you are running Kubernetes version 1.28 or higher, your Kubernetes secrets are protected with envelope encryption by default. For more information, see [Default envelope encryption for all Kubernetes API Data](envelope-encryption.md).
If you enable [secrets encryption](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/), the Kubernetes secrets are encrypted using the AWS KMS key that you select. The KMS key must meet the following conditions:
+ Symmetric
+ Can encrypt and decrypt data
+ Created in the same AWS Region as the cluster
+ If the KMS key was created in a different account, the [IAM principal](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) must have access to the KMS key.
For more information, see [Allowing IAM principals in other accounts to use a KMS key](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-modifying-external-accounts.html) in the * [AWS Key Management Service Developer Guide](https://docs.aws.amazon.com/kms/latest/developerguide/) *.
**Warning**
You can’t disable secrets encryption after enabling it. This action is irreversible.
eksctl
This procedure only applies to EKS clusters running Kubernetes version 1.27 or lower. For more information, see [Default envelope encryption for all Kubernetes API Data](envelope-encryption.md).
You can enable encryption in two ways:
+ Add encryption to your cluster with a single command.
To automatically re-encrypt your secrets, run the following command.
```
eksctl utils enable-secrets-encryption \
--cluster my-cluster \
--key-arn arn:aws:kms:region-code:account:key/key
```
To opt-out of automatically re-encrypting your secrets, run the following command.
```
eksctl utils enable-secrets-encryption
--cluster my-cluster \
--key-arn arn:aws:kms:region-code:account:key/key \
--encrypt-existing-secrets=false
```
+ Add encryption to your cluster with a `kms-cluster.yaml` file.
```
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
name: my-cluster
region: region-code
secretsEncryption:
keyARN: arn:aws:kms:region-code:account:key/key
```
To have your secrets re-encrypt automatically, run the following command.
```
eksctl utils enable-secrets-encryption -f kms-cluster.yaml
```
To opt out of automatically re-encrypting your secrets, run the following command.
```
eksctl utils enable-secrets-encryption -f kms-cluster.yaml --encrypt-existing-secrets=false
```
AWS Management Console
1. This procedure only applies to EKS clusters running Kubernetes version 1.27 or lower. For more information, see [Default envelope encryption for all Kubernetes API Data](envelope-encryption.md).
1. Open the [Amazon EKS console](https://console.aws.amazon.com/eks/home#/clusters).
1. Choose the cluster that you want to add KMS encryption to.
1. Choose the **Overview** tab (this is selected by default).
1. Scroll down to the **Secrets encryption** section and choose **Enable**.
1. Select a key from the dropdown list and choose the **Enable** button. If no keys are listed, you must create one first. For more information, see [Creating keys](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html)
1. Choose the **Confirm** button to use the chosen key.
AWS CLI
1. This procedure only applies to EKS clusters running Kubernetes version 1.27 or lower. For more information, see [Default envelope encryption for all Kubernetes API Data](envelope-encryption.md).
1. Associate the [secrets encryption](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/) configuration with your cluster using the following AWS CLI command. Replace the example values with your own.
```
aws eks associate-encryption-config \
--cluster-name my-cluster \
--encryption-config '[{"resources":["secrets"],"provider":{"keyArn":"arn:aws:kms:region-code:account:key/key"}}]'
```
An example output is as follows.
```
{
"update": {
"id": "3141b835-8103-423a-8e68-12c2521ffa4d",
"status": "InProgress",
"type": "AssociateEncryptionConfig",
"params": [
{
"type": "EncryptionConfig",
"value": "[{\"resources\":[\"secrets\"],\"provider\":{\"keyArn\":\"arn:aws:kms:region-code:account:key/key\"}}]"
}
],
"createdAt": 1613754188.734,
"errors": []
}
}
```
1. You can monitor the status of your encryption update with the following command. Use the specific `cluster name` and `update ID` that was returned in the previous output. When a `Successful` status is displayed, the update is complete.
```
aws eks describe-update \
--region region-code \
--name my-cluster \
--update-id 3141b835-8103-423a-8e68-12c2521ffa4d
```
An example output is as follows.
```
{
"update": {
"id": "3141b835-8103-423a-8e68-12c2521ffa4d",
"status": "Successful",
"type": "AssociateEncryptionConfig",
"params": [
{
"type": "EncryptionConfig",
"value": "[{\"resources\":[\"secrets\"],\"provider\":{\"keyArn\":\"arn:aws:kms:region-code:account:key/key\"}}]"
}
],
"createdAt": 1613754188.734>,
"errors": []
}
}
```
1. To verify that encryption is enabled in your cluster, run the `describe-cluster` command. The response contains an `EncryptionConfig` string.
```
aws eks describe-cluster --region region-code --name my-cluster
```
After you enabled encryption on your cluster, you must encrypt all existing secrets with the new key:
**Note**
If you use `eksctl`, running the following command is necessary only if you opt out of re-encrypting your secrets automatically.
```
kubectl get secrets --all-namespaces -o json | kubectl annotate --overwrite -f - kms-encryption-timestamp="time value"
```
**Warning**
If you enable [secrets encryption](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/) for an existing cluster and the KMS key that you use is ever deleted, then there’s no way to recover the cluster. If you delete the KMS key, you permanently put the cluster in a degraded state. For more information, see [Deleting AWS KMS keys](https://docs.aws.amazon.com/kms/latest/developerguide/deleting-keys.html).
**Note**
By default, the `create-key` command creates a [symmetric encryption KMS key](https://docs.aws.amazon.com/kms/latest/developerguide/symmetric-asymmetric.html) with a key policy that gives the account root admin access on AWS KMS actions and resources. If you want to scope down the permissions, make sure that the `kms:DescribeKey` and `kms:CreateGrant` actions are permitted on the policy for the principal that calls the `create-cluster` API.
For clusters using KMS Envelope Encryption, `kms:CreateGrant` permissions are required. The condition `kms:GrantIsForAWSResource` is not supported for the CreateCluster action, and should not be used in KMS policies to control `kms:CreateGrant` permissions for users performing CreateCluster.
# Use AWS Secrets Manager secrets with Amazon EKS Pods
To show secrets from Secrets Manager and parameters from Parameter Store as files mounted in Amazon EKS Pods, you can use the AWS Secrets and Configuration Provider (ASCP) for the [Kubernetes Secrets Store CSI Driver](https://secrets-store-csi-driver.sigs.k8s.io/).
With the ASCP, you can store and manage your secrets in Secrets Manager and then retrieve them through your workloads running on Amazon EKS. You can use IAM roles and policies to limit access to your secrets to specific Kubernetes Pods in a cluster. The ASCP retrieves the Pod identity and exchanges the identity for an IAM role. ASCP assumes the IAM role of the Pod, and then it can retrieve secrets from Secrets Manager that are authorized for that role.
If you use Secrets Manager automatic rotation for your secrets, you can also use the Secrets Store CSI Driver rotation reconciler feature to ensure you are retrieving the latest secret from Secrets Manager.
**Note**
AWS Fargate (Fargate) node groups are not supported.
For more information, see [Using Secrets Manager secrets in Amazon EKS](https://docs.aws.amazon.com/secretsmanager/latest/userguide/integrating_csi_driver.html) in the AWS Secrets Manager User Guide.
# Default envelope encryption for all Kubernetes API Data
Amazon Elastic Kubernetes Service (Amazon EKS) provides default envelope encryption for all Kubernetes API data in EKS clusters running Kubernetes version 1.28 or higher.
Envelope encryption protects the data you store with the Kubernetes API server. For example, envelope encryption applies to the configuration of your Kubernetes cluster, such as `ConfigMaps`. Envelope encryption does not apply to data on nodes or EBS volumes. EKS previously supported encrypting Kubernetes secrets, and now this envelope encryption extends to all Kubernetes API data.
This provides a managed, default experience that implements defense-in-depth for your Kubernetes applications and doesn’t require any action on your part.
Amazon EKS uses AWS [Key Management Service (KMS)](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html) with [Kubernetes KMS provider v2](https://kubernetes.io/docs/tasks/administer-cluster/kms-provider/#configuring-the-kms-provider-kms-v2) for this additional layer of security with an [Amazon Web Services owned key](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-owned-cmk), and the option for you to bring your own [customer managed key](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk) (CMK) from AWS KMS.
## Understanding envelope encryption
Envelope encryption is the process of encrypting plain text data with a data encryption key (DEK) before it’s sent to the datastore (etcd), and then encrypting the DEK with a root KMS key that is stored in a remote, centrally managed KMS system (AWS KMS). This is a defense-in-depth strategy because it protects the data with an encryption key (DEK), and then adds another security layer by protecting that DEK with a separate, securely stored encryption key called a key encryption key (KEK).
## How Amazon EKS enables default envelope encryption with KMS v2 and AWS KMS
Amazon EKS uses [KMS v2](https://kubernetes.io/docs/tasks/administer-cluster/kms-provider/#kms-v2) to implement default envelope encryption for all API data in the managed Kubernetes control plane before it’s persisted in the [etcd](https://etcd.io/docs/v3.5/faq/) database. At startup, the cluster API server generates a data encryption key (DEK) from a secret seed combined with randomly generated data. Also at startup, the API server makes a call to the KMS plugin to encrypt the DEK seed using a remote key encryption key (KEK) from AWS KMS. This is a one-time call executed at startup of the API server and on KEK rotation. The API server then caches the encrypted DEK seed. After this, the API server uses the cached DEK seed to generate other single use DEKs based on a Key Derivation Function (KDF). Each of these generated DEKs is then used only once to encrypt a single Kubernetes resource before it’s stored in etcd. With the use of an encrypted cached DEK seed in KMS v2, the process of encrypting Kubernetes resources in the API server is both more performant and cost effective.
**By default, this KEK is owned by AWS, but you can optionally bring your own from AWS KMS.**
The diagram below depicts the generation and encryption of a DEK at the startup of the API server.
![\[The diagram depicts the generation and encryption of a DEK at the startup of the API server\]](http://docs.aws.amazon.com/eks/latest/userguide/images/security-generate-dek.png)
The high-level diagram below depicts the encryption of a Kubernetes resource before it’s stored in etcd.
![\[The high-level diagram depicts the encryption of a Kubernetes resource before it’s stored in etcd.\]](http://docs.aws.amazon.com/eks/latest/userguide/images/security-encrypt-request.png)
## Frequently asked questions
### How does default envelope encryption improve the security posture of my EKS cluster?
This feature reduces the surface area and period of time in which metadata and customer content are un-encrypted. With default envelope encryption, metadata and customer content are only ever in a temporarily un-encrypted state in the kube-apiserver’s memory before being stored in etcd. T he kube-apiserver’s memory is secured through the [Nitro system](https://docs.aws.amazon.com/whitepapers/latest/security-design-of-aws-nitro-system/the-components-of-the-nitro-system.html). Amazon EKS only uses [Nitro-based EC2 instances](https://docs.aws.amazon.com/whitepapers/latest/security-design-of-aws-nitro-system/security-design-of-aws-nitro-system.html) for the managed Kubernetes control plane. These instances have security control designs that prevent any system or person from accessing their memory.
### Which version of Kubernetes do I need to run in order to have this feature?
For default envelope encryption to be enabled, your Amazon EKS cluster has to be running Kubernetes version 1.28 or later.
### Is my data still secure if I’m running a Kubernetes cluster version that doesn’t support this feature?
Yes. At AWS, [security is our highest priority](https://aws.amazon.com/security/). We base all our digital transformation and innovation on the highest security operational practices, and stay committed to raising that bar.
All of the data stored in the etcd are encrypted at the disk level for every EKS cluster, irrespective of the Kubernetes version being run. EKS uses root keys that generate volume encryption keys which are managed by the EKS service. Additionally, every Amazon EKS cluster is run in an isolated VPC using cluster-specific virtual machines. Because of this architecture, and our practices around operational security, Amazon EKS has [achieved multiple compliance ratings and standards](https://docs.aws.amazon.com/eks/latest/userguide/compliance.html) including SOC 1,2,3, PCI-DSS, ISO, and HIPAA eligibility. These compliance ratings and standards are maintained for all EKS clusters with or without default envelope encryption.
### How does envelope encryption work in Amazon EKS?
At startup, the cluster API server generates a data encryption key (DEK) from a secret seed combined with randomly generated data. Also at startup, the API server makes a call to the KMS plugin to encrypt the DEK using a remote key encryption key (KEK) from AWS KMS. This is a one-time call executed at startup of the API server and on KEK rotation. The API server then caches the encrypted DEK seed. After this, the API server uses the cached DEK seed to generate other single use DEKs based on a Key Derivation Function (KDF). Each of these generated DEKs is then used only once to encrypt a single Kubernetes resource before it’s stored in etcd.
It’s important to note that there are additional calls made from the API server to verify the health and normal functionality of the AWS KMS integration. These additional health checks are visible in your AWS CloudTrail.
### Do I have to do anything or change any permissions for this feature to work in my EKS cluster?
No, you don’t have to take any action. Envelope encryption in Amazon EKS is now a default configuration that is enabled in all clusters running Kubernetes version 1.28 or higher. The AWS KMS integration is established by the Kubernetes API server managed by AWS. This means you do not need to configure any permissions to start using KMS encryption for your cluster.
### How can I know if default envelope encryption is enabled on my cluster?
If you migrate to use your own CMK, then you will see the ARN of the KMS key associated with your cluster. Additionally, you can view the AWS CloudTrail event logs associated with the use of your cluster’s CMK.
If your cluster uses an AWS owned key, then this will be detailed in the EKS console (excluding the ARN of the key).
### Can AWS access the AWS owned key used for default envelope encryption in Amazon EKS?
No. AWS has stringent security controls in Amazon EKS that prevent any person from accessing any plaintext encryption keys used for securing data in the etcd database. These security measures are also applied to the AWS owned KMS key.
### Is default envelope encryption enabled in my existing EKS cluster?
If you are running an Amazon EKS cluster with Kubernetes version 1.28 or higher, then envelope encryption of all Kubernetes API data is enabled. For existing clusters, Amazon EKS uses the `eks:kms-storage-migrator` RBAC ClusterRole to migrate data that was previously not envelope encrypted in etcd to this new encryption state.
### What does this mean if I already enabled envelope encryption for Secrets in my EKS cluster?
If you have an existing customer managed key (CMK) in KMS that was used to envelope encrypt your Kubernetes Secrets, that same key will be used as the KEK for envelope encryption of all Kubernetes API data types in your cluster.
### Is there any additional cost to running an EKS cluster with default envelope encryption?
There is no additional cost associated with the managed Kubernetes control plane if you are using an [Amazon Web Services owned key](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-owned-cmk) for the default envelope encryption. By default, every EKS cluster running Kubernetes version 1.28 or later uses an [Amazon Web Services owned key](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-owned-cmk). However, if you use your own AWS KMS key, normal [KMS pricing](https://aws.amazon.com/kms/pricing/) will apply.
### How much does it cost to use my own AWS KMS key to encrypt Kubernetes API data in my cluster?
You pay \$11 per month to store any custom key that you create or import to KMS. KMS charges for encryption and decryption requests. There is a free tier of 20,000 requests per month per account and you pay \$10.03 per 10,000 requests above the free tier per month. This applies across all KMS usage for an account, so the cost of using your own AWS KMS key on your cluster will be impacted by the usage of this key on other clusters or AWS resources within your account.
### Will my KMS charges be higher now that my customer managed key (CMK) is being used to envelope encrypt all Kubernetes API data and not just Secrets?
No. Our implementation with KMS v2 significantly reduces the number of calls made to AWS KMS. This will in turn reduce the costs associated with your CMK irrespective of the additional Kubernetes data being encrypted or decrypted in your EKS cluster.
As detailed above, the generated DEK seed used for encryption of Kubernetes resources is stored locally in the Kubernetes API server’s cache after it has been encrypted with the remote KEK. If the encrypted DEK seed is not in the API server’s cache, the API server will call AWS KMS to encrypt the DEK seed. The API server then caches the encrypted DEK seed for future use in the cluster without calling KMS. Similarly, for decrypt requests, the API server will call AWS KMS for the first decrypt request, after which the decrypted DEK seed will be cached and used for future decrypt operations.
For more information, see [KEP-3299: KMS v2 Improvements](https://github.com/kubernetes/enhancements/tree/master/keps/sig-auth/3299-kms-v2-improvements) in the Kubernetes Enhancements on GitHub.
### Can I use the same CMK key for multiple Amazon EKS clusters?
Yes. To use a key again, you can link it to a cluster in the same region by associating the ARN with the cluster during creation. However, if you are using the same CMK for multiple EKS clusters, you should put the requisite measures in place to prevent arbitrary disablement of the CMK. Otherwise, a disabled CMK associated with multiple EKS clusters will have a wider scope of impact on the clusters depending on that key.
### What happens to my EKS cluster if my CMK becomes unavailable after default envelope encryption is enabled?
If you disable a KMS key, it cannot be used in any [cryptographic operation](https://docs.aws.amazon.com/kms/latest/developerguide/kms-cryptography.html#cryptographic-operations). Without access to an existing CMK, the API server will be unable to encrypt and persist any newly created Kubernetes objects, as well as decrypt any previously encrypted Kubernetes objects stored in etcd. If the CMK is disabled, the cluster will be immediately placed in an unhealthy/degraded state at which point we will be unable to fulfill our [Service Commitment](https://aws.amazon.com/eks/sla/) until you re-enable the associated CMK.
When a CMK is disabled, you will receive notifications about the degraded health of your EKS cluster and the need to re-enable your CMK within 30 days of disabling it to ensure successful restoration of your Kubernetes control plane resources.
### How can I protect my EKS cluster from the impact of a disabled/deleted CMK?
To protect your EKS clusters from such an occurrence, your key administrators should manage access to KMS key operations using IAM policies with a least privilege principle to reduce the risk of any arbitrary disablement or deletion of keys associated with EKS clusters. Additionally, you can set a [CloudWatch alarm](https://docs.aws.amazon.com/kms/latest/developerguide/deleting-keys-creating-cloudwatch-alarm.html) to be notified about the state of your CMK.
### Will my EKS cluster be restored if I re-enable the CMK?
To ensure successful restoration of your EKS cluster, we strongly recommend re-enabling your CMK within the first 30 days of it being disabled. However, the successful restoration of your EKS cluster will also depend on whether or not it undergoes any API breaking changes due to an automatic Kubernetes upgrade that may take place while the cluster is in an unhealthy/degraded state.
### Why is my EKS cluster placed in an unhealthy/degraded state after disabling the CMK?
The EKS control plane’s API server uses a DEK key which is encrypted and cached in the API server’s memory to encrypt all the objects during create/update operations before they’re stored in etcd. When an existing object is being retrieved from etcd, the API server uses the same cached DEK key and decrypts the Kubernetes resource object. If you disable the CMK, the API server will not see any immediate impact because of the cached DEK key in the API server’s memory. However, when the API server instance is restarted, it won’t have a cached DEK and will need to call AWS KMS for encrypt and decrypt operations. Without a CMK, this process will fail with a KMS\$1KEY\$1DISABLED error code, preventing the API server from booting successfully.
### What happens to my EKS cluster if I delete my CMK?
Deleting the CMK key associated with your EKS cluster will degrade its health beyond recovery. Without your cluster’s CMK, the API server will no longer be able to encrypt and persist any new Kubernetes objects, as well as decrypt any previously encrypted Kubernetes objects stored in the etcd database. You should only proceed with deleting a CMK key for your EKS cluster when you are sure that you don’t need to use the EKS cluster anymore.
Please note that if the CMK is not found (KMS\$1KEY\$1NOT\$1FOUND) or the grants for the CMK associated with your cluster are revoked (KMS\$1GRANT\$1REVOKED), your cluster will not be recoverable. For more information about about cluster health and error codes, see [Cluster health FAQs and error codes with resolution paths](https://docs.aws.amazon.com/eks/latest/userguide/troubleshooting.html#cluster-health-status).
### Will I still be charged for a degraded/unhealthy EKS cluster because I disabled or deleted my CMK?
Yes. Although the EKS control plane will not be usable in the event of a disabled CMK, AWS will still be running dedicated infrastructure resources allocated to the EKS cluster until it is deleted by the customer. Additionally, our [Service Commitment](https://aws.amazon.com/eks/sla/) will not apply in such a circumstance because it will be a voluntary action or inaction by the customer that prevents the normal health and operation of your EKS cluster.
### Can my EKS cluster be automatically upgraded when it’s in an unhealthy/degraded state because of a disabled CMK?
Yes. However, if your cluster has a disabled CMK, you will have a 30 day period to re-enable it. In this 30 day period, your Kubernetes cluster will not be automatically upgraded. However, if this period lapses and you have not re-enabled the CMK, the cluster will be automatically upgraded to the next version (n\$11) that is in standard support, following the Kubernetes version lifecycle in EKS.
We strongly recommend quickly re-enabling a disabled CMK when you become aware of an impacted cluster. It’s important to note, that although EKS will automatically upgrade these impacted clusters, there’s no guarantee that they will recover successfully, especially if the cluster undergoes multiple automatic upgrades since this may include changes to the Kubernetes API and unexpected behavior in the API server’s bootstrap process.
### Can I use a KMS key alias?
Yes. Amazon EKS [supports using KMS key aliases](https://docs.aws.amazon.com/eks/latest/APIReference/API_EncryptionConfig.html#API_EncryptionConfig_Contents). An alias is a friendly name for a [Amazon Web Service KMS key](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#kms_keys). For example, an alias lets you refer to a KMS key as **my-key** instead of ** `1234abcd-12ab-34cd-56ef-1234567890ab` **.
### Can I still backup and restore my cluster resources using my own Kubernetes backup solution?
Yes. You can use a Kubernetes backup solution (like [Velero](https://velero.io/)) for Kubernetes cluster disaster recovery, data migration, and data protection. If you run a Kubernetes backup solution that accesses the cluster resources through the API server, any data that the application retrieves will be decrypted before reaching the client. This will allow you to recover the cluster resources in another Kubernetes cluster.
# Harden Kubernetes RBAC in Amazon EKS
Kubernetes role-based access control (RBAC) controls what actions identities can perform inside a cluster. Many cluster components, including CSI drivers and other add-ons installed as DaemonSets, require broad permissions to function. Reviewing and scoping these permissions reduces the potential scope of any unintended access.
This topic describes the permission considerations for common cluster components and the recommended controls.
## DaemonSet service account permissions
DaemonSet Pods run on every node in the cluster, so their service account tokens and the RBAC permissions those tokens grant are present on every node.
An unauthorized process on a node may be able to access the service account tokens of other Pods running on the same node, including DaemonSet Pods. The RBAC permissions granted to DaemonSet service accounts are the same on every node in the cluster.
Components commonly deployed as DaemonSets include:
+ CSI node drivers (`ebs-csi-node`, `efs-csi-node`, `mountpoint-s3-csi-node`)
+ The Amazon VPC CNI plugin (`aws-node`)
+ `kube-proxy`
If a DaemonSet Pod has AWS IAM credentials through EKS Pod Identity or IAM Roles for Service Accounts (IRSA), a process that gains access outside its container on the same node may also access those credentials. This extends the scope of impact beyond Kubernetes RBAC to any AWS API permissions granted to a DaemonSet’s IAM role.
**Important**
When reviewing permissions, treat the Kubernetes RBAC permissions and the IAM permissions of every DaemonSet service account as accessible from every node in the cluster.
## CSI driver RBAC scope
CSI drivers commonly hold broad RBAC grants because they interact with nodes, persistent volumes, and storage APIs.
### Node object permissions
CSI drivers may require RBAC permissions to modify Node objects to support features such as taint removal or other node management tasks. Due to Kubernetes RBAC limitations, these permissions apply to *all* Node objects in the cluster, not only the local node the driver is running on.
For the EBS CSI driver, the Helm chart provides a parameter (`node.serviceAccount.disableMutation`) that removes the node modification permission from the `ebs-csi-node` service account. Enabling this disables the taint removal feature.
### Service account token exposure
CSI driver Pods may use projected service account tokens for authentication. On a node where an unauthorized process has gained access outside its container, those tokens may be accessible through the container filesystem or the kubelet API. If the service account is also associated with an IAM role through EKS Pod Identity or IRSA, an exposed token can be used to obtain AWS IAM credentials.
## Recommended controls
### Scope RBAC to least privilege
+ Review the ClusterRoles bound to CSI driver and DaemonSet service accounts. Remove permissions that are not required for your workloads.
+ For the EBS CSI driver, set `node.serviceAccount.disableMutation` to `true` if you don’t use the taint removal feature.
+ Use `kubectl auth can-i --list --as=system:serviceaccount:NAMESPACE:SERVICE_ACCOUNT` to audit effective permissions.
### Enforce Pod security standards
Apply the [Kubernetes Pod Security Standards](https://kubernetes.io/docs/concepts/security/pod-security-standards/) using the built-in Pod Security Admission controller or a policy engine. At minimum, enforce the `baseline` profile cluster-wide and the `restricted` profile for workload namespaces. This limits the ability to create privileged containers outside of system namespaces.
### Use network policies
Apply network policies to restrict egress from CSI driver and DaemonSet Pods to only the endpoints they need (for example, the Kubernetes API server and AWS service endpoints). This reduces the scope of actions possible.
### Monitor RBAC activity
Enable Kubernetes audit logging and monitor for unexpected API calls from DaemonSet service accounts. Look for:
+ Node modifications from CSI driver service accounts
+ Pod creation in system namespaces
+ Unusual `get` or `list` calls on Secrets
For more information, see [Send control plane logs to CloudWatch Logs](control-plane-logs.md).
# Security considerations for Amazon EKS Auto Mode
This topic describes the security architecture, controls, and best practices for Amazon EKS Auto Mode. As organizations deploy containerized applications at scale, maintaining a strong security posture becomes increasingly complex. EKS Auto Mode implements automated security controls and integrates with AWS security services to help you protect your cluster infrastructure, workloads, and data. Through built-in security features like enforced node lifecycle management and automated patch deployment, EKS Auto Mode helps you maintain security best practices while reducing operational overhead.
Before proceeding with this topic, make sure that you’re familiar with basic EKS Auto Mode concepts and have reviewed the prerequisites for enabling EKS Auto Mode on your clusters. For general information about Amazon EKS security, see [Security in Amazon EKS](security.md).
Amazon EKS Auto Mode builds upon the existing security foundations of Amazon EKS while introducing additional automated security controls for EC2 managed instances.
## API security and authentication
Amazon EKS Auto Mode uses AWS platform security mechanisms to secure and authenticate calls to the Amazon EKS API.
+ Access to the Kubernetes API is secured through EKS access entries, which integrate with AWS IAM identities.
+ For more information, see [Grant IAM users access to Kubernetes with EKS access entries](access-entries.md).
+ Customers can implement fine-grained access control to the Kubernetes API endpoint through configuration of EKS access entries.
## Network security
Amazon EKS Auto Mode supports multiple layers of network security:
+ **VPC integration**
+ Operates within your Amazon Virtual Private Cloud (VPC)
+ Supports custom VPC configurations and subnet layouts
+ Enables private networking between cluster components
+ For more information, see [Managing security responsibilities for Amazon Virtual Private Cloud](https://docs.aws.amazon.com/vpc/latest/userguide/security.html)
+ **Network Policies**
+ Native support for Kubernetes Network Policies
+ Ability to define granular network traffic rules
+ For more information, see [Limit Pod traffic with Kubernetes network policies](cni-network-policy.md)
## EC2 managed instance security
Amazon EKS Auto Mode operates EC2 managed instances with the following security controls:
### EC2 security
+ EC2 managed instances maintain the security features of Amazon EC2.
+ For more information about EC2 managed instances, see [Security in Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-security.html).
### Instance lifecycle management
EC2 managed instances operated by EKS Auto Mode have maximum lifetime of 21 days. Amazon EKS Auto Mode automatically terminates instances exceeding this lifetime. This lifecycle limit helps prevent configuration drift and maintains security posture.
### Data protection
+ Amazon EC2 Instance Storage is encrypted, this is storage directly attached to the instance. For more information, see [Data protection in Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/data-protection.html).
+ EKS Auto Mode manages the volumes attached to EC2 instances at creation time, including root and data volumes. EKS Auto Mode does not fully manage EBS volumes created using Kubernetes persistent storage features.
### Patch management
+ Amazon EKS Auto Mode automatically applies patches to managed instances.
+ Patches include:
+ Operating system updates
+ Security patches
+ Amazon EKS Auto Mode components
**Note**
Customers retain responsibility for securing and updating workloads running on these instances.
### Access controls
+ Direct instance access is restricted:
+ SSH access is not available.
+ AWS Systems Manager Session Manager (SSM) access is not available.
+ Management operations are performed through the Amazon EKS API and Kubernetes API.
## Automated resource management
Amazon EKS Auto Mode does not fully manage Amazon Elastic Block Store (Amazon EBS) Volumes created using Kubernetes persistent storage features. EKS Auto Mode also does not manage Elastic Load Balancers (ELB). Amazon EKS Auto Mode automates routine tasks for these resources.
### Storage security
+ AWS recommends that you enable encryption for EBS Volumes provisioned by Kubernetes persistent storage features. For more information, see [Create a storage class](create-storage-class.md).
+ Encryption at rest using AWS KMS
+ You can configure your AWS account to enforce the encryption of the new EBS volumes and snapshot copies that you create. For more information, see [Enable Amazon EBS encryption by default](https://docs.aws.amazon.com/ebs/latest/userguide/encryption-by-default.html) in the Amazon EBS User Guide.
+ For more information, see [Security in Amazon EBS](https://docs.aws.amazon.com/ebs/latest/userguide/security.html).
### Load balancer security
+ Automated configuration of Elastic Load Balancers
+ SSL/TLS certificate management through AWS Certificate Manager integration
+ Security group automation for load balancer access control
+ For more information, see [Security in Elastic Load Balancing](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/security.html).
## Security best practices
The following section describes security best practices for Amazon EKS Auto Mode.
+ Regularly review AWS IAM policies and EKS access entries.
+ Implement least privilege access patterns for workloads.
+ Monitor cluster activity through AWS CloudTrail and Amazon CloudWatch. For more information, see [Log API calls as AWS CloudTrail events](logging-using-cloudtrail.md) and [Monitor cluster data with Amazon CloudWatch](cloudwatch.md).
+ Use AWS Security Hub for security posture assessment.
+ Implement pod security standards appropriate for your workloads.
# Security considerations for EKS Capabilities
This topic covers important security considerations for EKS Capabilities, including IAM role configuration, Kubernetes permissions, and architectural patterns for multi-cluster deployments and cross-account AWS resource management.
EKS Capabilities use a combination of IAM roles, EKS access entries, and Kubernetes RBAC to provide secure access to AWS services, in-cluster Kubernetes resources, and integrations with AWS CodeConnections, AWS Secrets Manager, and other AWS services.
## Capability IAM role
When you create a capability, you provide an IAM capability role that EKS uses to perform actions on your behalf. This role must:
+ Be in the same AWS account as the cluster and capability resource
+ Have a trust policy allowing the `capabilities.eks.amazonaws.com` service principal to assume the role
+ Have IAM permissions appropriate for the capability type and use case, depending on your requirements. For detailed information about required IAM permissions, see [Connect to Git repositories with AWS CodeConnections](integration-codeconnections.md), [Manage application secrets with AWS Secrets Manager](integration-secrets-manager.md), and [Configure ACK permissions](ack-permissions.md)
It is a best practice to consider the scope of privileges required for your specific use case and grant only those permissions necessary to meet your requirements. For example, when using the EKS Capability for Kube Resource Orchestrator, no IAM permissions may be required, while when using the EKS Capability for AWS Controllers for Kubernetes you may grant full access to one or more AWS services.
**Important**
While some use cases may warrant the use of broad administrative privileges, follow the principle of least privilege by granting only the minimum IAM permissions required for your specific use case, restricting access to specific resources using ARNs and condition keys rather than using wildcard permissions.
For detailed information about creating and configuring capability IAM roles, see [Amazon EKS capability IAM role](capability-role.md).
## EKS access entries
When you create a capability with an IAM role, Amazon EKS automatically creates an access entry for that role on your cluster. This access entry grants the capability baseline Kubernetes permissions to function.
**Note**
Access entries are created for the cluster where the capability is created. For Argo CD deployments to remote clusters, you must create access entries on those clusters with appropriate permissions for the Argo CD capability to deploy and manage applications.
The access entry includes:
+ The IAM role ARN as the principal
+ Capability-specific access entry policies that grant baseline Kubernetes permissions
+ Appropriate scope (cluster-wide or namespace-scoped) based on the capability type
**Note**
For Argo CD, namespace-scoped permissions are granted to the namespace specified in the capability configuration (defaults to `argocd`).
**Default access entry policies by capability**
Each capability type grants the capability role the required permissions, setting different default access entry policies as follows:
**kro**
+ `arn:aws:eks::aws:cluster-access-policy/AmazonEKSKROPolicy` (cluster-scoped)
Grants permissions to watch and manage ResourceGraphDefinitions and create instances of custom resources defined by RGDs.
**ACK**
+ `arn:aws:eks::aws:cluster-access-policy/AmazonEKSACKPolicy` (cluster-scoped)
Grants permissions to create, read, update, and delete ACK custom resources across all namespaces.
**Argo CD**
+ `arn:aws:eks::aws:cluster-access-policy/AmazonEKSArgoCDClusterPolicy` (cluster-scoped)
Grants cluster-level permissions for Argo CD to discover resources and manage cluster-scoped objects.
+ `arn:aws:eks::aws:cluster-access-policy/AmazonEKSArgoCDPolicy` (namespace-scoped)
Grants namespace-level permissions for Argo CD to deploy and manage applications. Scoped to the namespace specified in the capability configuration (defaults to `argocd`).
See [Review access policy permissions](access-policy-permissions.md) for more detailed information.
## Additional Kubernetes permissions
Some capabilities may require additional Kubernetes permissions beyond the default access entry policies. You can grant these permissions using either:
+ **Access entry policies**: Associate additional managed policies to the access entry
+ **Kubernetes RBAC**: Create `Role` or `ClusterRole` bindings for the capability’s Kubernetes user
**ACK secret reader permissions**
Some ACK controllers need to read Kubernetes secrets to retrieve sensitive data like database passwords. The following ACK controllers require secret read access:
+ `acm`, `acmpca`, `documentdb`, `memorydb`, `mq`, `rds`, `secretsmanager`
To grant secret read permissions:
1. Associate the `arn:aws:eks::aws:cluster-access-policy/AmazonEKSSecretReaderPolicy` access entry policy to the capability’s access entry
1. Scope the policy to specific namespaces where ACK resources will reference secrets, or grant cluster-wide access
**Important**
Secret read permissions are scoped to the namespaces you specify when associating the access entry policy. This allows you to limit which secrets the capability can access.
**kro arbitrary resource permissions**
kro requires permissions to create and manage the resources defined in your ResourceGraphDefinitions. By default, kro can only watch and manage RGDs themselves.
To grant kro permissions to create resources:
**Option 1: Access entry policies**
Associate pre-defined access entry policies like `AmazonEKSAdminPolicy` or `AmazonEKSEditPolicy` to the capability’s access entry.
**Option 2: Kubernetes RBAC**
Create a `ClusterRoleBinding` that grants the capability’s Kubernetes user the necessary permissions:
```
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: kro-cluster-admin
subjects:
- kind: User
name: arn:aws:sts::111122223333:assumed-role/my-kro-role/KRO
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: cluster-admin
apiGroup: rbac.authorization.k8s.io
```
**Note**
The Kubernetes user name for kro follows the pattern: `arn:aws:sts::ACCOUNT_ID:assumed-role/ROLE_NAME/KRO`
The session name `/KRO` (uppercase) is automatically set by the EKS kro capability.
## IAM permissions required by capability
**kro (Kube Resource Orchestrator)**
No IAM permissions required. You can create a capability role with no attached policies. kro only requires Kubernetes RBAC permissions.
**ACK (AWS Controllers for Kubernetes)**
Requires permissions to manage the AWS resources that ACK will create and manage. You should scope permissions to specific services, actions, and resources based on your requirements. For detailed information about configuring ACK permissions, including production best practices with IAM Role Selectors, see [Configure ACK permissions](ack-permissions.md).
**Argo CD**
No IAM permissions are required by default. Optional permissions may be needed for:
+ AWS Secrets Manager: If storing Git repository credentials in Secrets Manager
+ AWS CodeConnections: If using CodeConnections for Git repository authentication
+ Amazon ECR: If using Helm charts stored in OCI format in Amazon ECR
## Security best practices
### IAM least privilege
Grant your capability resources only the permissions required for your use case. This does not mean you cannot grant broad administrative permissions to your capabilities if required. In such cases, you should govern access to those resources appropriately.
**Capability roles**:
+ **ACK**: When possible, limit IAM permissions to specific AWS services and resources your teams need, based on use case and requirements
+ **Argo CD**: Restrict access to specific Git repositories and Kubernetes namespaces
+ **kro**: Requires a capability role for the trust policy, but no IAM permissions are needed (uses cluster RBAC only)
**Example**: Instead of `"Resource": "*"`, specify patterns for specific resources or groups of resources.
```
"Resource": [
"arn:aws:s3:::my-app-*",
"arn:aws:rds:us-west-2:111122223333:db:prod-*"
]
```
Use IAM condition keys to further restrict access:
```
"Condition": {
"StringEquals": {
"aws:ResourceTag/Environment": "production"
}
}
```
For additional IAM configuration information, see the considerations section for each capability.
### Namespace isolation for Argo CD secrets
The managed Argo CD capability has access to all Kubernetes secrets within its configured namespace (default: `argocd`). To maintain optimal security posture, follow these namespace isolation practices:
+ Keep only Argo CD-relevant secrets within the Argo CD namespace
+ Avoid storing unrelated application secrets in the same namespace as Argo CD
+ Use separate namespaces for application secrets that are not required for Argo CD operations
This isolation ensures that Argo CD’s secret access is limited to only the credentials it needs for Git repository authentication and other Argo CD-specific operations.
### Kubernetes RBAC
Control which users and service accounts can create and manage capability resources. It is a best practice to deploy capability resources in dedicated namespaces with appropriate RBAC policies.
Example: RBAC Role to work with ACK, allowing for S3 Bucket resource management in the `app-team` namespace:
```
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: ack-s3-manager
namespace: app-team
rules:
- apiGroups: ["s3.services.k8s.aws"]
resources: ["buckets"]
verbs: ["get", "list", "create", "update", "delete"]
```
### Audit logging
**CloudTrail**: All EKS Capability API operations (create, update, delete) are logged to AWS CloudTrail.
Enable CloudTrail logging to track:
+ Who created or modified capabilities
+ When capability configurations changed
+ What capability roles are in use
### Network access and VPC endpoints
#### Private Argo CD API access
You can restrict access to the Argo CD API server by associating one or more VPC endpoints with the hosted Argo CD endpoint. This enables private connectivity from within your VPC without traversing the public internet. The VPC endpoint provides access to both the Argo CD web UI and the Argo CD API (including CLI access).
**Note**
VPC endpoints connected to hosted Argo CD API endpoints (using eks-capabilities.*region*.amazonaws.com) do not support VPC endpoint policies.
#### Deploying to private clusters
The Argo CD capability can deploy applications to fully private EKS clusters, providing a significant operational benefit by eliminating the need for VPC peering or complex networking configurations. However, when designing this architecture, consider that Argo CD will pull configuration from Git repositories (which may be public) and apply it to your private clusters.
Ensure you:
+ Use private Git repositories for sensitive workloads
+ Implement proper Git repository access controls and authentication
+ Review and approve changes through pull requests before merging
+ Consider using Argo CD’s sync windows to control when deployments can occur
+ Monitor Argo CD audit logs for unauthorized configuration changes
### Compliance
EKS Capabilities are fully managed and have the compliance certifications of Amazon EKS.
For current compliance information, see [AWS Services in Scope by Compliance Program](https://aws.amazon.com/compliance/services-in-scope/).
## Next steps
+ [Configure ACK permissions](ack-permissions.md) - Configure IAM permissions for ACK
+ [Configure kro permissions](kro-permissions.md) - Configure Kubernetes RBAC for kro
+ [Configure Argo CD permissions](argocd-permissions.md) - Configure Identity Center integration for Argo CD
+ [Troubleshooting EKS Capabilities](capabilities-troubleshooting.md) - Troubleshoot security and permission issues
# Identity and access management for Amazon EKS
AWS Identity and Access Management (IAM) is an AWS service that helps an administrator securely control access to AWS resources. IAM administrators control who can be *authenticated* (signed in) and *authorized* (have permissions) to use Amazon EKS resources. IAM is an AWS service that you can use with no additional charge.
## Audience
How you use AWS Identity and Access Management (IAM) differs, depending on the work that you do in Amazon EKS.
**Service user** – If you use the Amazon EKS service to do your job, then your administrator provides you with the credentials and permissions that you need. As you use more Amazon EKS features to do your work, you might need additional permissions. Understanding how access is managed can help you request the right permissions from your administrator. If you cannot access a feature in Amazon EKS, see [Troubleshooting IAM](security-iam-troubleshoot.md).
**Service administrator** – If you’re in charge of Amazon EKS resources at your company, you probably have full access to Amazon EKS. It’s your job to determine which Amazon EKS features and resources your service users should access. You must then submit requests to your IAM administrator to change the permissions of your service users. Review the information on this page to understand the basic concepts of IAM. To learn more about how your company can use IAM with Amazon EKS, see [How Amazon EKS works with IAM](security-iam-service-with-iam.md).
**IAM administrator** – If you’re an IAM administrator, you might want to learn details about how you can write policies to manage access to Amazon EKS. To view example Amazon EKS identity-based policies that you can use in IAM, see [Amazon EKS identity-based policy examples](security-iam-id-based-policy-examples.md).
## Authenticating with identities
Authentication is how you sign in to AWS using your identity credentials. You must be *authenticated* (signed in to AWS) as the AWS account root user, as an IAM user, or by assuming an IAM role.
You can sign in to AWS as a federated identity by using credentials provided through an identity source. AWS IAM Identity Center (IAM Identity Center) users, your company’s single sign-on authentication, and your Google or Facebook credentials are examples of federated identities. When you sign in as a federated identity, your administrator previously set up identity federation using IAM roles. When you access AWS by using federation, you are indirectly assuming a role.
Depending on the type of user you are, you can sign in to the AWS Management Console or the AWS access portal. For more information about signing in to AWS, see [How to sign in to your AWS account](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) in the * AWS Sign-In User Guide*.
If you access AWS programmatically, AWS provides a software development kit (SDK) and a command line interface (CLI) to cryptographically sign your requests by using your credentials. If you don’t use AWS tools, you must sign requests yourself. For more information about using the recommended method to sign requests yourself, see [Signing AWS API requests](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-signing.html) in the *IAM User Guide*.
Regardless of the authentication method that you use, you might be required to provide additional security information. For example, AWS recommends that you use multi-factor authentication (MFA) to increase the security of your account. To learn more, see [Multi-factor authentication](https://docs.aws.amazon.com/singlesignon/latest/userguide/enable-mfa.html) in the * AWS IAM Identity Center User Guide* and [Using multi-factor authentication (MFA) in AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa.html) in the *IAM User Guide*.
### AWS account root user
When you create an AWS account, you begin with one sign-in identity that has complete access to all AWS services and resources in the account. This identity is called the AWS account *root user* and is accessed by signing in with the email address and password that you used to create the account. We strongly recommend that you don’t use the root user for your everyday tasks. Safeguard your root user credentials and use them to perform the tasks that only the root user can perform. For the complete list of tasks that require you to sign in as the root user, see [Tasks that require root user credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks) in the *IAM User Guide*.
### IAM users and groups
An [https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html) is an identity within your AWS account that has specific permissions for a single person or application. Where possible, we recommend relying on temporary credentials instead of creating IAM users who have long-term credentials such as passwords and access keys. However, if you have specific use cases that require long-term credentials with IAM users, we recommend that you rotate access keys. For more information, see [Rotate access keys regularly for use cases that require long-term credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#rotate-credentials) in the *IAM User Guide*.
An [IAM group](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) is an identity that specifies a collection of IAM users. You can’t sign in as a group. You can use groups to specify permissions for multiple users at a time. Groups make permissions easier to manage for large sets of users. For example, you could have a group named *IAMAdmins* and give that group permissions to administer IAM resources.
Users are different from roles. A user is uniquely associated with one person or application, but a role is intended to be assumable by anyone who needs it. Users have permanent long-term credentials, but roles provide temporary credentials. To learn more, see [When to create an IAM user (instead of a role)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html#id_which-to-choose) in the *IAM User Guide*.
### IAM roles
An [https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) is an identity within your AWS account that has specific permissions. It is similar to an IAM user, but is not associated with a specific person. You can temporarily assume an IAM role in the AWS Management Console by [switching roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html). You can assume a role by calling an AWS CLI or AWS API operation or by using a custom URL. For more information about methods for using roles, see [Using IAM roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use.html) in the *IAM User Guide*.
IAM roles with temporary credentials are useful in the following situations:
+ **Federated user access** – To assign permissions to a federated identity, you create a role and define permissions for the role. When a federated identity authenticates, the identity is associated with the role and is granted the permissions that are defined by the role. For information about roles for federation, see [Creating a role for a third-party Identity Provider](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-idp.html) in the *IAM User Guide*. If you use IAM Identity Center, you configure a permission set. To control what your identities can access after they authenticate, IAM Identity Center correlates the permission set to a role in IAM. For information about permissions sets, see [Permission sets](https://docs.aws.amazon.com/singlesignon/latest/userguide/permissionsetsconcept.html) in the * AWS IAM Identity Center User Guide*.
+ **Temporary IAM user permissions** – An IAM user or role can assume an IAM role to temporarily take on different permissions for a specific task.
+ **Cross-account access** – You can use an IAM role to allow someone (a trusted principal) in a different account to access resources in your account. Roles are the primary way to grant cross-account access. However, with some AWS services, you can attach a policy directly to a resource (instead of using a role as a proxy). To learn the difference between roles and resource-based policies for cross-account access, see [Cross account resource access in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) in the *IAM User Guide*.
+ **Cross-service access** – Some AWS services use features in other AWS services. For example, when you make a call in a service, it’s common for that service to run applications in Amazon EC2 or store objects in Amazon S3. A service might do this using the calling principal’s permissions, using a service role, or using a service-linked role.
+ **Forward access sessions (FAS)** – When you use an IAM user or role to perform actions in AWS, you are considered a principal. When you use some services, you might perform an action that then initiates another action in a different service. FAS uses the permissions of the principal calling an AWS service, combined with the requesting AWS service to make requests to downstream services. FAS requests are only made when a service receives a request that requires interactions with other AWS services or resources to complete. In this case, you must have permissions to perform both actions. For policy details when making FAS requests, see [Forward access sessions](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_forward_access_sessions.html).
+ **Service role** – A service role is an [IAM role](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) that a service assumes to perform actions on your behalf. An IAM administrator can create, modify, and delete a service role from within IAM. For more information, see [Creating a role to delegate permissions to an AWS service](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html) in the *IAM User Guide*.
+ **Service-linked role** – A service-linked role is a type of service role that is linked to an AWS service. The service can assume the role to perform an action on your behalf. Service-linked roles appear in your AWS account and are owned by the service. An IAM administrator can view, but not edit the permissions for service-linked roles.
+ **Applications running on Amazon EC2** – You can use an IAM role to manage temporary credentials for applications that are running on an EC2 instance and making AWS CLI or AWS API requests. This is preferable to storing access keys within the EC2 instance. To assign an AWS role to an EC2 instance and make it available to all of its applications, you create an instance profile that is attached to the instance. An instance profile contains the role and enables programs that are running on the EC2 instance to get temporary credentials. For more information, see [Using an IAM role to grant permissions to applications running on Amazon EC2 instances](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2.html) in the *IAM User Guide*.
To learn whether to use IAM roles or IAM users, see [When to create an IAM role (instead of a user)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html#id_which-to-choose_role) in the *IAM User Guide*.
## Managing access using policies
You control access in AWS by creating policies and attaching them to AWS identities or resources. A policy is an object in AWS that, when associated with an identity or resource, defines their permissions. AWS evaluates these policies when a principal (user, root user, or role session) makes a request. Permissions in the policies determine whether the request is allowed or denied. Most policies are stored in AWS as JSON documents. For more information about the structure and contents of JSON policy documents, see [Overview of JSON policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#access_policies-json) in the *IAM User Guide*.
Administrators can use AWS JSON policies to specify who has access to what. That is, which **principal** can perform **actions** on what **resources**, and under what **conditions**.
By default, users and roles have no permissions. To grant users permission to perform actions on the resources that they need, an IAM administrator can create IAM policies. The administrator can then add the IAM policies to roles, and users can assume the roles.
IAM policies define permissions for an action regardless of the method that you use to perform the operation. For example, suppose that you have a policy that allows the `iam:GetRole` action. A user with that policy can get role information from the AWS Management Console, the AWS CLI, or the AWS API.
### Identity-based policies
Identity-based policies are JSON permissions policy documents that you can attach to an identity, such as an IAM user, group of users, or role. These policies control what actions users and roles can perform, on which resources, and under what conditions. To learn how to create an identity-based policy, see [Creating IAM policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) in the *IAM User Guide*.
Identity-based policies can be further categorized as *inline policies* or *managed policies*. Inline policies are embedded directly into a single user, group, or role. Managed policies are standalone policies that you can attach to multiple users, groups, and roles in your AWS account. Managed policies include AWS managed policies and customer managed policies. To learn how to choose between a managed policy or an inline policy, see [Choosing between managed policies and inline policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#choosing-managed-or-inline) in the *IAM User Guide*.
### Resource-based policies
Resource-based policies are JSON policy documents that you attach to a resource. Examples of resource-based policies are IAM *role trust policies* and Amazon S3 *bucket policies*. In services that support resource-based policies, service administrators can use them to control access to a specific resource. For the resource where the policy is attached, the policy defines what actions a specified principal can perform on that resource and under what conditions. You must [specify a principal](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html) in a resource-based policy. Principals can include accounts, users, roles, federated users, or AWS services.
Resource-based policies are inline policies that are located in that service. You can’t use AWS managed policies from IAM in a resource-based policy.
### Access control lists (ACLs)
Access control lists (ACLs) control which principals (account members, users, or roles) have permissions to access a resource. ACLs are similar to resource-based policies, although they do not use the JSON policy document format.
Amazon S3, AWS WAF, and Amazon VPC are examples of services that support ACLs. To learn more about ACLs, see [Access control list (ACL) overview](https://docs.aws.amazon.com/AmazonS3/latest/userguide/acl-overview.html) in the *Amazon Simple Storage Service Developer Guide*.
### Other policy types
AWS supports additional, less-common policy types. These policy types can set the maximum permissions granted to you by the more common policy types.
+ **Permissions boundaries** – A permissions boundary is an advanced feature in which you set the maximum permissions that an identity-based policy can grant to an IAM entity (IAM user or role). You can set a permissions boundary for an entity. The resulting permissions are the intersection of an entity’s identity-based policies and its permissions boundaries. Resource-based policies that specify the user or role in the `Principal` field are not limited by the permissions boundary. An explicit deny in any of these policies overrides the allow. For more information about permissions boundaries, see [Permissions boundaries for IAM entities](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html) in the *IAM User Guide*.
+ **Service control policies (SCPs)** – SCPs are JSON policies that specify the maximum permissions for an organization or organizational unit (OU) in AWS Organizations. AWS Organizations is a service for grouping and centrally managing multiple AWS accounts that your business owns. If you enable all features in an organization, then you can apply service control policies (SCPs) to any or all of your accounts. The SCP limits permissions for entities in member accounts, including each AWS account root user. For more information about Organizations and SCPs, see [Service control policies](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) in the * AWS Organizations User Guide*.
+ **Session policies** – Session policies are advanced policies that you pass as a parameter when you programmatically create a temporary session for a role or federated user. The resulting session’s permissions are the intersection of the user or role’s identity-based policies and the session policies. Permissions can also come from a resource-based policy. An explicit deny in any of these policies overrides the allow. For more information, see [Session policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session) in the *IAM User Guide*.
### Multiple policy types
When multiple types of policies apply to a request, the resulting permissions are more complicated to understand. To learn how AWS determines whether to allow a request when multiple policy types are involved, see [Policy evaluation logic](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html) in the *IAM User Guide*.
# How Amazon EKS works with IAM
Before you use IAM to manage access to Amazon EKS, you should understand what IAM features are available to use with Amazon EKS. To get a high-level view of how Amazon EKS and other AWS services work with IAM, see [AWS services that work with IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) in the *IAM User Guide*.
**Topics**
+ [
## Amazon EKS identity-based policies
](#security-iam-service-with-iam-id-based-policies)
+ [
## Amazon EKS resource-based policies
](#security-iam-service-with-iam-resource-based-policies)
+ [
## Authorization based on Amazon EKS tags
](#security-iam-service-with-iam-tags)
+ [
## Amazon EKS IAM roles
](#security-iam-service-with-iam-roles)
## Amazon EKS identity-based policies
With IAM identity-based policies, you can specify allowed or denied actions and resources as well as the conditions under which actions are allowed or denied. Amazon EKS supports specific actions, resources, and condition keys. To learn about all of the elements that you use in a JSON policy, see [IAM JSON policy elements reference](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html) in the *IAM User Guide*.
### Actions
Administrators can use AWS JSON policies to specify who has access to what. That is, which **principal** can perform **actions** on what **resources**, and under what **conditions**.
The `Action` element of a JSON policy describes the actions that you can use to allow or deny access in a policy. Policy actions usually have the same name as the associated AWS API operation. There are some exceptions, such as *permission-only actions* that don’t have a matching API operation. There are also some operations that require multiple actions in a policy. These additional actions are called *dependent actions*.
Include actions in a policy to grant permissions to perform the associated operation.
Policy actions in Amazon EKS use the following prefix before the action: `eks:`. For example, to grant someone permission to get descriptive information about an Amazon EKS cluster, you include the `DescribeCluster` action in their policy. Policy statements must include either an `Action` or `NotAction` element.
To specify multiple actions in a single statement, separate them with commas as follows:
```
"Action": ["eks:action1", "eks:action2"]
```
You can specify multiple actions using wildcards (\$1). For example, to specify all actions that begin with the word `Describe`, include the following action:
```
"Action": "eks:Describe*"
```
To see a list of Amazon EKS actions, see [Actions defined by Amazon Elastic Kubernetes Service](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-actions-as-permissions) in the *Service Authorization Reference*.
### Resources
Administrators can use AWS JSON policies to specify who has access to what. That is, which **principal** can perform **actions** on what **resources**, and under what **conditions**.
The `Resource` JSON policy element specifies the object or objects to which the action applies. Statements must include either a `Resource` or a `NotResource` element. As a best practice, specify a resource using its [Amazon Resource Name (ARN)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html). You can do this for actions that support a specific resource type, known as *resource-level permissions*.
For actions that don’t support resource-level permissions, such as listing operations, use a wildcard (\$1) to indicate that the statement applies to all resources.
```
"Resource": "*"
```
The Amazon EKS cluster resource has the following ARN.
```
arn:aws:eks:region-code:account-id:cluster/cluster-name
```
For more information about the format of ARNs, see [Amazon resource names (ARNs) and AWS service namespaces](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html).
For example, to specify the cluster with the name *my-cluster* in your statement, use the following ARN:
```
"Resource": "arn:aws:eks:region-code:111122223333:cluster/my-cluster"
```
To specify all clusters that belong to a specific account and AWS Region, use the wildcard (\$1):
```
"Resource": "arn:aws:eks:region-code:111122223333:cluster/*"
```
Some Amazon EKS actions, such as those for creating resources, can’t be performed on a specific resource. In those cases, you must use the wildcard (\$1).
```
"Resource": "*"
```
To see a list of Amazon EKS resource types and their ARNs, see [Resources defined by Amazon Elastic Kubernetes Service](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-resources-for-iam-policies) in the *Service Authorization Reference*. To learn with which actions you can specify the ARN of each resource, see [Actions defined by Amazon Elastic Kubernetes Service](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-actions-as-permissions).
### Condition keys
Amazon EKS defines its own set of condition keys and also supports using some global condition keys. To see all AWS global condition keys, see [AWS Global Condition Context Keys](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) in the *IAM User Guide*.
You can set condition keys when associating an OpenID Connect provider to your cluster. For more information, see [Example IAM policy](authenticate-oidc-identity-provider.md#oidc-identity-provider-iam-policy).
All Amazon EC2 actions support the `aws:RequestedRegion` and `ec2:Region` condition keys. For more information, see [Example: Restricting Access to a Specific AWS Region](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ExamplePolicies_EC2.html#iam-example-region).
For a list of Amazon EKS condition keys, see [Conditions defined by Amazon Elastic Kubernetes Service](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-policy-keys) in the *Service Authorization Reference*. To learn which actions and resources you can use a condition key with, see [Actions defined by Amazon Elastic Kubernetes Service](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-actions-as-permissions).
### Examples
To view examples of Amazon EKS identity-based policies, see [Amazon EKS identity-based policy examples](security-iam-id-based-policy-examples.md).
When you create an Amazon EKS cluster, the [IAM principal](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) that creates the cluster is automatically granted `system:masters` permissions in the cluster’s role-based access control (RBAC) configuration in the Amazon EKS control plane. This principal doesn’t appear in any visible configuration, so make sure to keep track of which principal originally created the cluster. To grant additional IAM principals the ability to interact with your cluster, edit the `aws-auth ConfigMap` within Kubernetes and create a Kubernetes `rolebinding` or `clusterrolebinding` with the name of a `group` that you specify in the `aws-auth ConfigMap`.
For more information about working with the ConfigMap, see [Grant IAM users and roles access to Kubernetes APIs](grant-k8s-access.md).
## Amazon EKS resource-based policies
Amazon EKS does not support resource-based policies.
## Authorization based on Amazon EKS tags
You can attach tags to Amazon EKS resources or pass tags in a request to Amazon EKS. To control access based on tags, you provide tag information in the [condition element](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) of a policy using the `aws:ResourceTag/key-name `, `aws:RequestTag/key-name `, or `aws:TagKeys` condition keys. For more information about tagging Amazon EKS resources, see [Organize Amazon EKS resources with tags](eks-using-tags.md). For more information about which actions that you can use tags in condition keys with, see [Actions defined by Amazon EKS](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-actions-as-permissions) in the [Service Authorization Reference](https://docs.aws.amazon.com/service-authorization/latest/reference/reference.html).
## Amazon EKS IAM roles
An [IAM role](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) is an entity within your AWS account that has specific permissions.
### Using temporary credentials with Amazon EKS
You can use temporary credentials to sign in with federation, assume an IAM role, or to assume a cross-account role. You obtain temporary security credentials by calling AWS STS API operations such as [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) or [GetFederationToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html).
Amazon EKS supports using temporary credentials.
### Service-linked roles
[Service-linked roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-service-linked-role) allow AWS services to access resources in other services to complete an action on your behalf. Service-linked roles appear in your IAM account and are owned by the service. An administrator can view but can’t edit the permissions for service-linked roles.
Amazon EKS supports service-linked roles. For details about creating or managing Amazon EKS service-linked roles, see [Using service-linked roles for Amazon EKS](using-service-linked-roles.md).
### Service roles
This feature allows a service to assume a [service role](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-service-role) on your behalf. This role allows the service to access resources in other services to complete an action on your behalf. Service roles appear in your IAM account and are owned by the account. This means that an IAM administrator can change the permissions for this role. However, doing so might break the functionality of the service.
Amazon EKS supports service roles. For more information, see [Amazon EKS cluster IAM role](cluster-iam-role.md) and [Amazon EKS node IAM role](create-node-role.md).
### Choosing an IAM role in Amazon EKS
When you create a cluster resource in Amazon EKS, you must choose a role to allow Amazon EKS to access several other AWS resources on your behalf. If you have previously created a service role, then Amazon EKS provides you with a list of roles to choose from. It’s important to choose a role that has the Amazon EKS managed policies attached to it. For more information, see [Check for an existing cluster role](cluster-iam-role.md#check-service-role) and [Check for an existing node role](create-node-role.md#check-worker-node-role).
# Amazon EKS identity-based policy examples
By default, IAM users and roles don’t have permission to create or modify Amazon EKS resources. They also can’t perform tasks using the AWS Management Console, AWS CLI, or AWS API. An IAM administrator must create IAM policies that grant users and roles permission to perform specific API operations on the specified resources they need. The administrator must then attach those policies to the IAM users or groups that require those permissions.
To learn how to create an IAM identity-based policy using these example JSON policy documents, see [Creating policies on the JSON tab](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html#access_policies_create-json-editor) in the *IAM User Guide*.
When you create an Amazon EKS cluster, the [IAM principal](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) that creates the cluster is automatically granted `system:masters` permissions in the cluster’s role-based access control (RBAC) configuration in the Amazon EKS control plane. This principal doesn’t appear in any visible configuration, so make sure to keep track of which principal originally created the cluster. To grant additional IAM principals the ability to interact with your cluster, edit the `aws-auth ConfigMap` within Kubernetes and create a Kubernetes `rolebinding` or `clusterrolebinding` with the name of a `group` that you specify in the `aws-auth ConfigMap`.
For more information about working with the ConfigMap, see [Grant IAM users and roles access to Kubernetes APIs](grant-k8s-access.md).
**Topics**
+ [
## Policy best practices
](#security-iam-service-with-iam-policy-best-practices)
+ [
## Using the Amazon EKS console
](#security-iam-id-based-policy-examples-console)
+ [
## Allow IAM users to view their own permissions
](#security-iam-id-based-policy-examples-view-own-permissions)
+ [
## Create a Kubernetes cluster on the AWS Cloud
](#policy-create-cluster)
+ [
## Create a local Kubernetes cluster on an Outpost
](#policy-create-local-cluster)
+ [
## Update a Kubernetes cluster
](#policy-example1)
+ [
## List or describe all clusters
](#policy-example2)
## Policy best practices
Identity-based policies determine whether someone can create, access, or delete Amazon EKS resources in your account. These actions can incur costs for your AWS account. When you create or edit identity-based policies, follow these guidelines and recommendations:
+ **Get started with AWS managed policies and move toward least-privilege permissions** – To get started granting permissions to your users and workloads, use the * AWS managed policies* that grant permissions for many common use cases. They are available in your AWS account. We recommend that you reduce permissions further by defining AWS customer managed policies that are specific to your use cases. For more information, see [AWS managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) or [AWS managed policies for job functions](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) in the *IAM User Guide*.
+ **Apply least-privilege permissions** – When you set permissions with IAM policies, grant only the permissions required to perform a task. You do this by defining the actions that can be taken on specific resources under specific conditions, also known as *least-privilege permissions*. For more information about using IAM to apply permissions, see [Policies and permissions in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) in the *IAM User Guide*.
+ **Use conditions in IAM policies to further restrict access** – You can add a condition to your policies to limit access to actions and resources. For example, you can write a policy condition to specify that all requests must be sent using SSL. You can also use conditions to grant access to service actions if they are used through a specific AWS service, such as AWS CloudFormation. For more information, see [IAM JSON policy elements: Condition](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) in the *IAM User Guide*.
+ **Use IAM Access Analyzer to validate your IAM policies to ensure secure and functional permissions** – IAM Access Analyzer validates new and existing policies so that the policies adhere to the IAM policy language (JSON) and IAM best practices. IAM Access Analyzer provides more than 100 policy checks and actionable recommendations to help you author secure and functional policies. For more information, see [IAM Access Analyzer policy validation](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html) in the *IAM User Guide*.
+ **Require multi-factor authentication (MFA)** – If you have a scenario that requires IAM users or a root user in your AWS account, turn on MFA for additional security. To require MFA when API operations are called, add MFA conditions to your policies. For more information, see [Configuring MFA-protected API access](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html) in the *IAM User Guide*.
For more information about best practices in IAM, see [Security best practices in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) in the *IAM User Guide*.
## Using the Amazon EKS console
To access the Amazon EKS console, an [IAM principal](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal), must have a minimum set of permissions. These permissions allow the principal to list and view details about the Amazon EKS resources in your AWS account. If you create an identity-based policy that is more restrictive than the minimum required permissions, the console won’t function as intended for principals with that policy attached to them.
To ensure that your IAM principals can still use the Amazon EKS console, create a policy with your own unique name, such as `AmazonEKSAdminPolicy`. Attach the policy to the principals. For more information, see [Adding and removing IAM identity permissions](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html) in the *IAM User Guide*.
**Important**
The following example policy allows a principal to view information on the **Configuration** tab in the console. To view information on the **Overview** and **Resources** tabs in the AWS Management Console, the principal also needs Kubernetes permissions. For more information, see [Required permissions](view-kubernetes-resources.md#view-kubernetes-resources-permissions).
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"eks:*"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "*",
"Condition": {
"StringEquals": {
"iam:PassedToService": "eks.amazonaws.com"
}
}
}
]
}
```
You don’t need to allow minimum console permissions for principals that are making calls only to the AWS CLI or the AWS API. Instead, allow access to only the actions that match the API operation that you’re trying to perform.
## Allow IAM users to view their own permissions
This example shows how you might create a policy that allows IAM users to view the inline and managed policies that are attached to their user identity. This policy includes permissions to complete this action on the console or programmatically using the AWS CLI or AWS API.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "ViewOwnUserInfo",
"Effect": "Allow",
"Action": [
"iam:GetUserPolicy",
"iam:ListGroupsForUser",
"iam:ListAttachedUserPolicies",
"iam:ListUserPolicies",
"iam:GetUser"
],
"Resource": ["arn:aws:iam::*:user/${aws:username}"]
},
{
"Sid": "NavigateInConsole",
"Effect": "Allow",
"Action": [
"iam:GetGroupPolicy",
"iam:GetPolicyVersion",
"iam:GetPolicy",
"iam:ListAttachedGroupPolicies",
"iam:ListGroupPolicies",
"iam:ListPolicyVersions",
"iam:ListPolicies",
"iam:ListUsers"
],
"Resource": "*"
}
]
}
```
## Create a Kubernetes cluster on the AWS Cloud
This example policy includes the minimum permissions required to create an Amazon EKS cluster named *my-cluster* in the *us-west-2* AWS Region. You can replace the AWS Region with the AWS Region that you want to create a cluster in. If you see a warning that says **The actions in your policy do not support resource-level permissions and require you to choose `All resources` ** in the AWS Management Console, it can be safely ignored. If your account already has the *AWSServiceRoleForAmazonEKS* role, you can remove the `iam:CreateServiceLinkedRole` action from the policy. If you’ve ever created an Amazon EKS cluster in your account then this role already exists, unless you deleted it.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "eks:CreateCluster",
"Resource": "arn:aws:eks:us-west-2:111122223333:cluster/my-cluster"
},
{
"Effect": "Allow",
"Action": "iam:CreateServiceLinkedRole",
"Resource": "arn:aws:iam::111122223333:role/aws-service-role/eks.amazonaws.com/AWSServiceRoleForAmazonEKS",
"Condition": {
"ForAnyValue:StringEquals": {
"iam:AWSServiceName": "eks"
}
}
},
{
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "arn:aws:iam::111122223333:role/cluster-role-name"
}
]
}
```
## Create a local Kubernetes cluster on an Outpost
This example policy includes the minimum permissions required to create an Amazon EKS local cluster named *my-cluster* on an Outpost in the *us-west-2* AWS Region. You can replace the AWS Region with the AWS Region that you want to create a cluster in. If you see a warning that says **The actions in your policy do not support resource-level permissions and require you to choose `All resources` ** in the AWS Management Console, it can be safely ignored. If your account already has the `AWSServiceRoleForAmazonEKSLocalOutpost` role, you can remove the `iam:CreateServiceLinkedRole` action from the policy. If you’ve ever created an Amazon EKS local cluster on an Outpost in your account then this role already exists, unless you deleted it.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "eks:CreateCluster",
"Resource": "arn:aws:eks:us-west-2:111122223333:cluster/my-cluster"
},
{
"Action": [
"ec2:DescribeSubnets",
"ec2:DescribeVpcs",
"iam:GetRole"
],
"Resource": "*",
"Effect": "Allow"
},
{
"Effect": "Allow",
"Action": "iam:CreateServiceLinkedRole",
"Resource": "arn:aws:iam::111122223333:role/aws-service-role/outposts.eks-local.amazonaws.com/AWSServiceRoleForAmazonEKSLocalOutpost"
},
{
"Effect": "Allow",
"Action": [
"iam:PassRole",
"iam:ListAttachedRolePolicies"
],
"Resource": "arn:aws:iam::111122223333:role/cluster-role-name"
},
{
"Action": [
"iam:CreateInstanceProfile",
"iam:TagInstanceProfile",
"iam:AddRoleToInstanceProfile",
"iam:GetInstanceProfile",
"iam:DeleteInstanceProfile",
"iam:RemoveRoleFromInstanceProfile"
],
"Resource": "arn:aws:iam::*:instance-profile/eks-local-*",
"Effect": "Allow"
}
]
}
```
## Update a Kubernetes cluster
This example policy includes the minimum permission required to update a cluster named *my-cluster* in the us-west-2 AWS Region.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "eks:UpdateClusterVersion",
"Resource": "arn:aws:eks:us-west-2:111122223333:cluster/my-cluster"
}
]
}
```
## List or describe all clusters
This example policy includes the minimum permissions required to list and describe all clusters in your account. An [IAM principal](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) must be able to list and describe clusters to use the `update-kubeconfig` AWS CLI command.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"eks:DescribeCluster",
"eks:ListClusters"
],
"Resource": "*"
}
]
}
```
# Using service-linked roles for Amazon EKS
Amazon Elastic Kubernetes Service uses AWS Identity and Access Management (IAM) [service-linked roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-service-linked-role). A service-linked role is a unique type of IAM role that is linked directly to Amazon EKS. Service-linked roles are predefined by Amazon EKS and include all the permissions that the service requires to call other AWS services on your behalf.
**Topics**
+ [
# Using roles for Amazon EKS clusters
](using-service-linked-roles-eks.md)
+ [
# Using roles for Amazon EKS node groups
](using-service-linked-roles-eks-nodegroups.md)
+ [
# Using roles for Amazon EKS Fargate profiles
](using-service-linked-roles-eks-fargate.md)
+ [
# Using roles to connect a Kubernetes cluster to Amazon EKS
](using-service-linked-roles-eks-connector.md)
+ [
# Using roles for Amazon EKS local clusters on Outpost
](using-service-linked-roles-eks-outpost.md)
+ [
# Using roles for Amazon EKS Dashboard
](using-service-linked-roles-eks-dashboard.md)
# Using roles for Amazon EKS clusters
Amazon Elastic Kubernetes Service uses AWS Identity and Access Management (IAM) [service-linked roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-service-linked-role). A service-linked role is a unique type of IAM role that is linked directly to Amazon EKS. Service-linked roles are predefined by Amazon EKS and include all the permissions that the service requires to call other AWS services on your behalf.
A service-linked role makes setting up Amazon EKS easier because you don’t have to manually add the necessary permissions. Amazon EKS defines the permissions of its service-linked roles, and unless defined otherwise, only Amazon EKS can assume its roles. The defined permissions include the trust policy and the permissions policy, and that permissions policy cannot be attached to any other IAM entity.
You can delete a service-linked role only after first deleting their related resources. This protects your Amazon EKS resources because you can’t inadvertently remove permission to access the resources.
For information about other services that support service-linked roles, see [AWS services that work with IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) and look for the services that have **Yes** in the **Service-linked role** column. Choose a **Yes** with a link to view the service-linked role documentation for that service.
## Service-linked role permissions for Amazon EKS
Amazon EKS uses the service-linked role named `AWSServiceRoleForAmazonEKS`. The role allows Amazon EKS to manage clusters in your account. The attached policies allow the role to manage the following resources: network interfaces, security groups, logs, and VPCs.
**Note**
The `AWSServiceRoleForAmazonEKS` service-linked role is distinct from the role required for cluster creation. For more information, see [Amazon EKS cluster IAM role](cluster-iam-role.md).
The `AWSServiceRoleForAmazonEKS` service-linked role trusts the following services to assume the role:
+ `eks.amazonaws.com`
The role permissions policy allows Amazon EKS to complete the following actions on the specified resources:
+ [AmazonEKSServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSServiceRolePolicy.html)
You must configure permissions to allow an IAM entity (such as a user, group, or role) to create, edit, or delete a service-linked role. For more information, see [Service-linked role permissions](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) in the *IAM User Guide*.
## Creating a service-linked role for Amazon EKS
You don’t need to manually create a service-linked role. When you create a cluster in the AWS Management Console, the AWS CLI, or the AWS API, Amazon EKS creates the service-linked role for you.
If you delete this service-linked role, and then need to create it again, you can use the same process to recreate the role in your account. When you create a cluster, Amazon EKS creates the service-linked role for you again.
## Editing a service-linked role for Amazon EKS
Amazon EKS does not allow you to edit the `AWSServiceRoleForAmazonEKS` service-linked role. After you create a service-linked role, you cannot change the name of the role because various entities might reference the role. However, you can edit the description of the role using IAM. For more information, see [Editing a service-linked role](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role) in the *IAM User Guide*.
## Deleting a service-linked role for Amazon EKS
If you no longer need to use a feature or service that requires a service-linked role, we recommend that you delete that role. That way you don’t have an unused entity that is not actively monitored or maintained. However, you must clean up your service-linked role before you can manually delete it.
### Cleaning up a service-linked role
Before you can use IAM to delete a service-linked role, you must first delete any resources used by the role.
**Note**
If the Amazon EKS service is using the role when you try to delete the resources, then the deletion might fail. If that happens, wait for a few minutes and try the operation again.
1. Open the [Amazon EKS console](https://console.aws.amazon.com/eks/home#/clusters).
1. In the left navigation pane, choose **Clusters**.
1. If your cluster has any node groups or Fargate profiles, you must delete them before you can delete the cluster. For more information, see [Delete a managed node group from your cluster](delete-managed-node-group.md) and [Delete a Fargate profile](delete-fargate-profile.md).
1. On the **Clusters** page, choose the cluster that you want to delete and choose **Delete**.
1. Type the name of the cluster in the deletion confirmation window, and then choose **Delete**.
1. Repeat this procedure for any other clusters in your account. Wait for all of the delete operations to finish.
### Manually delete the service-linked role
Use the IAM console, the AWS CLI, or the AWS API to delete the `AWSServiceRoleForAmazonEKS` service-linked role. For more information, see [Deleting a service-linked role](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role) in the *IAM User Guide*.
## Supported regions for Amazon EKS service-linked roles
Amazon EKS supports using service-linked roles in all of the regions where the service is available. For more information, see [Amazon EKS endpoints and quotas](https://docs.aws.amazon.com/general/latest/gr/eks.html).
# Using roles for Amazon EKS node groups
Amazon EKS uses AWS Identity and Access Management (IAM) [service-linked roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-service-linked-role). A service-linked role is a unique type of IAM role that is linked directly to Amazon EKS. Service-linked roles are predefined by Amazon EKS and include all the permissions that the service requires to call other AWS services on your behalf.
A service-linked role makes setting up Amazon EKS easier because you don’t have to manually add the necessary permissions. Amazon EKS defines the permissions of its service-linked roles, and unless defined otherwise, only Amazon EKS can assume its roles. The defined permissions include the trust policy and the permissions policy, and that permissions policy cannot be attached to any other IAM entity.
You can delete a service-linked role only after first deleting their related resources. This protects your Amazon EKS resources because you can’t inadvertently remove permission to access the resources.
For information about other services that support service-linked roles, see [AWS services that work with IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) and look for the services that have **Yes** in the **Service-linked role** column. Choose a **Yes** with a link to view the service-linked role documentation for that service.
## Service-linked role permissions for Amazon EKS
Amazon EKS uses the service-linked role named `AWSServiceRoleForAmazonEKSNodegroup`. The role allows Amazon EKS to manage node groups in your account. The attached `AWSServiceRoleForAmazonEKSNodegroup` policy allows the role to manage the following resources: Auto Scaling groups, security groups, launch templates, and IAM instance profiles. For more information, see [AWS managed policy: AWSServiceRoleForAmazonEKSNodegroup](security-iam-awsmanpol.md#security-iam-awsmanpol-awsserviceroleforamazoneksnodegroup).
The `AWSServiceRoleForAmazonEKSNodegroup` service-linked role trusts the following services to assume the role:
+ `eks-nodegroup.amazonaws.com`
The role permissions policy allows Amazon EKS to complete the following actions on the specified resources:
+ [AWSServiceRoleForAmazonEKSNodegroup](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSServiceRoleForAmazonEKSNodegroup.html)
You must configure permissions to allow an IAM entity (such as a user, group, or role) to create, edit, or delete a service-linked role. For more information, see [Service-linked role permissions](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) in the *IAM User Guide*.
## Creating a service-linked role for Amazon EKS
You don’t need to manually create a service-linked role. When you CreateNodegroup in the AWS Management Console, the AWS CLI, or the AWS API, Amazon EKS creates the service-linked role for you.
**Important**
This service-linked role can appear in your account if you completed an action in another service that uses the features supported by this role. If you were using the Amazon EKS service before January 1, 2017, when it began supporting service-linked roles, then Amazon EKS created the AWSServiceRoleForAmazonEKSNodegroup role in your account. To learn more, see [A new role appeared in my IAM account](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_roles.html#troubleshoot_roles_new-role-appeared).
### Creating a service-linked role in Amazon EKS (AWS API)
You don’t need to manually create a service-linked role. When you create a managed node group in the AWS Management Console, the AWS CLI, or the AWS API, Amazon EKS creates the service-linked role for you.
If you delete this service-linked role, and then need to create it again, you can use the same process to recreate the role in your account. When you create another managed node group, Amazon EKS creates the service-linked role for you again.
## Editing a service-linked role for Amazon EKS
Amazon EKS does not allow you to edit the `AWSServiceRoleForAmazonEKSNodegroup` service-linked role. After you create a service-linked role, you cannot change the name of the role because various entities might reference the role. However, you can edit the description of the role using IAM. For more information, see [Editing a service-linked role](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role) in the *IAM User Guide*.
## Deleting a service-linked role for Amazon EKS
If you no longer need to use a feature or service that requires a service-linked role, we recommend that you delete that role. That way you don’t have an unused entity that is not actively monitored or maintained. However, you must clean up your service-linked role before you can manually delete it.
### Cleaning up a service-linked role
Before you can use IAM to delete a service-linked role, you must first delete any resources used by the role.
**Note**
If the Amazon EKS service is using the role when you try to delete the resources, then the deletion might fail. If that happens, wait for a few minutes and try the operation again.
1. Open the [Amazon EKS console](https://console.aws.amazon.com/eks/home#/clusters).
1. In the left navigation pane, choose **Clusters**.
1. Select the **Compute** tab.
1. In the **Node groups** section, choose the node group to delete.
1. Type the name of the node group in the deletion confirmation window, and then choose **Delete**.
1. Repeat this procedure for any other node groups in the cluster. Wait for all of the delete operations to finish.
### Manually delete the service-linked role
Use the IAM console, the AWS CLI, or the AWS API to delete the `AWSServiceRoleForAmazonEKSNodegroup` service-linked role. For more information, see [Deleting a service-linked role](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role) in the *IAM User Guide*.
## Supported regions for Amazon EKS service-linked roles
Amazon EKS supports using service-linked roles in all of the regions where the service is available. For more information, see [Amazon EKS endpoints and quotas](https://docs.aws.amazon.com/general/latest/gr/eks.html).
# Using roles for Amazon EKS Fargate profiles
Amazon EKS uses AWS Identity and Access Management (IAM) [service-linked roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-service-linked-role). A service-linked role is a unique type of IAM role that is linked directly to Amazon EKS. Service-linked roles are predefined by Amazon EKS and include all the permissions that the service requires to call other AWS services on your behalf.
A service-linked role makes setting up Amazon EKS easier because you don’t have to manually add the necessary permissions. Amazon EKS defines the permissions of its service-linked roles, and unless defined otherwise, only Amazon EKS can assume its roles. The defined permissions include the trust policy and the permissions policy, and that permissions policy cannot be attached to any other IAM entity.
You can delete a service-linked role only after first deleting their related resources. This protects your Amazon EKS resources because you can’t inadvertently remove permission to access the resources.
For information about other services that support service-linked roles, see [AWS services that work with IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) and look for the services that have **Yes** in the **Service-linked role** column. Choose a **Yes** with a link to view the service-linked role documentation for that service.
## Service-linked role permissions for Amazon EKS
Amazon EKS uses the service-linked role named `AWSServiceRoleForAmazonEKSForFargate`. The role allows Amazon EKS Fargate to configure VPC networking required for Fargate Pods. The attached policies allow the role to create and delete elastic network interfaces and describe elastic network Interfaces and resources.
The `AWSServiceRoleForAmazonEKSForFargate` service-linked role trusts the following services to assume the role:
+ `eks-fargate.amazonaws.com`
The role permissions policy allows Amazon EKS to complete the following actions on the specified resources:
+ [AmazonEKSForFargateServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSForFargateServiceRolePolicy.html)
You must configure permissions to allow an IAM entity (such as a user, group, or role) to create, edit, or delete a service-linked role. For more information, see [Service-linked role permissions](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) in the *IAM User Guide*.
## Creating a service-linked role for Amazon EKS
You don’t need to manually create a service-linked role. When you create a Fargate profile in the AWS Management Console, the AWS CLI, or the AWS API, Amazon EKS creates the service-linked role for you.
**Important**
This service-linked role can appear in your account if you completed an action in another service that uses the features supported by this role. If you were using the Amazon EKS service before December 13, 2019, when it began supporting service-linked roles, then Amazon EKS created the AWSServiceRoleForAmazonEKSForFargate role in your account. To learn more, see [A New role appeared in my IAM account](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_roles.html#troubleshoot_roles_new-role-appeared).
### Creating a service-linked role in Amazon EKS (AWS API)
You don’t need to manually create a service-linked role. When you create a Fargate profile in the AWS Management Console, the AWS CLI, or the AWS API, Amazon EKS creates the service-linked role for you.
If you delete this service-linked role, and then need to create it again, you can use the same process to recreate the role in your account. When you create another managed node group, Amazon EKS creates the service-linked role for you again.
## Editing a service-linked role for Amazon EKS
Amazon EKS does not allow you to edit the `AWSServiceRoleForAmazonEKSForFargate` service-linked role. After you create a service-linked role, you cannot change the name of the role because various entities might reference the role. However, you can edit the description of the role using IAM. For more information, see [Editing a service-linked role](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role) in the *IAM User Guide*.
## Deleting a service-linked role for Amazon EKS
If you no longer need to use a feature or service that requires a service-linked role, we recommend that you delete that role. That way you don’t have an unused entity that is not actively monitored or maintained. However, you must clean up your service-linked role before you can manually delete it.
### Cleaning up a service-linked role
Before you can use IAM to delete a service-linked role, you must first delete any resources used by the role.
**Note**
If the Amazon EKS service is using the role when you try to delete the resources, then the deletion might fail. If that happens, wait for a few minutes and try the operation again.
1. Open the [Amazon EKS console](https://console.aws.amazon.com/eks/home#/clusters).
1. In the left navigation pane, choose **Clusters**.
1. On the **Clusters** page, select your cluster.
1. Select the **Compute** tab.
1. If there are any Fargate profiles in the **Fargate profiles** section, select each one individually, and then choose **Delete**.
1. Type the name of the profile in the deletion confirmation window, and then choose **Delete**.
1. Repeat this procedure for any other Fargate profiles in the cluster and for any other clusters in your account.
### Manually delete the service-linked role
Use the IAM console, the AWS CLI, or the AWS API to delete the AWSServiceRoleForAmazonEKSForFargate service-linked role. For more information, see [Deleting a service-linked role](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role) in the *IAM User Guide*.
## Supported regions for Amazon EKS service-linked roles
Amazon EKS supports using service-linked roles in all of the regions where the service is available. For more information, see [Amazon EKS endpoints and quotas](https://docs.aws.amazon.com/general/latest/gr/eks.html).
# Using roles to connect a Kubernetes cluster to Amazon EKS
Amazon EKS uses AWS Identity and Access Management (IAM) [service-linked roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-service-linked-role). A service-linked role is a unique type of IAM role that is linked directly to Amazon EKS. Service-linked roles are predefined by Amazon EKS and include all the permissions that the service requires to call other AWS services on your behalf.
A service-linked role makes setting up Amazon EKS easier because you don’t have to manually add the necessary permissions. Amazon EKS defines the permissions of its service-linked roles, and unless defined otherwise, only Amazon EKS can assume its roles. The defined permissions include the trust policy and the permissions policy, and that permissions policy cannot be attached to any other IAM entity.
You can delete a service-linked role only after first deleting their related resources. This protects your Amazon EKS resources because you can’t inadvertently remove permission to access the resources.
For information about other services that support service-linked roles, see [AWS services that work with IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) and look for the services that have **Yes** in the **Service-linked role** column. Choose a **Yes** with a link to view the service-linked role documentation for that service.
## Service-linked role permissions for Amazon EKS
Amazon EKS uses the service-linked role named `AWSServiceRoleForAmazonEKSConnector`. The role allows Amazon EKS to connect Kubernetes clusters. The attached policies allow the role to manage necessary resources to connect to your registered Kubernetes cluster.
The `AWSServiceRoleForAmazonEKSConnector` service-linked role trusts the following services to assume the role:
+ `eks-connector.amazonaws.com`
The role permissions policy allows Amazon EKS to complete the following actions on the specified resources:
+ [AmazonEKSConnectorServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSConnectorServiceRolePolicy.html)
You must configure permissions to allow an IAM entity (such as a user, group, or role) to create, edit, or delete a service-linked role. For more information, see [Service-linked role permissions](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) in the *IAM User Guide*.
This role uses SSM (Systems Manager) permissions to establish secure connections and manage connected Kubernetes clusters.
## Creating a service-linked role for Amazon EKS
You don’t need to manually create a service-linked role to connect a cluster. When you connect a cluster in the AWS Management Console, the AWS CLI, `eksctl`, or the AWS API, Amazon EKS creates the service-linked role for you.
If you delete this service-linked role, and then need to create it again, you can use the same process to recreate the role in your account. When you connect a cluster, Amazon EKS creates the service-linked role for you again.
## Editing a service-linked role for Amazon EKS
Amazon EKS does not allow you to edit the `AWSServiceRoleForAmazonEKSConnector` service-linked role. After you create a service-linked role, you cannot change the name of the role because various entities might reference the role. However, you can edit the description of the role using IAM. For more information, see [Editing a service-linked role](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role) in the *IAM User Guide*.
## Deleting a service-linked role for Amazon EKS
If you no longer need to use a feature or service that requires a service-linked role, we recommend that you delete that role. That way you don’t have an unused entity that is not actively monitored or maintained. However, you must clean up your service-linked role before you can manually delete it.
### Cleaning up a service-linked role
Before you can use IAM to delete a service-linked role, you must first delete any resources used by the role.
**Note**
If the Amazon EKS service is using the role when you try to delete the resources, then the deletion might fail. If that happens, wait for a few minutes and try the operation again.
1. Open the [Amazon EKS console](https://console.aws.amazon.com/eks/home#/clusters).
1. In the left navigation pane, choose **Clusters**.
1. On the **Clusters** page, select your cluster.
1. Select the **Deregister** tab and then select the **Ok** tab.
### Manually delete the service-linked role
Use the IAM console, the AWS CLI, or the AWS API to delete the AWSServiceRoleForAmazonEKSConnector service-linked role. For more information, see [Deleting a service-linked role](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role) in the *IAM User Guide*.
# Using roles for Amazon EKS local clusters on Outpost
Amazon Elastic Kubernetes Service uses AWS Identity and Access Management (IAM) [service-linked roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-service-linked-role). A service-linked role is a unique type of IAM role that is linked directly to Amazon EKS. Service-linked roles are predefined by Amazon EKS and include all the permissions that the service requires to call other AWS services on your behalf.
A service-linked role makes setting up Amazon EKS easier because you don’t have to manually add the necessary permissions. Amazon EKS defines the permissions of its service-linked roles, and unless defined otherwise, only Amazon EKS can assume its roles. The defined permissions include the trust policy and the permissions policy, and that permissions policy cannot be attached to any other IAM entity.
You can delete a service-linked role only after first deleting their related resources. This protects your Amazon EKS resources because you can’t inadvertently remove permission to access the resources.
For information about other services that support service-linked roles, see [AWS services that work with IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) and look for the services that have **Yes** in the **Service-linked role** column. Choose a **Yes** with a link to view the service-linked role documentation for that service.
## Service-linked role permissions for Amazon EKS
Amazon EKS uses the service-linked role named `AWSServiceRoleForAmazonEKSLocalOutpost`. The role allows Amazon EKS to manage local clusters in your account. The attached policies allow the role to manage the following resources: network interfaces, security groups, logs, and Amazon EC2 instances.
**Note**
The `AWSServiceRoleForAmazonEKSLocalOutpost` service-linked role is distinct from the role required for cluster creation. For more information, see [Amazon EKS cluster IAM role](cluster-iam-role.md).
The `AWSServiceRoleForAmazonEKSLocalOutpost` service-linked role trusts the following services to assume the role:
+ `outposts.eks-local.amazonaws.com`
The role permissions policy allows Amazon EKS to complete the following actions on the specified resources:
+ [AmazonEKSServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSServiceRolePolicy.html)
You must configure permissions to allow an IAM entity (such as a user, group, or role) to create, edit, or delete a service-linked role. For more information, see [Service-linked role permissions](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) in the *IAM User Guide*.
## Creating a service-linked role for Amazon EKS
You don’t need to manually create a service-linked role. When you create a cluster in the AWS Management Console, the AWS CLI, or the AWS API, Amazon EKS creates the service-linked role for you.
If you delete this service-linked role, and then need to create it again, you can use the same process to recreate the role in your account. When you create a cluster, Amazon EKS creates the service-linked role for you again.
## Editing a service-linked role for Amazon EKS
Amazon EKS does not allow you to edit the `AWSServiceRoleForAmazonEKSLocalOutpost` service-linked role. After you create a service-linked role, you can’t change the name of the role because various entities might reference the role. However, you can edit the description of the role using IAM. For more information, see [Editing a service-linked role](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role) in the *IAM User Guide*.
## Deleting a service-linked role for Amazon EKS
If you no longer need to use a feature or service that requires a service-linked role, we recommend that you delete that role. That way you don’t have an unused entity that is not actively monitored or maintained. However, you must clean up your service-linked role before you can manually delete it.
### Cleaning up a service-linked role
Before you can use IAM to delete a service-linked role, you must first delete any resources used by the role.
**Note**
If the Amazon EKS service is using the role when you try to delete the resources, then the deletion might fail. If that happens, wait for a few minutes and try the operation again.
1. Open the [Amazon EKS console](https://console.aws.amazon.com/eks/home#/clusters).
1. In the left navigation pane, choose Amazon EKS **Clusters**.
1. If your cluster has any node groups or Fargate profiles, you must delete them before you can delete the cluster. For more information, see [Delete a managed node group from your cluster](delete-managed-node-group.md) and [Delete a Fargate profile](delete-fargate-profile.md).
1. On the **Clusters** page, choose the cluster that you want to delete and choose **Delete**.
1. Type the name of the cluster in the deletion confirmation window, and then choose **Delete**.
1. Repeat this procedure for any other clusters in your account. Wait for all of the delete operations to finish.
### Manually delete the service-linked role
Use the IAM console, the AWS CLI, or the AWS API to delete the `AWSServiceRoleForAmazonEKSLocalOutpost` service-linked role. For more information, see [Deleting a service-linked role](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role) in the *IAM User Guide*.
## Supported regions for Amazon EKS service-linked roles
Amazon EKS supports using service-linked roles in all of the regions where the service is available. For more information, see [Amazon EKS endpoints and quotas](https://docs.aws.amazon.com/general/latest/gr/eks.html).
# Using roles for Amazon EKS Dashboard
The Amazon EKS Dashboard uses this service-linked role to aggregate information about cluster resources from multiple regions and accounts. The dashboard integrates with AWS Organizations to securely read information about multiple accounts in your organization.
To learn more about the Amazon EKS Dashboard, see [View aggregated data about cluster resources with the EKS Dashboard](cluster-dashboard.md).
## Background
Amazon EKS uses AWS Identity and Access Management (IAM) [service-linked roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-service-linked-role). A service-linked role is a unique type of IAM role that is linked directly to Amazon EKS. Service-linked roles are predefined by Amazon EKS and include all the permissions that the service requires to call other AWS services on your behalf.
A service-linked role makes setting up Amazon EKS easier because you don’t have to manually add the necessary permissions. Amazon EKS defines the permissions of its service-linked roles, and unless defined otherwise, only Amazon EKS can assume its roles. The defined permissions include the trust policy and the permissions policy, and that permissions policy cannot be attached to any other IAM entity.
You can delete a service-linked role only after first deleting their related resources. This protects your Amazon EKS resources because you can’t inadvertently remove permission to access the resources.
For information about other services that support service-linked roles, see [AWS services that work with IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) and look for the services that have **Yes** in the **Service-linked role** column. Choose a **Yes** with a link to view the service-linked role documentation for that service.
## Service-linked role permissions for Amazon EKS
Amazon EKS uses the service-linked role named `AWSServiceRoleForAmazonEKSDashboard`. The role allows Amazon EKS to generate and display the EKS Dashboard, including aggregated information about cluster resources. The attached `AmazonEKSDashboardServiceRolePolicy` policy allows the role to manage the following resources: Auto Scaling groups, security groups, launch templates, and IAM instance profiles. For more information, see [AWS managed policy: AmazonEKSDashboardServiceRolePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSDashboardServiceRolePolicy).
The `AWSServiceRoleForAmazonEKSDashboard` service-linked role trusts the following services to assume the role:
+ `dashboard.eks.amazonaws.com`
To view the latest version of the JSON policy document, see [AmazonEKSDashboardServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSDashboardServiceRolePolicy.html#AmazonEKSDashboardServiceRolePolicy-json) in the AWS Managed Policy Reference Guide.
You must configure permissions to allow an IAM entity (such as a user, group, or role) to create, edit, or delete a service-linked role. For more information, see [Service-linked role permissions](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) in the *IAM User Guide*.
## Creating a service-linked role for Amazon EKS
You don’t need to manually create a service-linked role. When you enable the dashboard in the AWS console, Amazon EKS creates the service-linked role for you.
For more information about enabling the EKS Dashboard, see [Configure EKS Dashboard integration with AWS Organizations](cluster-dashboard-orgs.md).
**Important**
This service-linked role can appear in your account if you completed an action in another service that uses the features supported by this role.
## Editing a service-linked role for Amazon EKS
Amazon EKS does not allow you to edit the `AWSServiceRoleForAmazonEKSDashboard` service-linked role. After you create a service-linked role, you cannot change the name of the role because various entities might reference the role. However, you can edit the description of the role using IAM. For more information, see [Editing a service-linked role](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role) in the *IAM User Guide*.
## Deleting a service-linked role for Amazon EKS
If you no longer need to use a feature or service that requires a service-linked role, we recommend that you delete that role. That way you don’t have an unused entity that is not actively monitored or maintained. However, you must clean up your service-linked role before you can manually delete it.
### Cleaning up a service-linked role
Before you can use IAM to delete a service-linked role, you must first delete any resources used by the role.
**Note**
If the Amazon EKS service is using the role when you try to delete the resources, then the deletion might fail. If that happens, wait for a few minutes and try the operation again.
For more information about disabling the EKS Dashboard, see [Configure EKS Dashboard integration with AWS Organizations](cluster-dashboard-orgs.md).
### Manually delete the service-linked role
Use the IAM console, the AWS CLI, or the AWS API to delete the `AWSServiceRoleForAmazonEKSDashboard` service-linked role. For more information, see [Deleting a service-linked role](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role) in the *IAM User Guide*.
## Supported regions for Amazon EKS service-linked roles
Amazon EKS supports using service-linked roles in all of the regions where the service is available. For more information, see [Amazon EKS endpoints and quotas](https://docs.aws.amazon.com/general/latest/gr/eks.html).
# Amazon EKS Pod execution IAM role
The Amazon EKS Pod execution role is required to run Pods on AWS Fargate infrastructure.
When your cluster creates Pods on AWS Fargate infrastructure, the components running on the Fargate infrastructure must make calls to AWS APIs on your behalf. This is so that they can do actions such as pull container images from Amazon ECR or route logs to other AWS services. The Amazon EKS Pod execution role provides the IAM permissions to do this.
When you create a Fargate profile, you must specify a Pod execution role for the Amazon EKS components that run on the Fargate infrastructure using the profile. This role is added to the cluster’s Kubernetes [Role based access control](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) (RBAC) for authorization. This allows the `kubelet` that’s running on the Fargate infrastructure to register with your Amazon EKS cluster so that it can appear in your cluster as a node.
**Note**
The Fargate profile must have a different IAM role than Amazon EC2 node groups.
**Important**
The containers running in the Fargate Pod can’t assume the IAM permissions associated with a Pod execution role. To give the containers in your Fargate Pod permissions to access other AWS services, you must use [IAM roles for service accounts](iam-roles-for-service-accounts.md).
Before you create a Fargate profile, you must create an IAM role with the [AmazonEKSFargatePodExecutionRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSFargatePodExecutionRolePolicy.html).
## Check for a correctly configured existing Pod execution role
You can use the following procedure to check and see if your account already has a correctly configured Amazon EKS Pod execution role. To avoid a confused deputy security problem, it’s important that the role restricts access based on `SourceArn`. You can modify the execution role as needed to include support for Fargate profiles on other clusters.
1. Open the IAM console at https://console.aws.amazon.com/iam/.
1. In the left navigation pane, choose **Roles**.
1. On the **Roles** page, search the list of roles for **AmazonEKSFargatePodExecutionRole**. If the role doesn’t exist, see [Creating the Amazon EKS Pod execution role](#create-pod-execution-role) to create the role. If the role does exist, choose the role.
1. On the **AmazonEKSFargatePodExecutionRole** page, do the following:
1. Choose **Permissions**.
1. Ensure that the **AmazonEKSFargatePodExecutionRolePolicy** Amazon managed policy is attached to the role.
1. Choose **Trust relationships**.
1. Choose **Edit trust policy**.
1. On the **Edit trust policy** page, verify that the trust relationship contains the following policy and has a line for Fargate profiles on your cluster. If so, choose **Cancel**.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Condition": {
"ArnLike": {
"aws:SourceArn": "arn:aws:eks:us-east-1:111122223333:fargateprofile/my-cluster/*"
}
},
"Principal": {
"Service": "eks-fargate-pods.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
If the policy matches but doesn’t have a line specifying the Fargate profiles on your cluster, you can add the following line at the top of the `ArnLike` object. Replace *region-code* with the AWS Region that your cluster is in, *111122223333* with your account ID, and *my-cluster* with the name of your cluster.
```
"aws:SourceArn": "arn:aws:eks:region-code:111122223333:fargateprofile/my-cluster/*",
```
If the policy doesn’t match, copy the full previous policy into the form and choose **Update policy**. Replace *region-code* with the AWS Region that your cluster is in. If you want to use the same role in all AWS Regions in your account, replace *region-code* with `*`. Replace *111122223333* with your account ID and *my-cluster* with the name of your cluster. If you want to use the same role for all clusters in your account, replace *my-cluster* with `*`.
## Creating the Amazon EKS Pod execution role
If you don’t already have the Amazon EKS Pod execution role for your cluster, you can use the AWS Management Console or the AWS CLI to create it.
AWS Management Console
1. Open the IAM console at https://console.aws.amazon.com/iam/.
1. In the left navigation pane, choose **Roles**.
1. On the **Roles** page, choose **Create role**.
1. On the **Select trusted entity** page, do the following:
1. In the **Trusted entity type** section, choose ** AWS service**.
1. From the **Use cases for other AWS services** dropdown list, choose **EKS**.
1. Choose **EKS - Fargate Pod**.
1. Choose **Next**.
1. On the **Add permissions** page, choose **Next**.
1. On the **Name, review, and create** page, do the following:
1. For **Role name**, enter a unique name for your role, such as `AmazonEKSFargatePodExecutionRole`.
1. Under **Add tags (Optional)**, add metadata to the role by attaching tags as key-value pairs. For more information about using tags in IAM, see [Tagging IAM resources](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_tags.html) in the *IAM User Guide*.
1. Choose **Create role**.
1. On the **Roles** page, search the list of roles for **AmazonEKSFargatePodExecutionRole**. Choose the role.
1. On the **AmazonEKSFargatePodExecutionRole** page, do the following:
1. Choose **Trust relationships**.
1. Choose **Edit trust policy**.
1. On the **Edit trust policy** page, do the following:
1. Copy and paste the following contents into the **Edit trust policy** form. Replace *region-code* with the AWS Region that your cluster is in. If you want to use the same role in all AWS Regions in your account, replace *region-code* with `*`. Replace *111122223333* with your account ID and *my-cluster* with the name of your cluster. If you want to use the same role for all clusters in your account, replace *my-cluster* with `*`.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Condition": {
"ArnLike": {
"aws:SourceArn": "arn:aws:eks:us-east-1:111122223333:fargateprofile/my-cluster/*"
}
},
"Principal": {
"Service": "eks-fargate-pods.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
1. Choose **Update policy**.
AWS CLI
1. Copy and paste the following contents to a file named `pod-execution-role-trust-policy.json`. Replace *region-code* with the AWS Region that your cluster is in. If you want to use the same role in all AWS Regions in your account, replace *region-code* with `*`. Replace *111122223333* with your account ID and *my-cluster* with the name of your cluster. If you want to use the same role for all clusters in your account, replace *my-cluster* with `*`.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Condition": {
"ArnLike": {
"aws:SourceArn": "arn:aws:eks:us-east-1:111122223333:fargateprofile/my-cluster/*"
}
},
"Principal": {
"Service": "eks-fargate-pods.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
1. Create a Pod execution IAM role.
```
aws iam create-role \
--role-name AmazonEKSFargatePodExecutionRole \
--assume-role-policy-document file://"pod-execution-role-trust-policy.json"
```
1. Attach the required Amazon EKS managed IAM policy to the role.
```
aws iam attach-role-policy \
--policy-arn arn:aws:iam::aws:policy/AmazonEKSFargatePodExecutionRolePolicy \
--role-name AmazonEKSFargatePodExecutionRole
```
# Amazon EKS connector IAM role
You can connect Kubernetes clusters to view them in your AWS Management Console. To connect to a Kubernetes cluster, create an IAM role.
## Check for an existing EKS connector role
You can use the following procedure to check and see if your account already has the Amazon EKS connector role.
1. Open the IAM console at https://console.aws.amazon.com/iam/.
1. In the left navigation pane, choose **Roles**.
1. Search the list of roles for `AmazonEKSConnectorAgentRole`. If a role that includes `AmazonEKSConnectorAgentRole` doesn’t exist, then see [Creating the Amazon EKS connector agent role](#create-connector-role) to create the role. If a role that includes `AmazonEKSConnectorAgentRole` does exist, then select the role to view the attached policies.
1. Choose **Permissions**.
1. Ensure that the **AmazonEKSConnectorAgentPolicy** managed policy is attached to the role. If the policy is attached, your Amazon EKS connector role is properly configured.
1. Choose **Trust relationships**, and then choose **Edit trust policy**.
1. Verify that the trust relationship contains the following policy. If the trust relationship matches the following policy, choose **Cancel**. If the trust relationship doesn’t match, copy the policy into the **Edit trust policy** window and choose **Update policy**.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": [
"ssm.amazonaws.com"
]
},
"Action": "sts:AssumeRole"
}
]
}
```
## Creating the Amazon EKS connector agent role
You can use the AWS Management Console or AWS CloudFormation to create the connector agent role.
AWS CLI
1. Create a file named `eks-connector-agent-trust-policy.json` that contains the following JSON to use for the IAM role.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": [
"ssm.amazonaws.com"
]
},
"Action": "sts:AssumeRole"
}
]
}
```
1. Create a file named `eks-connector-agent-policy.json` that contains the following JSON to use for the IAM role.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "SsmControlChannel",
"Effect": "Allow",
"Action": [
"ssmmessages:CreateControlChannel"
],
"Resource": "arn:aws:eks:*:*:cluster/*"
},
{
"Sid": "ssmDataplaneOperations",
"Effect": "Allow",
"Action": [
"ssmmessages:CreateDataChannel",
"ssmmessages:OpenDataChannel",
"ssmmessages:OpenControlChannel"
],
"Resource": "*"
}
]
}
```
1. Create the Amazon EKS Connector agent role using the trust policy and policy you created in the previous list items.
```
aws iam create-role \
--role-name AmazonEKSConnectorAgentRole \
--assume-role-policy-document file://eks-connector-agent-trust-policy.json
```
1. Attach the policy to your Amazon EKS Connector agent role.
```
aws iam put-role-policy \
--role-name AmazonEKSConnectorAgentRole \
--policy-name AmazonEKSConnectorAgentPolicy \
--policy-document file://eks-connector-agent-policy.json
```
AWS CloudFormation
1. Save the following AWS CloudFormation template to a text file on your local system.
**Note**
This template also creates the service-linked role that would otherwise be created when the `registerCluster` API is called. See [Using roles to connect a Kubernetes cluster to Amazon EKS](using-service-linked-roles-eks-connector.md) for details.
```
---
AWSTemplateFormatVersion: '2010-09-09'
Description: 'Provisions necessary resources needed to register clusters in EKS'
Parameters: {}
Resources:
EKSConnectorSLR:
Type: AWS::IAM::ServiceLinkedRole
Properties:
AWSServiceName: eks-connector.amazonaws.com
EKSConnectorAgentRole:
Type: AWS::IAM::Role
Properties:
AssumeRolePolicyDocument:
Version: '2012-10-17'
Statement:
- Effect: Allow
Action: [ 'sts:AssumeRole' ]
Principal:
Service: 'ssm.amazonaws.com'
EKSConnectorAgentPolicy:
Type: AWS::IAM::Policy
Properties:
PolicyName: EKSConnectorAgentPolicy
Roles:
- {Ref: 'EKSConnectorAgentRole'}
PolicyDocument:
Version: '2012-10-17'
Statement:
- Effect: 'Allow'
Action: [ 'ssmmessages:CreateControlChannel' ]
Resource:
- Fn::Sub: 'arn:${AWS::Partition}:eks:*:*:cluster/*'
- Effect: 'Allow'
Action: [ 'ssmmessages:CreateDataChannel', 'ssmmessages:OpenDataChannel', 'ssmmessages:OpenControlChannel' ]
Resource: "*"
Outputs:
EKSConnectorAgentRoleArn:
Description: The agent role that EKS connector uses to communicate with AWS services.
Value: !GetAtt EKSConnectorAgentRole.Arn
```
1. Open the [AWS CloudFormation console](https://console.aws.amazon.com/cloudformation/).
1. Choose **Create stack** with new resources (standard).
1. For **Specify template**, select **Upload a template file**, and then choose **Choose file**.
1. Choose the file you created earlier, and then choose **Next**.
1. For **Stack name**, enter a name for your role, such as `eksConnectorAgentRole`, and then choose **Next**.
1. On the **Configure stack options** page, choose **Next**.
1. On the **Review** page, review your information, acknowledge that the stack might create IAM resources, and then choose **Create stack**.
# AWS managed policies for Amazon Elastic Kubernetes Service
An AWS managed policy is a standalone policy that is created and administered by AWS. AWS managed policies are designed to provide permissions for many common use cases so that you can start assigning permissions to users, groups, and roles.
Keep in mind that AWS managed policies might not grant least-privilege permissions for your specific use cases because they’re available for all AWS customers to use. We recommend that you reduce permissions further by defining [customer managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies) that are specific to your use cases.
You cannot change the permissions defined in AWS managed policies. If AWS updates the permissions defined in an AWS managed policy, the update affects all principal identities (users, groups, and roles) that the policy is attached to. AWS is most likely to update an AWS managed policy when a new AWS service is launched or new API operations become available for existing services.
For more information, see [AWS managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) in the *IAM User Guide*.
## AWS managed policy: AmazonEKS\$1CNI\$1Policy
You can attach the `AmazonEKS_CNI_Policy` to your IAM entities. Before you create an Amazon EC2 node group, this policy must be attached to either the [node IAM role](create-node-role.md), or to an IAM role that’s used specifically by the Amazon VPC CNI plugin for Kubernetes. This is so that it can perform actions on your behalf. We recommend that you attach the policy to a role that’s used only by the plugin. For more information, see [Assign IPs to Pods with the Amazon VPC CNI](managing-vpc-cni.md) and [Configure Amazon VPC CNI plugin to use IRSA](cni-iam-role.md).
**Permissions details**
This policy includes the following permissions that allow Amazon EKS to complete the following tasks:
+ ** `ec2:*NetworkInterface` and `ec2:*PrivateIpAddresses` ** – Allows the Amazon VPC CNI plugin to perform actions such as provisioning Elastic Network Interfaces and IP addresses for Pods to provide networking for applications that run in Amazon EKS.
+ ** `ec2` read actions** – Allows the Amazon VPC CNI plugin to perform actions such as describe instances and subnets to see the amount of free IP addresses in your Amazon VPC subnets. The VPC CNI can use the free IP addresses in each subnet to pick the subnets with the most free IP addresses to use when creating an elastic network interface.
To view the latest version of the JSON policy document, see [AmazonEKS\$1CNI\$1Policy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKS_CNI_Policy.html#AmazonEKS_CNI_Policy-json) in the AWS Managed Policy Reference Guide.
## AWS managed policy: AmazonEKSClusterPolicy
You can attach `AmazonEKSClusterPolicy` to your IAM entities. Before creating a cluster, you must have a [cluster IAM role](cluster-iam-role.md) with this policy attached. Kubernetes clusters that are managed by Amazon EKS make calls to other AWS services on your behalf. They do this to manage the resources that you use with the service.
This policy includes the following permissions that allow Amazon EKS to complete the following tasks:
+ ** `autoscaling` ** – Read and update the configuration of an Auto Scaling group. These permissions aren’t used by Amazon EKS but remain in the policy for backwards compatibility.
+ ** `ec2` ** – Work with volumes and network resources that are associated to Amazon EC2 nodes. This is required so that the Kubernetes control plane can join instances to a cluster and dynamically provision and manage Amazon EBS volumes that are requested by Kubernetes persistent volumes.
+ ** `ec2` ** - Delete elastic network interfaces that are created by the VPC CNI. This is required so that EKS can clean up elastic network interfaces that are left behind if the VPC CNI quits unexpectedly.
+ ** `elasticloadbalancing` ** – Work with Elastic Load Balancers and add nodes to them as targets. This is required so that the Kubernetes control plane can dynamically provision Elastic Load Balancers requested by Kubernetes services.
+ ** `iam` ** – Create a service-linked role. This is required so that the Kubernetes control plane can dynamically provision Elastic Load Balancers that are requested by Kubernetes services.
+ ** `kms` ** – Read a key from AWS KMS. This is required for the Kubernetes control plane to support [secrets encryption](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/) of Kubernetes secrets stored in `etcd`.
To view the latest version of the JSON policy document, see [AmazonEKSClusterPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSClusterPolicy.html#AmazonEKSClusterPolicy-json) in the AWS Managed Policy Reference Guide.
## AWS managed policy: AmazonEKSDashboardConsoleReadOnly
You can attach `AmazonEKSDashboardConsoleReadOnly` to your IAM entities.
This policy includes the following permissions that allow Amazon EKS to complete the following tasks:
+ ** `eks` ** - Read-only access to EKS dashboard data, resources, and cluster versions information. This allows viewing EKS-related metrics and cluster configuration details.
+ ** `organizations` ** - Read-only access to AWS Organizations information, including:
+ Viewing organization details and service access
+ Listing organizational roots, accounts, and organizational units
+ Viewing organization structure
To view the latest version of the JSON policy document, see [AmazonEKSDashboardConsoleReadOnly](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSDashboardConsoleReadOnly.html#AmazonEKSDashboardConsoleReadOnly-json) in the AWS Managed Policy Reference Guide.
## AWS managed policy: AmazonEKSFargatePodExecutionRolePolicy
You can attach `AmazonEKSFargatePodExecutionRolePolicy` to your IAM entities. Before you can create a Fargate profile, you must create a Fargate Pod execution role and attach this policy to it. For more information, see [Step 2: Create a Fargate Pod execution role](fargate-getting-started.md#fargate-sg-pod-execution-role) and [Define which Pods use AWS Fargate when launched](fargate-profile.md).
This policy grants the role the permissions that provide access to other AWS service resources that are required to run Amazon EKS Pods on Fargate.
**Permissions details**
This policy includes the following permissions that allow Amazon EKS to complete the following tasks:
+ ** `ecr` ** – Allows Pods that are running on Fargate to pull container images that are stored in Amazon ECR.
To view the latest version of the JSON policy document, see [AmazonEKSFargatePodExecutionRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSFargatePodExecutionRolePolicy.html#AmazonEKSFargatePodExecutionRolePolicy-json) in the AWS Managed Policy Reference Guide.
## AWS managed policy: AmazonEKSConnectorServiceRolePolicy
You can’t attach `AmazonEKSConnectorServiceRolePolicy` to your IAM entities. This policy is attached to a service-linked role that allows Amazon EKS to perform actions on your behalf. For more information, see [Using roles to connect a Kubernetes cluster to Amazon EKS](using-service-linked-roles-eks-connector.md).
The role allows Amazon EKS to connect Kubernetes clusters. The attached policies allow the role to manage necessary resources to connect to your registered Kubernetes cluster.
**Permissions details**
This policy includes the following permissions that allow Amazon EKS to complete the following tasks.
+ ** `SSM Management` ** – Create, describe, and delete SSM activations, and deregister managed instances. This allows basic Systems Manager operations.
+ ** `Session Management` ** – Start SSM sessions specifically for EKS clusters and execute non-interactive commands using the AmazonEKS document.
+ ** `IAM Role Passing` ** – Pass IAM roles specifically to the SSM service, controlled by a condition that restricts the passed roles to `ssm.amazonaws.com`.
+ ** `EventBridge Rules` ** – Create EventBridge rules and targets, but only when managed by `eks-connector.amazonaws.com`. Rules are specifically limited to AWS SSM as the event source.
To view the latest version of the JSON policy document, see [AmazonEKSConnectorServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSConnectorServiceRolePolicy.html) in the AWS Managed Policy Reference Guide.
## AWS managed policy: AmazonEKSForFargateServiceRolePolicy
You can’t attach `AmazonEKSForFargateServiceRolePolicy` to your IAM entities. This policy is attached to a service-linked role that allows Amazon EKS to perform actions on your behalf. For more information, see `AWSServiceRoleforAmazonEKSForFargate`.
This policy grants necessary permissions to Amazon EKS to run Fargate tasks. The policy is only used if you have Fargate nodes.
**Permissions details**
This policy includes the following permissions that allow Amazon EKS to complete the following tasks.
+ ** `ec2` ** – Create and delete Elastic Network Interfaces and describe Elastic Network Interfaces and resources. This is required so that the Amazon EKS Fargate service can configure the VPC networking that’s required for Fargate Pods.
To view the latest version of the JSON policy document, see [AmazonEKSForFargateServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSForFargateServiceRolePolicy.html#AmazonEKSForFargateServiceRolePolicy-json) in the AWS Managed Policy Reference Guide.
## AWS managed policy: AmazonEKSComputePolicy
You can attach `AmazonEKSComputePolicy` to your IAM entities. You may attach this policy to your [cluster IAM role](cluster-iam-role.md) to expand the resources EKS can manage in your account.
This policy grants the permissions required for Amazon EKS to create and manage EC2 instances for the EKS cluster, and the necessary IAM permissions to configure EC2. Also, this policy grants the permissions for Amazon EKS to create the EC2 Spot service-linked role on your behalf.
### Permissions details
This policy includes the following permissions that allow Amazon EKS to complete the following tasks:
+ ** `ec2` Permissions**:
+ `ec2:CreateFleet` and `ec2:RunInstances` - Allows creating EC2 instances and using specific EC2 resources (images, security groups, subnets) for EKS cluster nodes.
+ `ec2:CreateLaunchTemplate` - Allows creating EC2 launch templates for EKS cluster nodes.
+ The policy also includes conditions to restrict the use of these EC2 permissions to resources tagged with the EKS cluster name and other relevant tags.
+ `ec2:CreateTags` - Allows adding tags to EC2 resources created by the `CreateFleet`, `RunInstances`, and `CreateLaunchTemplate` actions.
+ ** `iam` Permissions**:
+ `iam:AddRoleToInstanceProfile` - Allows adding an IAM role to the EKS compute instance profile.
+ `iam:PassRole` - Allows passing the necessary IAM roles to the EC2 service.
To view the latest version of the JSON policy document, see [AmazonEKSComputePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSComputePolicy.html#AmazonEKSComputePolicy-json) in the AWS Managed Policy Reference Guide.
## AWS managed policy: AmazonEKSNetworkingPolicy
You can attach `AmazonEKSNetworkingPolicy` to your IAM entities. You may attach this policy to your [cluster IAM role](cluster-iam-role.md) to expand the resources EKS can manage in your account.
This policy is designed to grant the necessary permissions for Amazon EKS to create and manage network interfaces for the EKS cluster, allowing the control plane and worker nodes to communicate and function properly.
### Permissions details
This policy grants the following permissions to allow Amazon EKS to manage network interfaces for the cluster:
+ ** `ec2` Network Interface Permissions**:
+ `ec2:CreateNetworkInterface` - Allows creating EC2 network interfaces.
+ The policy includes conditions to restrict the use of this permission to network interfaces tagged with the EKS cluster name and the Kubernetes CNI node name.
+ `ec2:CreateTags` - Allows adding tags to the network interfaces created by the `CreateNetworkInterface` action.
+ ** `ec2` Network Interface Management Permissions**:
+ `ec2:AttachNetworkInterface`, `ec2:ModifyNetworkInterfaceAttribute`, `ec2:DetachNetworkInterface` - Allows attaching, modifying network interface attributes and detaching network interfaces to EC2 instances.
+ `ec2:UnassignPrivateIpAddresses`, `ec2:UnassignIpv6Addresses`, `ec2:AssignPrivateIpAddresses`, `ec2:AssignIpv6Addresses` - Allows managing the IP address assignments of the network interfaces.
+ These permissions are restricted to network interfaces tagged with the EKS cluster name.
To view the latest version of the JSON policy document, see [AmazonEKSNetworkingPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSNetworkingPolicy.html#AmazonEKSNetworkingPolicy-json) in the AWS Managed Policy Reference Guide.
## AWS managed policy: AmazonEKSBlockStoragePolicy
You can attach `AmazonEKSBlockStoragePolicy` to your IAM entities. You may attach this policy to your [cluster IAM role](cluster-iam-role.md) to expand the resources EKS can manage in your account.
This policy grants the necessary permissions for Amazon EKS to create, manage, and maintain EC2 volumes and snapshots for the EKS cluster, enabling the control plane and worker nodes to provision and use persistent storage as required by Kubernetes workloads.
### Permissions details
This IAM policy grants the following permissions to allow Amazon EKS to manage EC2 volumes and snapshots:
+ ** `ec2` Volume Management Permissions**:
+ `ec2:AttachVolume`, `ec2:DetachVolume`, `ec2:ModifyVolume`, `ec2:EnableFastSnapshotRestores` - Allows attaching, detaching, modifying, and enabling fast snapshot restores for EC2 volumes.
+ These permissions are restricted to volumes tagged with the EKS cluster name.
+ `ec2:CreateTags` - Allows adding tags to the EC2 volumes and snapshots created by the `CreateVolume` and `CreateSnapshot` actions.
+ ** `ec2` Volume Creation Permissions**:
+ `ec2:CreateVolume` - Allows creating new EC2 volumes.
+ The policy includes conditions to restrict the use of this permission to volumes tagged with the EKS cluster name and other relevant tags.
+ `ec2:CreateSnapshot` - Allows creating new EC2 volume snapshots.
+ The policy includes conditions to restrict the use of this permission to snapshots tagged with the EKS cluster name and other relevant tags.
To view the latest version of the JSON policy document, see [AmazonEKSBlockStoragePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSBlockStoragePolicy.html#AmazonEKSBlockStoragePolicy-json) in the AWS Managed Policy Reference Guide.
## AWS managed policy: AmazonEKSLoadBalancingPolicy
You can attach `AmazonEKSLoadBalancingPolicy` to your IAM entities. You may attach this policy to your [cluster IAM role](cluster-iam-role.md) to expand the resources EKS can manage in your account.
This IAM policy grants the necessary permissions for Amazon EKS to work with various AWS services to manage Elastic Load Balancers (ELBs) and related resources.
### Permissions details
The key permissions granted by this policy are:
+ ** `elasticloadbalancing` **: Allows creating, modifying, and managing Elastic Load Balancers and Target Groups. This includes permissions to create, update, and delete load balancers, target groups, listeners, and rules.
+ ** `ec2` **: Allows creating and managing security groups, which are required for the Kubernetes control plane to join instances to a cluster and manage Amazon EBS volumes. Also allows describing and listing EC2 resources such as instances, VPCs, Subnets, Security Groups, and other networking resources.
+ ** `iam` **: Allows creating a service-linked role for Elastic Load Balancing, which is required for the Kubernetes control plane to dynamically provision ELBs.
+ ** `kms` **: Allows reading a key from AWS KMS, which is required for the Kubernetes control plane to support encryption of Kubernetes secrets stored in etcd.
+ ** `wafv2` ** and ** `shield` **: Allows associating and disassociating Web ACLs and creating/deleting AWS Shield protections for the Elastic Load Balancers.
+ ** `cognito-idp` **, ** `acm` **, and ** `elasticloadbalancing` **: Grants permissions to describe user pool clients, list and describe certificates, and describe target groups, which are required for the Kubernetes control plane to manage the Elastic Load Balancers.
The policy also includes several condition checks to ensure that the permissions are scoped to the specific EKS cluster being managed, using the `eks:eks-cluster-name` tag.
To view the latest version of the JSON policy document, see [AmazonEKSLoadBalancingPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSLoadBalancingPolicy.html#AmazonEKSLoadBalancingPolicy-json) in the AWS Managed Policy Reference Guide.
## AWS managed policy: AmazonEKSMCPReadOnlyAccess
You can attach `AmazonEKSMCPReadOnlyAccess` to your IAM entities. This policy provides read-only access to Amazon EKS resources and related AWS services, enabling the Amazon EKS Model Context Protocol (MCP) Server to perform observability and troubleshooting operations without making any modifications to your infrastructure.
**Permissions details**
This policy includes the following permissions that allow principals to complete the following tasks:
+ ** `eks` ** Allows principals to describe and list EKS clusters, node groups, add-ons, access entries, insights, and access the Kubernetes API for read-only operations.
+ ** `iam` ** Allows principals to retrieve information about IAM roles, policies, and their attachments to understand the permissions associated with EKS resources.
+ ** `ec2` ** Allows principals to describe VPCs, subnets, and route tables to understand the network configuration of EKS clusters.
+ ** `sts` ** Allows principals to retrieve caller identity information for authentication and authorization purposes.
+ ** `logs` ** Allows principals to start queries and retrieve query results from CloudWatch Logs for troubleshooting and monitoring.
+ ** `cloudwatch` ** Allows principals to retrieve metric data for monitoring cluster and workload performance.
+ ** `eks-mcp` ** Allows principals to invoke MCP operations and call read-only tools within the Amazon EKS MCP Server.
To view the latest version of the JSON policy document, see [AmazonEKSMCPReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSMCPReadOnlyAccess.html) in the AWS Managed Policy Reference Guide.
## AWS managed policy: AmazonEKSServicePolicy
You can attach `AmazonEKSServicePolicy` to your IAM entities. Clusters that were created before April 16, 2020, required you to create an IAM role and attach this policy to it. Clusters that were created on or after April 16, 2020, don’t require you to create a role and don’t require you to assign this policy. When you create a cluster using an IAM principal that has the `iam:CreateServiceLinkedRole` permission, the [AWSServiceRoleforAmazonEKS](using-service-linked-roles-eks.md#service-linked-role-permissions-eks) service-linked role is automatically created for you. The service-linked role has the [managed policy: AmazonEKSServiceRolePolicy](#security-iam-awsmanpol-amazoneksservicerolepolicy) attached to it.
This policy allows Amazon EKS to create and manage the necessary resources to operate Amazon EKS clusters.
**Permissions details**
This policy includes the following permissions that allow Amazon EKS to complete the following tasks.
+ ** `eks` ** – Update the Kubernetes version of your cluster after you initiate an update. This permission isn’t used by Amazon EKS but remains in the policy for backwards compatibility.
+ ** `ec2` ** – Work with Elastic Network Interfaces and other network resources and tags. This is required by Amazon EKS to configure networking that facilitates communication between nodes and the Kubernetes control plane. Read information about security groups. Update tags on security groups.
+ ** `route53` ** – Associate a VPC with a hosted zone. This is required by Amazon EKS to enable private endpoint networking for your Kubernetes cluster API server.
+ ** `logs` ** – Log events. This is required so that Amazon EKS can ship Kubernetes control plane logs to CloudWatch.
+ ** `iam` ** – Create a service-linked role. This is required so that Amazon EKS can create the [Service-linked role permissions for Amazon EKS](using-service-linked-roles-eks.md#service-linked-role-permissions-eks) service-linked role on your behalf.
To view the latest version of the JSON policy document, see [AmazonEKSServicePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSServicePolicy.html#AmazonEKSServicePolicy-json) in the AWS Managed Policy Reference Guide.
## AWS managed policy: AmazonEKSServiceRolePolicy
You can’t attach `AmazonEKSServiceRolePolicy` to your IAM entities. This policy is attached to a service-linked role that allows Amazon EKS to perform actions on your behalf. For more information, see [Service-linked role permissions for Amazon EKS](using-service-linked-roles-eks.md#service-linked-role-permissions-eks). When you create a cluster using an IAM principal that has the `iam:CreateServiceLinkedRole` permission, the [AWSServiceRoleforAmazonEKS](using-service-linked-roles-eks.md#service-linked-role-permissions-eks) service-linked role is automatically created for you and this policy is attached to it.
This policy allows the service-linked role to call AWS services on your behalf.
**Permissions details**
This policy includes the following permissions that allow Amazon EKS to complete the following tasks.
+ ** `ec2` ** – Create and describe Elastic Network Interfaces and Amazon EC2 instances, the cluster security group, and VPC that are required to create a cluster. For more information, see [View Amazon EKS security group requirements for clusters](sec-group-reqs.md). Read information about security groups. Update tags on security groups. Read information about On-Demand Capacity Reservations. Read VPC configuration including route tables and network ACLs to detect configuration issues as part of cluster insights.
+ ** `ec2` Auto Mode** – Terminate EC2 instances created by EKS Auto Mode. For more information, see [Automate cluster infrastructure with EKS Auto Mode](automode.md).
+ ** `iam` ** – List all of the managed policies that attached to an IAM role. This is required so that Amazon EKS can list and validate all managed policies and permissions required to create a cluster.
+ **Associate a VPC with a hosted zone** – This is required by Amazon EKS to enable private endpoint networking for your Kubernetes cluster API server.
+ **Log event** – This is required so that Amazon EKS can ship Kubernetes control plane logs to CloudWatch.
+ **Put metric** – This is required so that Amazon EKS can ship Kubernetes control plane logs to CloudWatch.
+ ** `eks` ** - Manage cluster access entries and policies, allowing fine-grained control over who can access EKS resources and what actions they can perform. This includes associating standard access policies for compute, networking, load balancing, and storage operations.
+ ** `elasticloadbalancing` ** - Create, manage, and delete load balancers and their components (listeners, target groups, certificates) that are associated with EKS clusters. View load balancer attributes and health status.
+ ** `events` ** - Create and manage EventBridge rules for monitoring EC2 and AWS Health events related to EKS clusters, enabling automated responses to infrastructure changes and health alerts.
+ ** `iam` ** - Manage EC2 instance profiles with the "eks" prefix, including creation, deletion, and role association, which is necessary for EKS node management. Allows describing any instance profile to enable users to define custom instance profiles for their worker nodes to use.
+ ** `pricing` ** ** `shield` ** - Access AWS pricing information and Shield protection status, enabling cost management and advanced security features for EKS resources.
+ **Resource cleanup** - Safely delete EKS-tagged resources including volumes, snapshots, launch templates, and network interfaces during cluster cleanup operations.
To view the latest version of the JSON policy document, see [AmazonEKSServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSServiceRolePolicy.html#AmazonEKSServiceRolePolicy-json) in the AWS Managed Policy Reference Guide.
## AWS managed policy: AmazonEKSVPCResourceController
You can attach the `AmazonEKSVPCResourceController` policy to your IAM identities. If you’re using [security groups for Pods](security-groups-for-pods.md), you must attach this policy to your [Amazon EKS cluster IAM role](cluster-iam-role.md) to perform actions on your behalf.
This policy grants the cluster role permissions to manage Elastic Network Interfaces and IP addresses for nodes.
**Permissions details**
This policy includes the following permissions that allow Amazon EKS to complete the following tasks:
+ ** `ec2` ** – Manage Elastic Network Interfaces and IP addresses to support Pod security groups and Windows nodes.
To view the latest version of the JSON policy document, see [AmazonEKSVPCResourceController](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSVPCResourceController.html#AmazonEKSVPCResourceController-json) in the AWS Managed Policy Reference Guide.
## AWS managed policy: AmazonEKSWorkerNodePolicy
You can attach the `AmazonEKSWorkerNodePolicy` to your IAM entities. You must attach this policy to a [node IAM role](create-node-role.md) that you specify when you create Amazon EC2 nodes that allow Amazon EKS to perform actions on your behalf. If you create a node group using `eksctl`, it creates the node IAM role and attaches this policy to the role automatically.
This policy grants Amazon EKS Amazon EC2 nodes permissions to connect to Amazon EKS clusters.
**Permissions details**
This policy includes the following permissions that allow Amazon EKS to complete the following tasks:
+ ** `ec2` ** – Read instance volume and network information. This is required so that Kubernetes nodes can describe information about Amazon EC2 resources that are required for the node to join the Amazon EKS cluster.
+ ** `eks` ** – Optionally describe the cluster as part of node bootstrapping.
+ ** `eks-auth:AssumeRoleForPodIdentity` ** – Allow retrieving credentials for EKS workloads on the node. This is required for EKS Pod Identity to function properly.
To view the latest version of the JSON policy document, see [AmazonEKSWorkerNodePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSWorkerNodePolicy.html#AmazonEKSWorkerNodePolicy-json) in the AWS Managed Policy Reference Guide.
## AWS managed policy: AmazonEKSWorkerNodeMinimalPolicy
You can attach the AmazonEKSWorkerNodeMinimalPolicy to your IAM entities. You may attach this policy to a node IAM role that you specify when you create Amazon EC2 nodes that allow Amazon EKS to perform actions on your behalf.
This policy grants Amazon EKS Amazon EC2 nodes permissions to connect to Amazon EKS clusters. This policy has fewer permissions compared to AmazonEKSWorkerNodePolicy.
**Permissions details**
This policy includes the following permissions that allow Amazon EKS to complete the following tasks:
+ `eks-auth:AssumeRoleForPodIdentity` - Allow retrieving credentials for EKS workloads on the node. This is required for EKS Pod Identity to function properly.
To view the latest version of the JSON policy document, see [AmazonEKSWorkerNodePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSWorkerNodeMinimalPolicy.html#AmazonEKSWorkerNodeMinimalPolicy-json) in the AWS Managed Policy Reference Guide.
## AWS managed policy: AWSServiceRoleForAmazonEKSNodegroup
You can’t attach `AWSServiceRoleForAmazonEKSNodegroup` to your IAM entities. This policy is attached to a service-linked role that allows Amazon EKS to perform actions on your behalf. For more information, see [Service-linked role permissions for Amazon EKS](using-service-linked-roles-eks-nodegroups.md#service-linked-role-permissions-eks-nodegroups).
This policy grants the `AWSServiceRoleForAmazonEKSNodegroup` role permissions that allow it to create and manage Amazon EC2 node groups in your account.
**Permissions details**
This policy includes the following permissions that allow Amazon EKS to complete the following tasks:
+ ** `ec2` ** – Work with security groups, tags, capacity reservations, and launch templates. This is required for Amazon EKS managed node groups to enable remote access configuration and to describe capacity reservations that can be used in managed node groups. Additionally, Amazon EKS managed node groups create a launch template on your behalf. This is to configure the Amazon EC2 Auto Scaling group that backs each managed node group.
+ ** `iam` ** – Create a service-linked role and pass a role. This is required by Amazon EKS managed node groups to manage instance profiles for the role being passed when creating a managed node group. This instance profile is used by Amazon EC2 instances launched as part of a managed node group. Amazon EKS needs to create service-linked roles for other services such as Amazon EC2 Auto Scaling groups. These permissions are used in the creation of a managed node group.
+ ** `autoscaling` ** – Work with security Auto Scaling groups. This is required by Amazon EKS managed node groups to manage the Amazon EC2 Auto Scaling group that backs each managed node group. It’s also used to support functionality such as evicting Pods when nodes are terminated or recycled during node group updates and managing warm pools configured on managed node groups.
To view the latest version of the JSON policy document, see [AWSServiceRoleForAmazonEKSNodegroup](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSServiceRoleForAmazonEKSNodegroup.html#AWSServiceRoleForAmazonEKSNodegroup-json) in the AWS Managed Policy Reference Guide.
## AWS managed policy: AmazonEKSDashboardServiceRolePolicy
You can’t attach `AmazonEKSDashboardServiceRolePolicy` to your IAM entities. This policy is attached to a service-linked role that allows Amazon EKS to perform actions on your behalf. For more information, see [Service-linked role permissions for Amazon EKS](using-service-linked-roles-eks-dashboard.md#service-linked-role-permissions-eks-dashboard).
This policy grants the `AWSServiceRoleForAmazonEKSDashboard` role permissions that allow it to create and manage Amazon EC2 node groups in your account.
**Permissions details**
This policy includes the following permissions that allow access to complete these tasks:
+ ** `organizations` ** – View information about your AWS Organizations structure and accounts. This includes permissions to list accounts in your organization, view organizational units and roots, list delegated administrators, view services that have access to your organization, and retrieve detailed information about your organization and accounts.
To view the latest version of the JSON policy document, see [AmazonEKSDashboardServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSDashboardServiceRolePolicy.html#AmazonEKSDashboardServiceRolePolicy-json) in the AWS Managed Policy Reference Guide.
## AWS managed policy: AmazonEBSCSIDriverPolicy
**Important**
Two new AWS-managed IAM policies are available that provide more restrictive permission scoping: [AmazonEBSCSIDriverPolicyV2](#security-iam-awsmanpol-amazonebscsidriverpolicyv2) for tag-based scoping, or [AmazonEBSCSIDriverEKSClusterScopedPolicy](#security-iam-awsmanpol-amazonebscsidrivereksclusterscopedpolicy) for cluster-scoped isolation. If interested in migrating, see [EBS CSI Driver policy migration](https://github.com/kubernetes-sigs/aws-ebs-csi-driver/issues/2918).
The `AmazonEBSCSIDriverPolicy` policy allows the Amazon EBS Container Storage Interface (CSI) driver to create, modify, copy, attach, detach, and delete volumes on your behalf. This includes modifying tags on existing volumes and enabling Fast Snapshot Restore (FSR) on EBS volumes. It also grants the EBS CSI driver permissions to create, lock, restore, and delete snapshots, and to list your instances, volumes, and snapshots.
To view the latest version of the JSON policy document, see [AmazonEBSCSIDriverServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEBSCSIDriverPolicy.html#AmazonEBSCSIDriverPolicy-json) in the AWS Managed Policy Reference Guide.
## AWS managed policy: AmazonEBSCSIDriverPolicyV2
The `AmazonEBSCSIDriverPolicyV2` policy is a more restrictive alternative to `AmazonEBSCSIDriverPolicy`. It limits the Amazon EBS CSI driver to only managing EBS volumes and snapshots that are tagged with the key `ebs.csi.aws.com/cluster` set to `true`. Volumes provisioned by the in-tree Kubernetes volume plugin (CSI-migrated volumes) are also supported through the `kubernetes.io/created-for/pvc/name` resource tag.
If migrating from `AmazonEBSCSIDriverPolicy`, please see [EBS CSI Driver policy migration](https://github.com/kubernetes-sigs/aws-ebs-csi-driver/issues/2918).
To view the latest version of the JSON policy document, see [AmazonEBSCSIDriverPolicyV2](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEBSCSIDriverPolicyV2.html#AmazonEBSCSIDriverPolicyV2-json) in the AWS Managed Policy Reference Guide.
## AWS managed policy: AmazonEBSCSIDriverEKSClusterScopedPolicy
The `AmazonEBSCSIDriverEKSClusterScopedPolicy` policy restricts the Amazon EBS CSI driver to only managing EBS volumes and snapshots that belong to a specific EKS cluster. It requires the resource tag `ebs.csi.aws.com/cluster-name` to match the `eks-cluster-name` tag on the IAM principal, preventing cross-cluster access when multiple clusters share the same AWS account. Attach and detach operations on instances are restricted to instances tagged with either the `eks:cluster-name` tag (set automatically by EKS on managed node groups) or the `ebs.csi.aws.com/cluster-name` tag (for manually tagged instances).
If migrating from `AmazonEBSCSIDriverPolicy`, please see [EBS CSI Driver policy migration](https://github.com/kubernetes-sigs/aws-ebs-csi-driver/issues/2918).
To view the latest version of the JSON policy document, see [AmazonEBSCSIDriverEKSClusterScopedPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEBSCSIDriverEKSClusterScopedPolicy.html#AmazonEBSCSIDriverEKSClusterScopedPolicy-json) in the AWS Managed Policy Reference Guide.
## AWS managed policy: AmazonEFSCSIDriverPolicy
The `AmazonEFSCSIDriverPolicy` policy allows the Amazon EFS Container Storage Interface (CSI) to create and delete access points on your behalf. It also grants the Amazon EFS CSI driver permissions to list your access points, file systems, mount targets, and Amazon EC2 availability zones.
To view the latest version of the JSON policy document, see [AmazonEFSCSIDriverPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEFSCSIDriverPolicy.html#AmazonEFSCSIDriverPolicy-json) in the AWS Managed Policy Reference Guide.
## AWS managed policy: AmazonS3FilesCSIDriverPolicy
The `AmazonS3FilesCSIDriverPolicy` policy allows the Amazon EFS Container Storage Interface (CSI) to create and delete Amazon S3 Files access points on your behalf. It also grants the Amazon EFS CSI driver permissions to list your Amazon S3 Files access points and file systems.
To view the latest version of the JSON policy document, see [AmazonS3FilesCSIDriverPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonS3FilesCSIDriverPolicy.html#AmazonS3FilesCSIDriverPolicy-json) in the AWS Managed Policy Reference Guide.
## AWS managed policy: AmazonEKSLocalOutpostClusterPolicy
You can attach this policy to IAM entities. Before creating a local cluster, you must attach this policy to your [cluster role](cluster-iam-role.md). Kubernetes clusters that are managed by Amazon EKS make calls to other AWS services on your behalf. They do this to manage the resources that you use with the service.
The `AmazonEKSLocalOutpostClusterPolicy` includes the following permissions:
+ ** `ec2` read actions** – Allows control plane instances to describe Availability Zone, route table, instance, and network interface properties. Required permissions for Amazon EC2 instances to successfully join the cluster as control plane instances.
+ ** `ssm` ** – Allows Amazon EC2 Systems Manager connection to the control plane instance, which is used by Amazon EKS to communicate and manage the local cluster in your account.
+ ** `logs` ** – Allows instances to push logs to Amazon CloudWatch.
+ ** `secretsmanager` ** – Allows instances to get and delete bootstrap data for the control plane instances securely from AWS Secrets Manager.
+ ** `ecr` ** – Allows Pods and containers that are running on the control plane instances to pull container images that are stored in Amazon Elastic Container Registry.
To view the latest version of the JSON policy document, see [AmazonEKSLocalOutpostClusterPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSLocalOutpostClusterPolicy.html#AmazonEKSLocalOutpostClusterPolicy-json) in the AWS Managed Policy Reference Guide.
## AWS managed policy: AmazonEKSLocalOutpostServiceRolePolicy
You can’t attach this policy to your IAM entities. When you create a cluster using an IAM principal that has the `iam:CreateServiceLinkedRole` permission, Amazon EKS automatically creates the [AWSServiceRoleforAmazonEKSLocalOutpost](using-service-linked-roles-eks-outpost.md) service-linked role for you and attaches this policy to it. This policy allows the service-linked role to call AWS services on your behalf for local clusters.
The `AmazonEKSLocalOutpostServiceRolePolicy` includes the following permissions:
+ ** `ec2` ** – Allows Amazon EKS to work with security, network, and other resources to successfully launch and manage control plane instances in your account.
+ ** `ssm`, `ssmmessages` ** – Allows Amazon EC2 Systems Manager connection to the control plane instances, which is used by Amazon EKS to communicate and manage the local cluster in your account.
+ ** `iam` ** – Allows Amazon EKS to manage the instance profile associated with the control plane instances.
+ ** `secretsmanager` ** - Allows Amazon EKS to put bootstrap data for the control plane instances into AWS Secrets Manager so it can be securely referenced during instance bootstrapping.
+ ** `outposts` ** – Allows Amazon EKS to get Outpost information from your account to successfully launch a local cluster in an Outpost.
To view the latest version of the JSON policy document, see [AmazonEKSLocalOutpostServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSLocalOutpostServiceRolePolicy.html#AmazonEKSLocalOutpostServiceRolePolicy-json) in the AWS Managed Policy Reference Guide.
## Amazon EKS updates to AWS managed policies
View details about updates to AWS managed policies for Amazon EKS since this service began tracking these changes.
To receive notifications of all source file changes to this specific documentation page, you can subscribe to the following URL with an RSS reader:
```
https://github.com/awsdocs/amazon-eks-user-guide/commits/mainline/latest/ug/security/iam-reference/security-iam-awsmanpol.adoc.atom
```
| Change | Description | Date |
| --- | --- | --- |
| Introduced [AmazonEBSCSIDriverPolicyV2](#security-iam-awsmanpol-amazonebscsidriverpolicyv2) and [AmazonEBSCSIDriverEKSClusterScopedPolicy](#security-iam-awsmanpol-amazonebscsidrivereksclusterscopedpolicy). | Introduced `AmazonEBSCSIDriverPolicyV2` and `AmazonEBSCSIDriverEKSClusterScopedPolicy` as more restrictive alternatives to `AmazonEBSCSIDriverPolicy`. `AmazonEBSCSIDriverPolicyV2` scopes the EBS CSI driver to volumes and snapshots tagged with `ebs.csi.aws.com/cluster` set to `true`. `AmazonEBSCSIDriverEKSClusterScopedPolicy` scopes the driver to volumes and snapshots belonging to a specific EKS cluster using the `ebs.csi.aws.com/cluster-name` tag. | April 16, 2026 |
| Updated permissions to [AWS managed policy: AmazonEKSLoadBalancingPolicy](#security-iam-awsmanpol-AmazonEKSLoadBalancingPolicy). | Updated `shield:CreateProtection`, `shield:DeleteProtection` permission in `AmazonEKSLoadBalancingPolicy`. This allows Amazon EKS Auto Mode Controller to add shield protection. | April 14, 2026 |
| Added permissions to [AWS managed policy: AmazonEKSLoadBalancingPolicy](#security-iam-awsmanpol-AmazonEKSLoadBalancingPolicy). | Updated `elasticloadbalancing:RegisterTargets` permission in `AmazonEKSLoadBalancingPolicy` to add support for multi-cluster and custom targetgroupbindings | March 20, 2026 |
| Added permissions to [AWS managed policy: AmazonEKSLoadBalancingPolicy](#security-iam-awsmanpol-AmazonEKSLoadBalancingPolicy). | Added `elasticloadbalancing:ModifyIpPools` permission in `AmazonEKSLoadBalancingPolicy` to add support for setting IPAM pool for ALB | March 20, 2026 |
| Added permission to [AWS managed policy: AmazonEKSNetworkingPolicy](#security-iam-awsmanpol-AmazonEKSNetworkingPolicy). | Added `ec2:ModifyNetworkInterfaceAttribute` permission in `AmazonEKSNetworkingPolicy`. This allows Amazon EKS Auto Mode Controller to modify network interface attributes related to EC2 instances | Feb 3, 2026 |
| Added permissions to [AWS managed policy: AWSServiceRoleForAmazonEKSNodegroup](#security-iam-awsmanpol-awsserviceroleforamazoneksnodegroup). | Added `autoscaling:PutWarmPool`, `autoscaling:DeleteWarmPool`, and `autoscaling:DescribeWarmPool` permissions to `AWSServiceRoleForAmazonEKSNodegroup`. This allows Amazon EKS Managed Nodegroups to manage underlying ASG warm pool resources throughout the node group lifecycle. | February 17, 2026 |
| Added permission to [AWS managed policy: AmazonEKSServiceRolePolicy](#security-iam-awsmanpol-amazoneksservicerolepolicy). | Removed the "eks" prefix requirement in the name of the target instance profile for the `iam:GetInstanceProfile` permission in `AmazonEKSServiceRolePolicy`. This allows Amazon EKS Auto Mode to validate and utilize custom instance profiles in NodeClasses without requiring the "eks" naming prefix. | Feb 2, 2026 |
| Added permissions to [AmazonEBSCSIDriverPolicy](#security-iam-awsmanpol-amazonebscsidriverservicerolepolicy). | Added `ec2:LockSnapshot` permission to allow the EBS CSI Driver to lock EBS Snapshots directly. | January 15, 2026 |
| Introduced [AWS managed policy: AmazonEKSMCPReadOnlyAccess](#security-iam-awsmanpol-amazoneksmcpreadonlyaccess). | Amazon EKS introduced new managed policy `AmazonEKSMCPReadOnlyAccess` to enable read-only tools in the Amazon EKS MCP Server for observability and troubleshooting. | November 21, 2025 |
| Added permissions to [AmazonEBSCSIDriverPolicy](#security-iam-awsmanpol-amazonebscsidriverservicerolepolicy). | Added `ec2:CopyVolumes` permission to allow the EBS CSI Driver to copy EBS volumes directly. | November 17, 2025 |
| Added permission to [AWS managed policy: AmazonEKSServiceRolePolicy](#security-iam-awsmanpol-amazoneksservicerolepolicy). | Added `ec2:DescribeRouteTables` and `ec2:DescribeNetworkAcls` permissions to `AmazonEKSServiceRolePolicy`. This allows Amazon EKS to detect configuration issues with VPC route tables and network ACLs for hybrid nodes as part of cluster insights. | Oct 22, 2025 |
| Added permission to [AWSServiceRoleForAmazonEKSConnector](using-service-linked-roles-eks-connector.md) | Added `ssmmessages:OpenDataChannel` permission to `AmazonEKSConnectorServiceRolePolicy` | October 15, 2025 |
| Added permission to [AWS managed policy: AmazonEKSServiceRolePolicy](#security-iam-awsmanpol-amazoneksservicerolepolicy) | This role can attach new access policy `AmazonEKSEventPolicy`. Restricted permissions for `ec2:DeleteLaunchTemplate` and `ec2:TerminateInstances`. | August 26, 2025 |
| Added permission to [AWS managed policy: AmazonEKSLocalOutpostServiceRolePolicy](#security-iam-awsmanpol-amazonekslocaloutpostservicerolepolicy) | Added `ssmmessages:OpenDataChannel` permission to `AmazonEKSLocalOutpostServiceRolePolicy`. | June 26, 2025 |
| Added permission to [AWS managed policy: AmazonEKSComputePolicy](#security-iam-awsmanpol-AmazonEKSComputePolicy). | Updated resource permissions for the `ec2:RunInstances` and `ec2:CreateFleet` actions to include capacity reservations ` arn:aws:ec2:*:*:capacity-reservation/*`. This allows Amazon EKS Auto Mode to launch instances by using the EC2 On-Demand Capacity Reservations in your account. Added `iam:CreateServiceLinkedRole` to allow Amazon EKS Auto Mode to create the EC2 Spot service-linked role `AWSServiceRoleForEC2Spot` on your behalf. | June 20, 2025 |
| Added permission to [AmazonEKSServiceRolePolicy](#security-iam-awsmanpol-amazoneksservicerolepolicy). | Added `ec2:DescribeCapacityReservations` permission to allow Amazon EKS Auto Mode to launch instances by using the EC2 On-Demand Capacity Reservations in your account. | June 20, 2025 |
| Introduced [AWS managed policy: AmazonEKSDashboardConsoleReadOnly](#security-iam-awsmanpol-amazoneksdashboardconsolereadonly). | Introduced new `AmazonEKSDashboardConsoleReadOnly` policy. | June 19, 2025 |
| Introduced [AWS managed policy: AmazonEKSDashboardServiceRolePolicy](#security-iam-awsmanpol-AmazonEKSDashboardServiceRolePolicy). | Introduced new `AmazonEKSDashboardServiceRolePolicy` policy. | May 21, 2025 |
| Added permissions to [AmazonEKSClusterPolicy](#security-iam-awsmanpol-amazoneksclusterpolicy). | Added `ec2:DeleteNetworkInterfaces` permission to allow Amazon EKS to delete elastic network interfaces that are left behind if the VPC CNI quits unexpectedly. | April 16, 2025 |
| Added permission to [AmazonEKSServiceRolePolicy](#security-iam-awsmanpol-amazoneksservicerolepolicy). | Added `ec2:RevokeSecurityGroupEgress` and `ec2:AuthorizeSecurityGroupEgress` permissions to allow EKS AI/ML customers to add Security Group Egress rules to the default EKS Cluster SG that are compatible with EFA, as part of the EKS 1.33 version release. | April 14, 2025 |
| Added permissions to [AmazonEKSServiceRolePolicy](#security-iam-awsmanpol-amazoneksservicerolepolicy). | Added permission to terminate EC2 instances created by EKS Auto Mode. | February 28, 2025 |
| Added permissions to [AmazonEBSCSIDriverPolicy](#security-iam-awsmanpol-amazonebscsidriverservicerolepolicy). | Added a new statement authorizing the EBS CSI Driver to restore all snapshots. This was previously allowed by the existing policy but a new explicit statement is required due to a change in the handling of IAM for `CreateVolume`. Added the ability for the EBS CSI Driver to modify tags on existing volumes. The EBS CSI Driver can modify tags of existing volumes via a parameters in Kubernetes VolumeAttributesClasses. Added the ability for the EBS CSI Driver to enable Fast Snapshot Restore (FSR) on EBS volumes. The EBS CSI Driver can enable FSR on new volumes via parameters in Kubernetes storage classes. | January 13, 2025 |
| Added permissions to [AWS managed policy: AmazonEKSLoadBalancingPolicy](#security-iam-awsmanpol-AmazonEKSLoadBalancingPolicy). | Updated `AmazonEKSLoadBalancingPolicy` to allow listing and describing networking and IP address resources. | December 26, 2024 |
| Added permissions to [AWS managed policy: AWSServiceRoleForAmazonEKSNodegroup](#security-iam-awsmanpol-awsserviceroleforamazoneksnodegroup). | Updated `AWSServiceRoleForAmazonEKSNodegroup` for compatibility with China regions. | November 22, 2024 |
| Added permissions to [AWS managed policy: AmazonEKSLocalOutpostClusterPolicy](#security-iam-awsmanpol-amazonekslocaloutpostclusterpolicy) | Added `ec2:DescribeAvailabilityZones` permission to `AmazonEKSLocalOutpostClusterPolicy` so the AWS Cloud Controller Manager on the cluster control plane can identify the Availability Zone that each node is in. | November 21, 2024 |
| Added permissions to [AWS managed policy: AWSServiceRoleForAmazonEKSNodegroup](#security-iam-awsmanpol-awsserviceroleforamazoneksnodegroup). | Updated `AWSServiceRoleForAmazonEKSNodegroup` policy to allow `ec2:RebootInstances` for instances created by Amazon EKS managed node groups. Restricted the `ec2:CreateTags` permissions for Amazon EC2 resources. | November 20, 2024 |
| Added permissions to [AWS managed policy: AmazonEKSServiceRolePolicy](#security-iam-awsmanpol-amazoneksservicerolepolicy). | EKS updated AWS managed policy `AmazonEKSServiceRolePolicy`. Added permissions for EKS access policies, load balancer management, and automated cluster resource cleanup. | November 16, 2024 |
| Introduced [AWS managed policy: AmazonEKSComputePolicy](#security-iam-awsmanpol-AmazonEKSComputePolicy). | EKS updated AWS managed policy `AmazonEKSComputePolicy`. Updated resource permissions for the `iam:AddRoleToInstanceProfile` action. | November 7, 2024 |
| Introduced [AWS managed policy: AmazonEKSComputePolicy](#security-iam-awsmanpol-AmazonEKSComputePolicy). | AWS introduced the `AmazonEKSComputePolicy`. | November 1, 2024 |
| Added permissions to `AmazonEKSClusterPolicy` | Added `ec2:DescribeInstanceTopology` permission to allow Amazon EKS to attach topology information to the node as labels. | November 1, 2024 |
| Introduced [AWS managed policy: AmazonEKSBlockStoragePolicy](#security-iam-awsmanpol-AmazonEKSBlockStoragePolicy). | AWS introduced the `AmazonEKSBlockStoragePolicy`. | October 30, 2024 |
| Introduced [AWS managed policy: AmazonEKSLoadBalancingPolicy](#security-iam-awsmanpol-AmazonEKSLoadBalancingPolicy). | AWS introduced the `AmazonEKSLoadBalancingPolicy`. | October 30, 2024 |
| Added permissions to [AmazonEKSServiceRolePolicy](#security-iam-awsmanpol-amazoneksservicerolepolicy). | Added `cloudwatch:PutMetricData` permissions to allow Amazon EKS to publish metrics to Amazon CloudWatch. | October 29, 2024 |
| Introduced [AWS managed policy: AmazonEKSNetworkingPolicy](#security-iam-awsmanpol-AmazonEKSNetworkingPolicy). | AWS introduced the `AmazonEKSNetworkingPolicy`. | October 28, 2024 |
| Added permissions to `AmazonEKSServicePolicy` and `AmazonEKSServiceRolePolicy` | Added `ec2:GetSecurityGroupsForVpc` and associated tag permissions to allow EKS to read security group information and update related tags. | October 10, 2024 |
| Introduced [AmazonEKSWorkerNodeMinimalPolicy](#security-iam-awsmanpol-AmazonEKSWorkerNodeMinimalPolicy). | AWS introduced the `AmazonEKSWorkerNodeMinimalPolicy`. | October 3, 2024 |
| Added permissions to [AWSServiceRoleForAmazonEKSNodegroup](#security-iam-awsmanpol-awsserviceroleforamazoneksnodegroup). | Added `autoscaling:ResumeProcesses` and `autoscaling:SuspendProcesses` permissions to allow Amazon EKS to suspend and resume `AZRebalance` in Amazon EKS-managed Auto Scaling groups. | August 21, 2024 |
| Added permissions to [AWSServiceRoleForAmazonEKSNodegroup](#security-iam-awsmanpol-awsserviceroleforamazoneksnodegroup). | Added `ec2:DescribeCapacityReservations` permission to allow Amazon EKS to describe capacity reservation in user’s account. Added `autoscaling:PutScheduledUpdateGroupAction` permission to enable setting scheduled scaling on `CAPACITY_BLOCK` node groups. | June 27, 2024 |
| [AmazonEKS\$1CNI\$1Policy](#security-iam-awsmanpol-amazoneks-cni-policy) – Update to an existing policy | Amazon EKS added new `ec2:DescribeSubnets` permissions to allow the Amazon VPC CNI plugin for Kubernetes to see the amount of free IP addresses in your Amazon VPC subnets. The VPC CNI can use the free IP addresses in each subnet to pick the subnets with the most free IP addresses to use when creating an elastic network interface. | March 4, 2024 |
| [AmazonEKSWorkerNodePolicy](#security-iam-awsmanpol-amazoneksworkernodepolicy) – Update to an existing policy | Amazon EKS added new permissions to allow EKS Pod Identities. The Amazon EKS Pod Identity Agent uses the node role. | November 26, 2023 |
| Introduced [AmazonEFSCSIDriverPolicy](#security-iam-awsmanpol-amazonefscsidriverservicerolepolicy). | AWS introduced the `AmazonEFSCSIDriverPolicy`. | July 26, 2023 |
| Added permissions to [AmazonEKSClusterPolicy](#security-iam-awsmanpol-amazoneksclusterpolicy). | Added `ec2:DescribeAvailabilityZones` permission to allow Amazon EKS to get the AZ details during subnet auto-discovery while creating load balancers. | February 7, 2023 |
| Updated policy conditions in [AmazonEBSCSIDriverPolicy](#security-iam-awsmanpol-amazonebscsidriverservicerolepolicy). | Removed invalid policy conditions with wildcard characters in the `StringLike` key field. Also added a new condition `ec2:ResourceTag/kubernetes.io/created-for/pvc/name: "*"` to `ec2:DeleteVolume`, which allows the EBS CSI driver to delete volumes created by the in-tree plugin. | November 17, 2022 |
| Added permissions to [AmazonEKSLocalOutpostServiceRolePolicy](#security-iam-awsmanpol-amazonekslocaloutpostservicerolepolicy). | Added `ec2:DescribeVPCAttribute`, `ec2:GetConsoleOutput` and `ec2:DescribeSecret` to allow better prerequisite validation and managed lifecycle control. Also added `ec2:DescribePlacementGroups` and `"arn:aws:ec2:*:*:placement-group/*"` to `ec2:RunInstances` to support placement control of the control plane Amazon EC2 instances on Outposts. | October 24, 2022 |
| Update Amazon Elastic Container Registry permissions in [AmazonEKSLocalOutpostClusterPolicy](#security-iam-awsmanpol-amazonekslocaloutpostclusterpolicy). | Moved action `ecr:GetDownloadUrlForLayer` from all resource sections to a scoped section. Added resource ` arn:aws:ecr:*:*:repository/eks/ `. Removed resource ` arn:aws:ecr:`. This resource is covered by the added ` arn:aws:ecr:*:*:repository/eks/*` resource. | October 20, 2022 |
| Added permissions to [AmazonEKSLocalOutpostClusterPolicy](#security-iam-awsmanpol-amazonekslocaloutpostclusterpolicy). | Added the ` arn:aws:ecr:*:*:repository/kubelet-config-updater` Amazon Elastic Container Registry repository so the cluster control plane instances can update some `kubelet` arguments. | August 31, 2022 |
| Introduced [AmazonEKSLocalOutpostClusterPolicy](#security-iam-awsmanpol-amazonekslocaloutpostclusterpolicy). | AWS introduced the `AmazonEKSLocalOutpostClusterPolicy`. | August 24, 2022 |
| Introduced [AmazonEKSLocalOutpostServiceRolePolicy](#security-iam-awsmanpol-amazonekslocaloutpostservicerolepolicy). | AWS introduced the `AmazonEKSLocalOutpostServiceRolePolicy`. | August 23, 2022 |
| Introduced [AmazonEBSCSIDriverPolicy](#security-iam-awsmanpol-amazonebscsidriverservicerolepolicy). | AWS introduced the `AmazonEBSCSIDriverPolicy`. | April 4, 2022 |
| Added permissions to [AmazonEKSWorkerNodePolicy](#security-iam-awsmanpol-amazoneksworkernodepolicy). | Added `ec2:DescribeInstanceTypes` to enable Amazon EKS-optimized AMIs that can auto discover instance level properties. | March 21, 2022 |
| Added permissions to [AWSServiceRoleForAmazonEKSNodegroup](#security-iam-awsmanpol-awsserviceroleforamazoneksnodegroup). | Added `autoscaling:EnableMetricsCollection` permission to allow Amazon EKS to enable metrics collection. | December 13, 2021 |
| Added permissions to [AmazonEKSClusterPolicy](#security-iam-awsmanpol-amazoneksclusterpolicy). | Added `ec2:DescribeAccountAttributes`, `ec2:DescribeAddresses`, and `ec2:DescribeInternetGateways` permissions to allow Amazon EKS to create a service-linked role for a Network Load Balancer. | June 17, 2021 |
| Amazon EKS started tracking changes. | Amazon EKS started tracking changes for its AWS managed policies. | June 17, 2021 |
# Troubleshooting IAM
This topic covers some common errors that you may see while using Amazon EKS with IAM and how to work around them.
## AccessDeniedException
If you receive an `AccessDeniedException` when calling an AWS API operation, then the [IAM principal](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) credentials that you’re using don’t have the required permissions to make that call.
```
An error occurred (AccessDeniedException) when calling the DescribeCluster operation:
User: arn:aws:iam::111122223333:user/user_name is not authorized to perform:
eks:DescribeCluster on resource: arn:aws:eks:region:111122223333:cluster/my-cluster
```
In the previous example message, the user does not have permissions to call the Amazon EKS `DescribeCluster` API operation. To provide Amazon EKS admin permissions to an IAM principal, see [Amazon EKS identity-based policy examples](security-iam-id-based-policy-examples.md).
For more general information about IAM, see [Controlling access using policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_controlling.html) in the *IAM User Guide*.
## Can’t see **Nodes** on the **Compute** tab or anything on the **Resources** tab and you receive an error in the AWS Management Console
You may see a console error message that says `Your current user or role does not have access to Kubernetes objects on this EKS cluster`. Make sure that the [IAM principal](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) user that you’re using the AWS Management Console with has the necessary permissions. For more information, see [Required permissions](view-kubernetes-resources.md#view-kubernetes-resources-permissions).
## aws-auth `ConfigMap` does not grant access to the cluster
The [AWS IAM Authenticator](https://github.com/kubernetes-sigs/aws-iam-authenticator) doesn’t permit a path in the role ARN used in the `ConfigMap`. Therefore, before you specify `rolearn`, remove the path. For example, change ` arn:aws:iam::111122223333:role/team/developers/eks-admin ` to ` arn:aws:iam::111122223333:role/eks-admin `.
## I am not authorized to perform iam:PassRole
If you receive an error that you’re not authorized to perform the `iam:PassRole` action, your policies must be updated to allow you to pass a role to Amazon EKS.
Some AWS services allow you to pass an existing role to that service instead of creating a new service role or service-linked role. To do this, you must have permissions to pass the role to the service.
The following example error occurs when an IAM user named `marymajor` tries to use the console to perform an action in Amazon EKS. However, the action requires the service to have permissions that are granted by a service role. Mary does not have permissions to pass the role to the service.
```
User: {arn-aws}iam::123456789012:user/marymajor is not authorized to perform: iam:PassRole
```
In this case, Mary’s policies must be updated to allow her to perform the `iam:PassRole` action.
If you need help, contact your AWS administrator. Your administrator is the person who provided you with your sign-in credentials.
## I want to allow people outside of my AWS account to access my Amazon EKS resources
You can create a role that users in other accounts or people outside of your organization can use to access your resources. You can specify who is trusted to assume the role. For services that support resource-based policies or access control lists (ACLs), you can use those policies to grant people access to your resources.
To learn more, consult the following:
+ To learn whether Amazon EKS supports these features, see [How Amazon EKS works with IAM](security-iam-service-with-iam.md).
+ To learn how to provide access to your resources across AWS accounts that you own, see [Providing access to an IAM user in another AWS account that you own](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html) in the *IAM User Guide*.
+ To learn how to provide access to your resources to third-party AWS accounts, see [Providing access to AWS accounts owned by third parties](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html) in the *IAM User Guide*.
+ To learn how to provide access through identity federation, see [Providing access to externally authenticated users (identity federation)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_federated-users.html) in the *IAM User Guide*.
+ To learn the difference between using roles and resource-based policies for cross-account access, see [Cross account resource access in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) in the *IAM User Guide*.
## Pod containers receive the following error: `An error occurred (SignatureDoesNotMatch) when calling the GetCallerIdentity operation: Credential should be scoped to a valid region`
Your containers receive this error if your application is explicitly making requests to the AWS STS global endpoint (`https://sts.amazonaws.com`) and your Kubernetes service account is configured to use a regional endpoint. You can resolve the issue with one of the following options:
+ Update your application code to remove explicit calls to the AWS STS global endpoint.
+ Update your application code to make explicit calls to regional endpoints such as `https://sts.us-west-2.amazonaws.com`. Your application should have redundancy built in to pick a different AWS Region in the event of a failure of the service in the AWS Region. For more information, see [Managing AWS STS in an AWS Region](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_enable-regions.html) in the IAM User Guide.
+ Configure your service accounts to use the global endpoint. Clusters use the regional endpoint by default. For more information, see [Configure the AWS Security Token Service endpoint for a service account](configure-sts-endpoint.md).
# Amazon EKS cluster IAM role
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.
Before you can create Amazon EKS clusters, you must create an IAM role with either of the following IAM policies:
+ [AmazonEKSClusterPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSClusterPolicy.html)
+ A custom IAM policy. The minimal permissions that follow allows the Kubernetes cluster to manage nodes, but doesn’t allow the [legacy Cloud Provider](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/guide/service/annotations/#legacy-cloud-provider) to create load balancers with Elastic Load Balancing. Your custom IAM policy must have at least the following permissions:
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:CreateTags"
],
"Resource": "arn:aws:ec2:*:*:instance/*",
"Condition": {
"ForAnyValue:StringLike": {
"aws:TagKeys": "kubernetes.io/cluster/*"
}
}
},
{
"Effect": "Allow",
"Action": [
"ec2:DescribeInstances",
"ec2:DescribeNetworkInterfaces",
"ec2:DescribeVpcs",
"ec2:DescribeDhcpOptions",
"ec2:DescribeAvailabilityZones",
"ec2:DescribeInstanceTopology",
"kms:DescribeKey"
],
"Resource": "*"
}
]
}
```
**Note**
Prior to October 3, 2023, [AmazonEKSClusterPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSClusterPolicy.html) was required on the IAM role for each cluster.
Prior to April 16, 2020, [AmazonEKSServicePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSServicePolicy.html) and [AmazonEKSClusterPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSClusterPolicy.html) was required and the suggested name for the role was `eksServiceRole`. With the `AWSServiceRoleForAmazonEKS` service-linked role, the [AmazonEKSServicePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSServicePolicy.html) policy is no longer required for clusters created on or after April 16, 2020.
## Check for an existing cluster role
You can use the following procedure to check and see if your account already has the Amazon EKS cluster role.
1. Open the IAM console at https://console.aws.amazon.com/iam/.
1. In the left navigation pane, choose **Roles**.
1. Search the list of roles for `eksClusterRole`. If a role that includes `eksClusterRole` doesn’t exist, then see [Creating the Amazon EKS cluster role](#create-service-role) to create the role. If a role that includes `eksClusterRole` does exist, then select the role to view the attached policies.
1. Choose **Permissions**.
1. Ensure that the **AmazonEKSClusterPolicy** managed policy is attached to the role. If the policy is attached, your Amazon EKS cluster role is properly configured.
1. Choose **Trust relationships**, and then choose **Edit trust policy**.
1. Verify that the trust relationship contains the following policy. If the trust relationship matches the following policy, choose **Cancel**. If the trust relationship doesn’t match, copy the policy into the **Edit trust policy** window and choose **Update policy**.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "eks.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
## Creating the Amazon EKS cluster role
You can use the AWS Management Console or the AWS CLI to create the cluster role.
AWS Management Console
1. Open the IAM console at https://console.aws.amazon.com/iam/.
1. Choose **Roles**, then **Create role**.
1. Under **Trusted entity type**, select ** AWS service**.
1. From the **Use cases for other AWS services** dropdown list, choose **EKS**.
1. Choose **EKS - Cluster** for your use case, and then choose **Next**.
1. On the **Add permissions** tab, choose **Next**.
1. For **Role name**, enter a unique name for your role, such as `eksClusterRole`.
1. For **Description**, enter descriptive text such as `Amazon EKS - Cluster role`.
1. Choose **Create role**.
AWS CLI
1. Copy the following contents to a file named *cluster-trust-policy.json*.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "eks.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
1. Create the role. You can replace *eksClusterRole* with any name that you choose.
```
aws iam create-role \
--role-name eksClusterRole \
--assume-role-policy-document file://"cluster-trust-policy.json"
```
1. Attach the required IAM policy to the role.
```
aws iam attach-role-policy \
--policy-arn arn:aws:iam::aws:policy/AmazonEKSClusterPolicy \
--role-name eksClusterRole
```
# Amazon EKS node IAM role
The Amazon EKS node `kubelet` daemon makes calls to AWS APIs on your behalf. Nodes receive permissions for these API calls through an IAM instance profile and associated policies. Before you can launch nodes and register them into a cluster, you must create an IAM role for those nodes to use when they are launched. This requirement applies to nodes launched with the Amazon EKS optimized AMI provided by Amazon, or with any other node AMIs that you intend to use. Additionally, this requirement applies to both managed node groups and self-managed nodes.
**Note**
You can’t use the same role that is used to create any clusters.
Before you create nodes, you must create an IAM role with the following permissions:
+ Permissions for the `kubelet` to describe Amazon EC2 resources in the VPC, such as provided by the [AmazonEKSWorkerNodePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSWorkerNodePolicy.html) policy. This policy also provides the permissions for the Amazon EKS Pod Identity Agent.
+ Permissions for the `kubelet` to use container images from Amazon Elastic Container Registry (Amazon ECR), such as provided by the [AmazonEC2ContainerRegistryPullOnly](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEC2ContainerRegistryPullOnly.html) policy. The permissions to use container images from Amazon Elastic Container Registry (Amazon ECR) are required because the built-in add-ons for networking run pods that use container images from Amazon ECR.
+ (Optional) Permissions for the Amazon EKS Pod Identity Agent to use the `eks-auth:AssumeRoleForPodIdentity` action to retrieve credentials for pods. If you don’t use the [AmazonEKSWorkerNodePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSWorkerNodePolicy.html), then you must provide this permission in addition to the EC2 permissions to use EKS Pod Identity.
+ (Optional) If you don’t use IRSA or EKS Pod Identity to give permissions to the VPC CNI pods, then you must provide permissions for the VPC CNI on the instance role. You can use either the [https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKS_CNI_Policy.html](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKS_CNI_Policy.html) managed policy (if you created your cluster with the `IPv4` family) or an [IPv6 policy that you create](cni-iam-role.md#cni-iam-role-create-ipv6-policy) (if you created your cluster with the `IPv6` family). Rather than attaching the policy to this role however, we recommend that you attach the policy to a separate role used specifically for the Amazon VPC CNI add-on. For more information about creating a separate role for the Amazon VPC CNI add-on, see [Configure Amazon VPC CNI plugin to use IRSA](cni-iam-role.md).
+ (Optional) Permissions for the `kubelet` to use container images from Amazon ECR Public (public.ecr.aws), such as provided by the [AmazonElasticContainerRegistryPublicReadOnly](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonElasticContainerRegistryPublicReadOnly.html) policy. These permissions are recommended if you pull container images from ECR Public. Without them, the pulls will succeed, but may be rate-limited.
**Note**
The Amazon EC2 node groups must have a different IAM role than the Fargate profile. For more information, see [Amazon EKS Pod execution IAM role](pod-execution-role.md).
## Check for an existing node role
You can use the following procedure to check and see if your account already has the Amazon EKS node role.
1. Open the IAM console at https://console.aws.amazon.com/iam/.
1. In the left navigation pane, choose **Roles**.
1. Search the list of roles for `eksNodeRole`, `AmazonEKSNodeRole`, or `NodeInstanceRole`. If a role with one of those names doesn’t exist, then see [Creating the Amazon EKS node IAM role](#create-worker-node-role) to create the role. If a role that contains `eksNodeRole`, `AmazonEKSNodeRole`, or `NodeInstanceRole` does exist, then select the role to view the attached policies.
1. Choose **Permissions**.
1. Ensure that the **AmazonEKSWorkerNodePolicy** and **AmazonEC2ContainerRegistryPullOnly** managed policies are attached to the role or a custom policy is attached with the minimal permissions.
**Note**
If the **AmazonEKS\$1CNI\$1Policy** policy is attached to the role, we recommend removing it and attaching it to an IAM role that is mapped to the `aws-node` Kubernetes service account instead. For more information, see [Configure Amazon VPC CNI plugin to use IRSA](cni-iam-role.md).
1. Choose **Trust relationships**, and then choose **Edit trust policy**.
1. Verify that the trust relationship contains the following policy. If the trust relationship matches the following policy, choose **Cancel**. If the trust relationship doesn’t match, copy the policy into the **Edit trust policy** window and choose **Update policy**.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"sts:AssumeRole"
],
"Principal": {
"Service": [
"ec2.amazonaws.com"
]
}
}
]
}
```
## Creating the Amazon EKS node IAM role
You can create the node IAM role with the AWS Management Console or the AWS CLI.
AWS Management Console
1. Open the IAM console at https://console.aws.amazon.com/iam/.
1. In the left navigation pane, choose **Roles**.
1. On the **Roles** page, choose **Create role**.
1. On the **Select trusted entity** page, do the following:
1. In the **Trusted entity type** section, choose ** AWS service**.
1. Under **Use case**, choose **EC2**.
1. Choose **Next**.
1. On the **Add permissions** page, attach a custom policy or do the following:
1. In the **Filter policies** box, enter `AmazonEKSWorkerNodePolicy`.
1. Select the check box to the left of **AmazonEKSWorkerNodePolicy** in the search results.
1. Choose **Clear filters**.
1. In the **Filter policies** box, enter `AmazonEC2ContainerRegistryPullOnly`.
1. Select the check box to the left of **AmazonEC2ContainerRegistryPullOnly** in the search results.
Either the **AmazonEKS\$1CNI\$1Policy** managed policy, or an [IPv6 policy](cni-iam-role.md#cni-iam-role-create-ipv6-policy) that you create must also be attached to either this role or to a different role that’s mapped to the `aws-node` Kubernetes service account. We recommend assigning the policy to the role associated to the Kubernetes service account instead of assigning it to this role. For more information, see [Configure Amazon VPC CNI plugin to use IRSA](cni-iam-role.md).
1. Choose **Next**.
1. On the **Name, review, and create** page, do the following:
1. For **Role name**, enter a unique name for your role, such as `AmazonEKSNodeRole`.
1. For **Description**, replace the current text with descriptive text such as `Amazon EKS - Node role`.
1. Under **Add tags (Optional)**, add metadata to the role by attaching tags as key-value pairs. For more information about using tags in IAM, see [Tagging IAM resources](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_tags.html) in the *IAM User Guide*.
1. Choose **Create role**.
AWS CLI
1. Run the following command to create the `node-role-trust-relationship.json` file.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"sts:AssumeRole"
],
"Principal": {
"Service": [
"ec2.amazonaws.com"
]
}
}
]
}
```
1. Create the IAM role.
```
aws iam create-role \
--role-name AmazonEKSNodeRole \
--assume-role-policy-document file://"node-role-trust-relationship.json"
```
1. Attach two required IAM managed policies to the IAM role.
```
aws iam attach-role-policy \
--policy-arn arn:aws:iam::aws:policy/AmazonEKSWorkerNodePolicy \
--role-name AmazonEKSNodeRole
aws iam attach-role-policy \
--policy-arn arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryPullOnly \
--role-name AmazonEKSNodeRole
```
1. Attach one of the following IAM policies to the IAM role depending on which IP family you created your cluster with. The policy must be attached to this role or to a role associated to the Kubernetes `aws-node` service account that’s used for the Amazon VPC CNI plugin for Kubernetes. We recommend assigning the policy to the role associated to the Kubernetes service account. To assign the policy to the role associated to the Kubernetes service account, see [Configure Amazon VPC CNI plugin to use IRSA](cni-iam-role.md).
+ IPv4
```
aws iam attach-role-policy \
--policy-arn arn:aws:iam::aws:policy/AmazonEKS_CNI_Policy \
--role-name AmazonEKSNodeRole
```
+ IPv6
1. Copy the following text and save it to a file named `vpc-cni-ipv6-policy.json`.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:AssignIpv6Addresses",
"ec2:DescribeInstances",
"ec2:DescribeTags",
"ec2:DescribeNetworkInterfaces",
"ec2:DescribeInstanceTypes"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ec2:CreateTags"
],
"Resource": [
"arn:aws:ec2:*:*:network-interface/*"
]
}
]
}
```
1. Create the IAM policy.
```
aws iam create-policy --policy-name AmazonEKS_CNI_IPv6_Policy --policy-document file://vpc-cni-ipv6-policy.json
```
1. Attach the IAM policy to the IAM role. Replace *111122223333* with your account ID.
```
aws iam attach-role-policy \
--policy-arn arn:aws:iam::111122223333:policy/AmazonEKS_CNI_IPv6_Policy \
--role-name AmazonEKSNodeRole
```
# Amazon EKS Auto Mode cluster IAM role
An Amazon EKS cluster IAM role is required for each cluster. Kubernetes clusters managed by Amazon EKS use this role to automate routine tasks for storage, networking, and compute autoscaling.
Before you can create Amazon EKS clusters, you must create an IAM role with the policies required for EKS Auto Mode. You can either attach the suggested AWS IAM managed policies, or create custom polices with equivalent permissions.
+ [AmazonEKSComputePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSComputePolicy)
+ [AmazonEKSBlockStoragePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSBlockStoragePolicy)
+ [AmazonEKSLoadBalancingPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSLoadBalancingPolicy)
+ [AmazonEKSNetworkingPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSNetworkingPolicy)
+ [AmazonEKSClusterPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-amazoneksclusterpolicy)
## Custom AWS tags for EKS Auto resources
By default, the managed policies related to EKS Auto Mode do not permit applying user defined tags to Auto Mode provisioned AWS resources. If you want to apply user defined tags to AWS resources, you must attach additional permissions to the Cluster IAM Role with sufficient permissions to create and modify tags on AWS resources. Below is an example of a policy that will allow unrestricted tagging access:
### View custom tag policy example
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "Compute",
"Effect": "Allow",
"Action": [
"ec2:CreateFleet",
"ec2:RunInstances",
"ec2:CreateLaunchTemplate"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:RequestTag/eks:eks-cluster-name": "${aws:PrincipalTag/eks:eks-cluster-name}"
},
"StringLike": {
"aws:RequestTag/eks:kubernetes-node-class-name": "*",
"aws:RequestTag/eks:kubernetes-node-pool-name": "*"
}
}
},
{
"Sid": "Storage",
"Effect": "Allow",
"Action": [
"ec2:CreateVolume",
"ec2:CreateSnapshot"
],
"Resource": [
"arn:aws:ec2:*:*:volume/*",
"arn:aws:ec2:*:*:snapshot/*"
],
"Condition": {
"StringEquals": {
"aws:RequestTag/eks:eks-cluster-name": "${aws:PrincipalTag/eks:eks-cluster-name}"
}
}
},
{
"Sid": "Networking",
"Effect": "Allow",
"Action": "ec2:CreateNetworkInterface",
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:RequestTag/eks:eks-cluster-name": "${aws:PrincipalTag/eks:eks-cluster-name}"
},
"StringLike": {
"aws:RequestTag/eks:kubernetes-cni-node-name": "*"
}
}
},
{
"Sid": "LoadBalancer",
"Effect": "Allow",
"Action": [
"elasticloadbalancing:CreateLoadBalancer",
"elasticloadbalancing:CreateTargetGroup",
"elasticloadbalancing:CreateListener",
"elasticloadbalancing:CreateRule",
"ec2:CreateSecurityGroup"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:RequestTag/eks:eks-cluster-name": "${aws:PrincipalTag/eks:eks-cluster-name}"
}
}
},
{
"Sid": "ShieldProtection",
"Effect": "Allow",
"Action": [
"shield:CreateProtection"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:RequestTag/eks:eks-cluster-name": "${aws:PrincipalTag/eks:eks-cluster-name}"
}
}
},
{
"Sid": "ShieldTagResource",
"Effect": "Allow",
"Action": [
"shield:TagResource"
],
"Resource": "arn:aws:shield::*:protection/*",
"Condition": {
"StringEquals": {
"aws:RequestTag/eks:eks-cluster-name": "${aws:PrincipalTag/eks:eks-cluster-name}"
}
}
}
]
}
```
## Check for an existing cluster role
You can use the following procedure to check and see if your account already has the Amazon EKS cluster role.
1. Open the IAM console at https://console.aws.amazon.com/iam/.
1. In the left navigation pane, choose **Roles**.
1. Search the list of roles for `AmazonEKSAutoClusterRole`. If a role that includes `AmazonEKSAutoClusterRole` doesn’t exist, then see the instructions in the next section to create the role. If a role that includes `AmazonEKSAutoClusterRole` does exist, then select the role to view the attached policies.
1. Choose **Permissions**.
1. Ensure that the **AmazonEKSClusterPolicy** managed policy is attached to the role. If the policy is attached, your Amazon EKS cluster role is properly configured.
1. Choose **Trust relationships**, and then choose **Edit trust policy**.
1. Verify that the trust relationship contains the following policy. If the trust relationship matches the following policy, choose **Cancel**. If the trust relationship doesn’t match, copy the policy into the **Edit trust policy** window and choose **Update policy**.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
]
}
]
}
```
**Note**
AWS does not require the name `AmazonEKSAutoClusterRole` for this role.
## Creating the Amazon EKS cluster role
You can use the AWS Management Console or the AWS CLI to create the cluster role.
### AWS Management Console
1. Open the IAM console at https://console.aws.amazon.com/iam/.
1. Choose **Roles**, then **Create role**.
1. Under **Trusted entity type**, select ** AWS service**.
1. From the **Use cases for other AWS services** dropdown list, choose **EKS**.
1. Choose **EKS - Cluster** for your use case, and then choose **Next**.
1. On the **Add permissions** tab, select the policies and then choose **Next**.
+ [AmazonEKSComputePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSComputePolicy)
+ [AmazonEKSBlockStoragePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSBlockStoragePolicy)
+ [AmazonEKSLoadBalancingPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSLoadBalancingPolicy)
+ [AmazonEKSNetworkingPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSNetworkingPolicy)
+ [AmazonEKSClusterPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-amazoneksclusterpolicy)
1. For **Role name**, enter a unique name for your role, such as `AmazonEKSAutoClusterRole`.
1. For **Description**, enter descriptive text such as `Amazon EKS - Cluster role`.
1. Choose **Create role**.
### AWS CLI
1. Copy the following contents to a file named *cluster-trust-policy.json*.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
]
}
]
}
```
1. Create the role. You can replace *AmazonEKSAutoClusterRole* with any name that you choose.
```
aws iam create-role \
--role-name AmazonEKSAutoClusterRole \
--assume-role-policy-document file://"cluster-trust-policy.json"
```
1. Attach the required IAM policies to the role:
**AmazonEKSClusterPolicy**:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoClusterRole \
--policy-arn arn:aws:iam::aws:policy/AmazonEKSClusterPolicy
```
**AmazonEKSComputePolicy**:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoClusterRole \
--policy-arn arn:aws:iam::aws:policy/AmazonEKSComputePolicy
```
**AmazonEKSBlockStoragePolicy**:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoClusterRole \
--policy-arn arn:aws:iam::aws:policy/AmazonEKSBlockStoragePolicy
```
**AmazonEKSLoadBalancingPolicy**:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoClusterRole \
--policy-arn arn:aws:iam::aws:policy/AmazonEKSLoadBalancingPolicy
```
**AmazonEKSNetworkingPolicy**:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoClusterRole \
--policy-arn arn:aws:iam::aws:policy/AmazonEKSNetworkingPolicy
```
# Amazon EKS Auto Mode node IAM role
**Note**
You can’t use the same role that is used to create any clusters.
Before you create nodes, you must create an IAM role with the following policies, or equivalent permissions:
+ [AmazonEKSWorkerNodeMinimalPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSWorkerNodeMinimalPolicy)
+ [AmazonEC2ContainerRegistryPullOnly](https://docs.aws.amazon.com/AmazonECR/latest/userguide/security-iam-awsmanpol.html#security-iam-awsmanpol-AmazonEC2ContainerRegistryPullOnly)
## Check for an existing node role
You can use the following procedure to check and see if your account already has the Amazon EKS node role.
1. Open the IAM console at https://console.aws.amazon.com/iam/.
1. In the left navigation pane, choose **Roles**.
1. Search the list of roles for `AmazonEKSAutoNodeRole`. If a role with one of those names doesn’t exist, then see instructions in the next section to create the role. If a role that contains `AmazonEKSAutoNodeRole` does exist, then select the role to view the attached policies.
1. Choose **Permissions**.
1. Ensure that the required policies above are attached, or equivalent custom policies.
1. Choose **Trust relationships**, and then choose **Edit trust policy**.
1. Verify that the trust relationship contains the following policy. If the trust relationship matches the following policy, choose **Cancel**. If the trust relationship doesn’t match, copy the policy into the **Edit trust policy** window and choose **Update policy**.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "ec2.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
## Creating the Amazon EKS node IAM role
You can create the node IAM role with the AWS Management Console or the AWS CLI.
### AWS Management Console
1. Open the IAM console at https://console.aws.amazon.com/iam/.
1. In the left navigation pane, choose **Roles**.
1. On the **Roles** page, choose **Create role**.
1. On the **Select trusted entity** page, do the following:
1. In the **Trusted entity type** section, choose ** AWS service**.
1. Under **Use case**, choose **EC2**.
1. Choose **Next**.
1. On the **Add permissions** page, attach the following policies:
+ [AmazonEKSWorkerNodeMinimalPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSWorkerNodeMinimalPolicy)
+ [AmazonEC2ContainerRegistryPullOnly](https://docs.aws.amazon.com/AmazonECR/latest/userguide/security-iam-awsmanpol.html#security-iam-awsmanpol-AmazonEC2ContainerRegistryPullOnly)
1. On the **Name, review, and create** page, do the following:
1. For **Role name**, enter a unique name for your role, such as `AmazonEKSAutoNodeRole`.
1. For **Description**, replace the current text with descriptive text such as `Amazon EKS - Node role`.
1. Under **Add tags (Optional)**, add metadata to the role by attaching tags as key-value pairs. For more information about using tags in IAM, see [Tagging IAM resources](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_tags.html) in the *IAM User Guide*.
1. Choose **Create role**.
### AWS CLI
**Create the Node IAM Role**
Use the **node-trust-policy.json** file from the previous step to define which entities can assume the role. Run the following command to create the Node IAM Role:
```
aws iam create-role \
--role-name AmazonEKSAutoNodeRole \
--assume-role-policy-document file://node-trust-policy.json
```
**Note the Role ARN**
After creating the role, retrieve and save the ARN of the Node IAM Role. You will need this ARN in subsequent steps. Use the following command to get the ARN:
```
aws iam get-role --role-name AmazonEKSAutoNodeRole --query "Role.Arn" --output text
```
**Attach Required Policies**
Attach the following AWS managed policies to the Node IAM Role to provide the necessary permissions:
To attach AmazonEKSWorkerNodeMinimalPolicy:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoNodeRole \
--policy-arn arn:aws:iam::aws:policy/AmazonEKSWorkerNodeMinimalPolicy
```
To attach AmazonEC2ContainerRegistryPullOnly:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoNodeRole \
--policy-arn arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryPullOnly
```
**Attach Optional Policy**
If you will pull container images from Public ECR, you should attach the following AWS managed policy to the Node IAM Role to ensure your nodes can authenticate to Public ECR and pull images without throttling.
To attach AmazonElasticContainerRegistryPublicReadOnly:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoNodeRole \
--policy-arn arn:aws:iam::aws:policy/AmazonElasticContainerRegistryPublicReadOnly
```
# Amazon EKS capability IAM role
EKS Capabilities require a capability IAM role (or capability role) to be configured. Capabilities use this role to perform actions on AWS services and to access Kubernetes resources in your cluster through automatically created access entries.
Before you can specify a capability role during capability creation, you must create the IAM role with the appropriate trust policy and permissions for the capability type. Once this IAM role is created, it can be reused for any number of capability resources.
## Capability role requirements
The capability role must meet the following requirements:
+ The role must be in the same AWS account as the cluster and capability resource
+ The role must have a trust policy that allows the EKS capabilities service to assume the role
+ The role must have permissions appropriate for the capability type and use case requirements (see [Permissions by capability type](#capability-permissions))
## Trust policy for capability roles
All capability roles must include the following trust policy:
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "capabilities.eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
]
}
]
}
```
This trust policy allows EKS to:
+ Assume the role to perform AWS API operations
+ Tag sessions for audit and tracking purposes
## Permissions by capability type
The IAM permissions required depend on which capability you’re using and your deployment model.
**Note**
For production deployments using IAM Role Selectors with ACK, or when using kro or Argo CD without AWS service integration, the Capability Role may not require any IAM permissions beyond the trust policy.
**kro (Kube Resource Orchestrator)**
No IAM permissions are required. You can create a capability role with no attached policies. kro only requires Kubernetes RBAC permissions to create and manage Kubernetes resources.
** AWS Controllers for Kubernetes (ACK)**
ACK supports two permission models:
+ **Simple setup (development/testing)**: Add AWS service permissions directly to the Capability Role. This works well for getting started, single-account deployments, or when all users need the same permissions.
+ **Production best practice**: Use IAM Role Selectors to implement least-privilege access. With this approach, the Capability Role only needs `sts:AssumeRole` permission to assume service-specific roles. You don’t add AWS service permissions (like S3 or RDS) to the Capability Role itself—those permissions are granted to individual IAM roles that are mapped to specific namespaces.
IAM Role Selectors enable:
+ Namespace-level permission isolation
+ Cross-account resource management
+ Team-specific IAM roles
+ Least-privilege security model
Example Capability Role policy for IAM Role Selector approach:
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": [
"arn:aws:iam::111122223333:role/ACK-S3-Role",
"arn:aws:iam::111122223333:role/ACK-RDS-Role",
"arn:aws:iam::444455556666:role/ACKCrossAccountRole"
]
}
]
}
```
For detailed ACK permission configuration including IAM Role Selectors, see [Configure ACK permissions](ack-permissions.md).
**Argo CD**
No IAM permissions required by default. Optional permissions may be needed for:
+ ** AWS Secrets Manager**: If using Secrets Manager to store Git repository credentials
+ ** AWS CodeConnections**: If using CodeConnections for Git repository authentication
Example policy for Secrets Manager and CodeConnections:
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"secretsmanager:GetSecretValue",
"secretsmanager:DescribeSecret"
],
"Resource": "arn:aws:secretsmanager:region:account-id:secret:argocd/*"
},
{
"Effect": "Allow",
"Action": [
"codeconnections:UseConnection",
"codeconnections:GetConnection"
],
"Resource": "arn:aws:codeconnections:region:account-id:connection/*"
}
]
}
```
For detailed Argo CD permission requirements, see [Argo CD considerations](argocd-considerations.md).
## Check for an existing capability role
You can use the following procedure to check if your account already has a capability IAM role suitable for your use case.
1. Open the IAM console at https://console.aws.amazon.com/iam/.
1. In the left navigation pane, choose **Roles**.
1. Search the list of roles for your capability role name (for example, `ACKCapabilityRole` or `ArgoCDCapabilityRole`).
1. If a role exists, select it to view the attached policies and trust relationship.
1. Choose **Trust relationships**, and then choose **Edit trust policy**.
1. Verify that the trust relationship matches the [capability trust policy](#capability-trust-policy). If it doesn’t match, update the trust policy.
1. Choose **Permissions** and verify that the role has the appropriate permissions for your capability type and use case.
## Creating a capability IAM role
You can use the AWS Management Console or the AWS CLI to create a capability role.
** AWS Management Console **
1. Open the IAM console at https://console.aws.amazon.com/iam/.
1. Choose **Roles**, then **Create role**.
1. Under **Trusted entity type**, select **Custom trust policy**.
1. Copy and paste the [capability trust policy](#capability-trust-policy) into the trust policy editor.
1. Choose **Next**.
1. On the **Add permissions** tab, select or create policies appropriate for your capability type (see [Permissions by capability type](#capability-permissions)). For kro, you can skip this step.
1. Choose **Next**.
1. For **Role name**, enter a unique name for your role, such as `ACKCapabilityRole`, `ArgoCDCapabilityRole`, or `kroCapabilityRole`.
1. For **Description**, enter descriptive text such as `Amazon EKS - ACK capability role`.
1. Choose **Create role**.
** AWS CLI**
1. Copy the [capability trust policy](#capability-trust-policy) to a file named `capability-trust-policy.json`.
1. Create the role. Replace `ACKCapabilityRole` with your desired role name.
```
aws iam create-role \
--role-name ACKCapabilityRole \
--assume-role-policy-document file://capability-trust-policy.json
```
1. Attach the required IAM policies to the role. For ACK, attach policies for the AWS services you want to manage. For Argo CD, attach policies for Secrets Manager or CodeConnections if needed. For kro, you can skip this step.
Example for ACK with S3 permissions:
```
aws iam put-role-policy \
--role-name ACKCapabilityRole \
--policy-name S3Management \
--policy-document file://s3-policy.json
```
## Troubleshooting capability role issues
**Capability creation fails with "Invalid IAM role"**
Verify that:
+ The role exists in the same account as the cluster
+ The trust policy matches the [capability trust policy](#capability-trust-policy)
+ You have `iam:PassRole` permission for the role
**Capability shows permission errors**
Verify that:
+ The role has the necessary IAM permissions for the capability type
+ The access entry exists on the cluster for the role
+ Additional Kubernetes permissions are configured if required (see [Additional Kubernetes permissions](capabilities-security.md#additional-kubernetes-permissions))
**ACK resources fail with "permission denied" errors**
Verify that:
+ The role has the necessary IAM permissions for your use case
+ For ACK controllers that reference secrets, ensure you’ve associated the `AmazonEKSSecretReaderPolicy` access entry policy scoped to the appropriate namespaces.
For more troubleshooting guidance, see [Security considerations for EKS Capabilities](capabilities-security.md).