**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.

# Identity and access management for Amazon EKS
<a name="security-iam"></a>

 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
<a name="security-iam-audience"></a>

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
<a name="security-iam-authentication"></a>

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
<a name="security-iam-authentication-rootuser"></a>

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
<a name="security-iam-authentication-iamuser"></a>

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
<a name="security-iam-authentication-iamrole"></a>

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
<a name="security-iam-access-manage"></a>

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
<a name="security-iam-access-manage-id-based-policies"></a>

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
<a name="security-iam-access-manage-resource-based-policies"></a>

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)
<a name="security-iam-access-manage-acl"></a>

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
<a name="security-iam-access-manage-other-policies"></a>

 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
<a name="security-iam-access-manage-multiple-policies"></a>

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
<a name="security-iam-service-with-iam"></a>

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
<a name="security-iam-service-with-iam-id-based-policies"></a>

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
<a name="security-iam-service-with-iam-id-based-policies-actions"></a>

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
<a name="security-iam-service-with-iam-id-based-policies-resources"></a>

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
<a name="security-iam-service-with-iam-id-based-policies-conditionkeys"></a>

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
<a name="security-iam-service-with-iam-id-based-policies-examples"></a>

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
<a name="security-iam-service-with-iam-resource-based-policies"></a>

Amazon EKS does not support resource-based policies.

## Authorization based on Amazon EKS tags
<a name="security-iam-service-with-iam-tags"></a>

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
<a name="security-iam-service-with-iam-roles"></a>

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
<a name="security-iam-service-with-iam-roles-tempcreds"></a>

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
<a name="security-iam-service-with-iam-roles-service-linked"></a>

 [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
<a name="security-iam-service-with-iam-roles-service"></a>

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
<a name="security-iam-service-with-iam-roles-choose"></a>

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
<a name="security-iam-id-based-policy-examples"></a>

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
<a name="security-iam-service-with-iam-policy-best-practices"></a>

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
<a name="security-iam-id-based-policy-examples-console"></a>

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
<a name="security-iam-id-based-policy-examples-view-own-permissions"></a>

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
<a name="policy-create-cluster"></a>

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
<a name="policy-create-local-cluster"></a>

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
<a name="policy-example1"></a>

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
<a name="policy-example2"></a>

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
<a name="using-service-linked-roles"></a>

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
<a name="using-service-linked-roles-eks"></a>

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
<a name="service-linked-role-permissions-eks"></a>

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
<a name="create-service-linked-role-eks"></a>

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
<a name="edit-service-linked-role-eks"></a>

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
<a name="delete-service-linked-role-eks"></a>

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
<a name="service-linked-role-review-before-delete-eks"></a>

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
<a name="slr-manual-delete-eks"></a>

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
<a name="slr-regions-eks"></a>

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
<a name="using-service-linked-roles-eks-nodegroups"></a>

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
<a name="service-linked-role-permissions-eks-nodegroups"></a>

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
<a name="create-service-linked-role-eks-nodegroups"></a>

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)
<a name="create-service-linked-role-service-api-eks-nodegroups"></a>

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
<a name="edit-service-linked-role-eks-nodegroups"></a>

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
<a name="delete-service-linked-role-eks-nodegroups"></a>

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
<a name="service-linked-role-review-before-delete-eks-nodegroups"></a>

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
<a name="slr-manual-delete-eks-nodegroups"></a>

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
<a name="slr-regions-eks-nodegroups"></a>

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
<a name="using-service-linked-roles-eks-fargate"></a>

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
<a name="service-linked-role-permissions-eks-fargate"></a>

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
<a name="create-service-linked-role-eks-fargate"></a>

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)
<a name="create-service-linked-role-service-api-eks-fargate"></a>

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
<a name="edit-service-linked-role-eks-fargate"></a>

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
<a name="delete-service-linked-role-eks-fargate"></a>

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
<a name="service-linked-role-review-before-delete-eks-fargate"></a>

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
<a name="slr-manual-delete-eks-fargate"></a>

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
<a name="slr-regions-eks-fargate"></a>

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
<a name="using-service-linked-roles-eks-connector"></a>

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
<a name="service-linked-role-permissions-eks-connector"></a>

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
<a name="create-service-linked-role-eks-connector"></a>

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
<a name="edit-service-linked-role-eks-connector"></a>

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
<a name="delete-service-linked-role-eks-connector"></a>

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
<a name="service-linked-role-review-before-delete-eks-connector"></a>

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
<a name="slr-manual-delete-eks-connector"></a>

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
<a name="using-service-linked-roles-eks-outpost"></a>

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
<a name="service-linked-role-permissions"></a>

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
<a name="create-service-linked-role-eks-outpost"></a>

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
<a name="edit-service-linked-role-eks-outpost"></a>

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
<a name="delete-service-linked-role-eks-outpost"></a>

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
<a name="service-linked-role-review-before-delete-eks-outpost"></a>

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
<a name="slr-manual-delete-eks-outpost"></a>

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
<a name="slr-regions-eks-connector"></a>

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
<a name="using-service-linked-roles-eks-dashboard"></a>

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
<a name="_background"></a>

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
<a name="service-linked-role-permissions-eks-dashboard"></a>

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
<a name="create-service-linked-role-eks-dashboard"></a>

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
<a name="edit-service-linked-role-eks-dashboard"></a>

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
<a name="delete-service-linked-role-eks-dashboard"></a>

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
<a name="service-linked-role-review-before-delete-eks-dashboard"></a>

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
<a name="slr-manual-delete-eks-dashboard"></a>

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
<a name="slr-regions-eks-dashboard"></a>

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
<a name="pod-execution-role"></a>

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
<a name="check-pod-execution-role"></a>

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
<a name="create-pod-execution-role"></a>

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
<a name="connector-iam-role"></a>

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
<a name="check-connector-role"></a>

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
<a name="create-connector-role"></a>

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
<a name="security-iam-awsmanpol"></a>

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
<a name="security-iam-awsmanpol-amazoneks-cni-policy"></a>

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
<a name="security-iam-awsmanpol-amazoneksclusterpolicy"></a>

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
<a name="security-iam-awsmanpol-amazoneksdashboardconsolereadonly"></a>

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
<a name="security-iam-awsmanpol-amazoneksfargatepodexecutionrolepolicy"></a>

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
<a name="security-iam-awsmanpol-AmazonEKSConnectorServiceRolePolicy"></a>

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
<a name="security-iam-awsmanpol-amazoneksforfargateservicerolepolicy"></a>

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
<a name="security-iam-awsmanpol-AmazonEKSComputePolicy"></a>

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
<a name="_permissions_details"></a>

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
<a name="security-iam-awsmanpol-AmazonEKSNetworkingPolicy"></a>

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
<a name="_permissions_details_2"></a>

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
<a name="security-iam-awsmanpol-AmazonEKSBlockStoragePolicy"></a>

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
<a name="_permissions_details_3"></a>

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
<a name="security-iam-awsmanpol-AmazonEKSLoadBalancingPolicy"></a>

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
<a name="_permissions_details_4"></a>

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
<a name="security-iam-awsmanpol-amazoneksmcpreadonlyaccess"></a>

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
<a name="security-iam-awsmanpol-amazoneksservicepolicy"></a>

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
<a name="security-iam-awsmanpol-amazoneksservicerolepolicy"></a>

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
<a name="security-iam-awsmanpol-amazoneksvpcresourcecontroller"></a>

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
<a name="security-iam-awsmanpol-amazoneksworkernodepolicy"></a>

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
<a name="security-iam-awsmanpol-AmazonEKSWorkerNodeMinimalPolicy"></a>

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
<a name="security-iam-awsmanpol-awsserviceroleforamazoneksnodegroup"></a>

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
<a name="security-iam-awsmanpol-AmazonEKSDashboardServiceRolePolicy"></a>

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
<a name="security-iam-awsmanpol-amazonebscsidriverservicerolepolicy"></a>

**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
<a name="security-iam-awsmanpol-amazonebscsidriverpolicyv2"></a>

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
<a name="security-iam-awsmanpol-amazonebscsidrivereksclusterscopedpolicy"></a>

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
<a name="security-iam-awsmanpol-amazonefscsidriverservicerolepolicy"></a>

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
<a name="security-iam-awsmanpol-amazons3filescsidriverservicerolepolicy"></a>

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
<a name="security-iam-awsmanpol-amazonekslocaloutpostclusterpolicy"></a>

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
<a name="security-iam-awsmanpol-amazonekslocaloutpostservicerolepolicy"></a>

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
<a name="security-iam-awsmanpol-updates"></a>

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
<a name="security-iam-troubleshoot"></a>

This topic covers some common errors that you may see while using Amazon EKS with IAM and how to work around them.

## AccessDeniedException
<a name="iam-error"></a>

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
<a name="security-iam-troubleshoot-cannot-view-nodes-or-workloads"></a>

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
<a name="security-iam-troubleshoot-configmap"></a>

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
<a name="security-iam-troubleshoot-passrole"></a>

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
<a name="security-iam-troubleshoot-cross-account-access"></a>

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`
<a name="security-iam-troubleshoot-wrong-sts-endpoint"></a>

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
<a name="cluster-iam-role"></a>

An Amazon EKS cluster IAM role is required for each cluster. Kubernetes clusters managed by Amazon EKS use this role to manage nodes and the [legacy Cloud Provider](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/guide/service/annotations/#legacy-cloud-provider) uses this role to create load balancers with Elastic Load Balancing for services.

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
<a name="check-service-role"></a>

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
<a name="create-service-role"></a>

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
<a name="create-node-role"></a>

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
<a name="check-worker-node-role"></a>

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
<a name="create-worker-node-role"></a>

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
<a name="auto-cluster-iam-role"></a>

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
<a name="tag-prop"></a>

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
<a name="auto-tag-policy"></a>

```
{
    "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
<a name="auto-cluster-iam-role-check"></a>

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
<a name="auto-cluster-iam-role-create"></a>

You can use the AWS Management Console or the AWS CLI to create the cluster role.

### AWS Management Console
<a name="auto-cluster-iam-role-console"></a>

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
<a name="auto-cluster-iam-role-cli"></a>

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
<a name="auto-create-node-role"></a>

**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
<a name="auto-create-node-role-check"></a>

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
<a name="auto-create-node-role-iam"></a>

You can create the node IAM role with the AWS Management Console or the AWS CLI.

### AWS Management Console
<a name="auto-create-node-role-console"></a>

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
<a name="auto-create-node-role-cli"></a>

 **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
<a name="capability-role"></a>

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
<a name="_capability_role_requirements"></a>

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
<a name="capability-trust-policy"></a>

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
<a name="capability-permissions"></a>

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
<a name="check-capability-role"></a>

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
<a name="create-capability-role"></a>

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
<a name="troubleshooting-capability-role"></a>

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