**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. # Learn how EKS Pod Identity grants pods access to AWS services Applications in a Pod’s containers can use an AWS SDK or the AWS CLI to make API requests to AWS services using AWS Identity and Access Management (IAM) permissions. Applications must sign their AWS API requests with AWS credentials. *EKS Pod Identities* provide the ability to manage credentials for your applications, similar to the way that Amazon EC2 instance profiles provide credentials to Amazon EC2 instances. Instead of creating and distributing your AWS credentials to the containers or using the Amazon EC2 instance’s role, you associate an IAM role with a Kubernetes service account and configure your Pods to use the service account. [![AWS Videos](http://img.youtube.com/vi/https://www.youtube.com/embed/aUjJSorBE70?rel=0/0.jpg)](http://www.youtube.com/watch?v=https://www.youtube.com/embed/aUjJSorBE70?rel=0) Each EKS Pod Identity association maps a role to a service account in a namespace in the specified cluster. If you have the same application in multiple clusters, you can make identical associations in each cluster without modifying the trust policy of the role. If a pod uses a service account that has an association, Amazon EKS sets environment variables in the containers of the pod. The environment variables configure the AWS SDKs, including the AWS CLI, to use the EKS Pod Identity credentials. ## Benefits of EKS Pod Identities EKS Pod Identities provide the following benefits: + **Least privilege** – You can scope IAM permissions to a service account, and only Pods that use that service account have access to those permissions. This feature also eliminates the need for third-party solutions such as `kiam` or `kube2iam`. + **Credential isolation** – When access to the [Amazon EC2 Instance Metadata Service (IMDS)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html) is restricted, a Pod’s containers can only retrieve credentials for the IAM role that’s associated with the service account that the container uses. A container never has access to credentials that are used by other containers in other Pods. If IMDS is not restricted, the Pod’s containers also have access to the [Amazon EKS node IAM role](create-node-role.md) and the containers may be able to gain access to credentials of IAM roles of other Pods on the same node. For more information, see [Restrict access to the instance profile assigned to the worker node](https://docs.aws.amazon.com/eks/latest/best-practices/identity-and-access-management.html#_identities_and_credentials_for_eks_pods_recommendations). **Note** Pods configured with `hostNetwork: true` will always have IMDS access, but the AWS SDKs and CLI will use Pod Identity credentials when enabled. + **Auditability** – Access and event logging is available through AWS CloudTrail to help facilitate retrospective auditing. **Important** Containers are not a security boundary, and the use of Pod Identity does not change this. Pods assigned to the same node will share a kernel and potentially other resources depending on your Pod configuration. While Pods running on separate nodes will be isolated at the compute layer, there are node applications that have additional permissions in the Kubernetes API beyond the scope of an individual instance. Some examples are `kubelet`, `kube-proxy`, CSI storage drivers, or your own Kubernetes applications. EKS Pod Identity is a simpler method than [IAM roles for service accounts](iam-roles-for-service-accounts.md), as this method doesn’t use OIDC identity providers. EKS Pod Identity has the following enhancements: + **Independent operations** – In many organizations, creating OIDC identity providers is a responsibility of different teams than administering the Kubernetes clusters. EKS Pod Identity has clean separation of duties, where all configuration of EKS Pod Identity associations is done in Amazon EKS and all configuration of the IAM permissions is done in IAM. + **Reusability** – EKS Pod Identity uses a single IAM principal instead of the separate principals for each cluster that IAM roles for service accounts use. Your IAM administrator adds the following principal to the trust policy of any role to make it usable by EKS Pod Identities. ``` "Principal": { "Service": "pods.eks.amazonaws.com" } ``` + **Scalability** — Each set of temporary credentials are assumed by the EKS Auth service in EKS Pod Identity, instead of each AWS SDK that you run in each pod. Then, the Amazon EKS Pod Identity Agent that runs on each node issues the credentials to the SDKs. Thus the load is reduced to once for each node and isn’t duplicated in each pod. For more details of the process, see [Understand how EKS Pod Identity works](pod-id-how-it-works.md). For more information to compare the two alternatives, see [Grant Kubernetes workloads access to AWS using Kubernetes Service Accounts](service-accounts.md). ## Overview of setting up EKS Pod Identities Turn on EKS Pod Identities by completing the following procedures: 1. [Set up the Amazon EKS Pod Identity Agent](pod-id-agent-setup.md) — You only complete this procedure once for each cluster. You do not need to complete this step if EKS Auto Mode is enabled on your cluster. 1. [Assign an IAM role to a Kubernetes service account](pod-id-association.md) — Complete this procedure for each unique set of permissions that you want an application to have. 1. [Configure Pods to access AWS services with service accounts](pod-id-configure-pods.md) — Complete this procedure for each Pod that needs access to AWS services. 1. [Use pod identity with the AWS SDK](pod-id-minimum-sdk.md) — Confirm that the workload uses an AWS SDK of a supported version and that the workload uses the default credential chain. ## Limits + Up to 5,000 EKS Pod Identity associations per cluster to map IAM roles to Kubernetes service accounts are supported. ## Considerations + **IAM Role Association**: Each Kubernetes service account in a cluster can be associated with one IAM role from the same AWS account as the cluster. To change the role, edit the EKS Pod Identity association. For cross-account access, delegate access to the role using IAM roles. To learn more, see [Delegate access across AWS accounts using IAM roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html) in the *IAM User Guide*. + **EKS Pod Identity Agent**: The Pod Identity Agent is required to use EKS Pod Identity. The agent runs as a Kubernetes `DaemonSet` on cluster nodes, providing credentials only to pods on the same node. It uses the node’s `hostNetwork`, occupying port `80` and `2703` on the link-local address (`169.254.170.23` for IPv4, `[fd00:ec2::23]` for IPv6). If IPv6 is disabled in your cluster, disable IPv6 for the Pod Identity Agent. To learn more, see [Disable IPv6 in the EKS Pod Identity Agent](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-agent-config-ipv6.html). + **Eventual Consistency**: EKS Pod Identity associations are eventually consistent, with potential delays of several seconds after API calls. Avoid creating or updating associations in critical, high-availability code paths. Instead, perform these actions in separate, less frequent initialization or setup routines. To learn more, see [Security Groups Per Pod](https://docs.aws.amazon.com/eks/latest/best-practices/sgpp.html) in the *EKS Best Practices Guide*. + **Proxy and Security Group Considerations**: For pods using a proxy, add `169.254.170.23` (IPv4) and `[fd00:ec2::23]` (IPv6) to the `no_proxy/NO_PROXY` environment variables to prevent failed requests to the EKS Pod Identity Agent. If using Security Groups for Pods with the AWS VPC CNI, set the `ENABLE_POD_ENI` flag to ‘true’ and the `POD_SECURITY_GROUP_ENFORCING_MODE` flag to ‘standard’. To learn more, see [Assign security groups to individual Pods](https://docs.aws.amazon.com/eks/latest/userguide/security-groups-for-pods.html). ### EKS Pod Identity cluster versions To use EKS Pod Identity, the cluster must have a platform version that is the same or later than the version listed in the following table, or a Kubernetes version that is later than the versions listed in the table. To find the suggested version of the Amazon EKS Pod Identity Agent for a Kubernetes version, see [Verify Amazon EKS add-on version compatibility with a cluster](addon-compat.md). | Kubernetes version | Platform version | | --- | --- | | Kubernetes versions not listed | All platform versions support | | `1.28` | `eks.4` | ### EKS Pod Identity restrictions EKS Pod Identities are available on the following: + Amazon EKS cluster versions listed in the previous topic [EKS Pod Identity cluster versions](#pod-id-cluster-versions). + Worker nodes in the cluster that are Linux Amazon EC2 instances. EKS Pod Identities aren’t available on the following: + AWS Outposts. + Amazon EKS Anywhere. + Kubernetes clusters that you create and run on Amazon EC2. The EKS Pod Identity components are only available on Amazon EKS. You can’t use EKS Pod Identities with: + Pods that run anywhere except Linux Amazon EC2 instances. Linux and Windows pods that run on AWS Fargate (Fargate) aren’t supported. Pods that run on Windows Amazon EC2 instances aren’t supported. # Understand how EKS Pod Identity works Amazon EKS Pod Identity associations provide the ability to manage credentials for your applications, similar to the way that Amazon EC2 instance profiles provide credentials to Amazon EC2 instances. Amazon EKS Pod Identity provides credentials to your workloads with an additional *EKS Auth* API and an agent pod that runs on each node. In your add-ons, such as *Amazon EKS add-ons* and self-managed controller, operators, and other add-ons, the author needs to update their software to use the latest AWS SDKs. For the list of compatibility between EKS Pod Identity and the add-ons produced by Amazon EKS, see the previous section [EKS Pod Identity restrictions](pod-identities.md#pod-id-restrictions). ## Using EKS Pod Identities in your code In your code, you can use the AWS SDKs to access AWS services. You write code to create a client for an AWS service with an SDK, and by default the SDK searches in a chain of locations for AWS Identity and Access Management credentials to use. After valid credentials are found, the search is stopped. For more information about the default locations used, see the [Credential provider chain](https://docs.aws.amazon.com/sdkref/latest/guide/standardized-credentials.html#credentialProviderChain) in the AWS SDKs and Tools Reference Guide. EKS Pod Identities have been added to the *Container credential provider* which is searched in a step in the default credential chain. If your workloads currently use credentials that are earlier in the chain of credentials, those credentials will continue to be used even if you configure an EKS Pod Identity association for the same workload. This way you can safely migrate from other types of credentials by creating the association first, before removing the old credentials. The container credentials provider provides temporary credentials from an agent that runs on each node. In Amazon EKS, the agent is the Amazon EKS Pod Identity Agent and on Amazon Elastic Container Service the agent is the `amazon-ecs-agent`. The SDKs use environment variables to locate the agent to connect to. In contrast, *IAM roles for service accounts* provides a *web identity* token that the AWS SDK must exchange with AWS Security Token Service by using `AssumeRoleWithWebIdentity`. ## How EKS Pod Identity Agent works with a Pod 1. When Amazon EKS starts a new pod that uses a service account with an EKS Pod Identity association, the cluster adds the following content to the Pod manifest: ``` env: - name: AWS_CONTAINER_AUTHORIZATION_TOKEN_FILE value: "/var/run/secrets/pods.eks.amazonaws.com/serviceaccount/eks-pod-identity-token" - name: AWS_CONTAINER_CREDENTIALS_FULL_URI value: "http://169.254.170.23/v1/credentials" volumeMounts: - mountPath: "/var/run/secrets/pods.eks.amazonaws.com/serviceaccount/" name: eks-pod-identity-token volumes: - name: eks-pod-identity-token projected: defaultMode: 420 sources: - serviceAccountToken: audience: pods.eks.amazonaws.com expirationSeconds: 86400 # 24 hours path: eks-pod-identity-token ``` 1. Kubernetes selects which node to run the pod on. Then, the Amazon EKS Pod Identity Agent on the node uses the [AssumeRoleForPodIdentity](https://docs.aws.amazon.com/eks/latest/APIReference/API_auth_AssumeRoleForPodIdentity.html) action to retrieve temporary credentials from the EKS Auth API. 1. The EKS Pod Identity Agent makes these credentials available for the AWS SDKs that you run inside your containers. 1. You use the SDK in your application without specifying a credential provider to use the default credential chain. Or, you specify the container credential provider. For more information about the default locations used, see the [Credential provider chain](https://docs.aws.amazon.com/sdkref/latest/guide/standardized-credentials.html#credentialProviderChain) in the AWS SDKs and Tools Reference Guide. 1. The SDK uses the environment variables to connect to the EKS Pod Identity Agent and retrieve the credentials. **Note** If your workloads currently use credentials that are earlier in the chain of credentials, those credentials will continue to be used even if you configure an EKS Pod Identity association for the same workload. # Set up the Amazon EKS Pod Identity Agent Amazon EKS Pod Identity associations provide the ability to manage credentials for your applications, similar to the way that Amazon EC2 instance profiles provide credentials to Amazon EC2 instances. Amazon EKS Pod Identity provides credentials to your workloads with an additional *EKS Auth* API and an agent pod that runs on each node. **Tip** You do not need to install the EKS Pod Identity Agent on EKS Auto Mode Clusters. This capability is built into EKS Auto Mode. ## Considerations + By default, the EKS Pod Identity Agent is pre-installed on EKS Auto Mode clusters. To learn more, see [Automate cluster infrastructure with EKS Auto Mode](automode.md). + By default, the EKS Pod Identity Agent listens on an `IPv4` and `IPv6` address for pods to request credentials. The agent uses the loopback (localhost) IP address `169.254.170.23` for `IPv4` and the localhost IP address `[fd00:ec2::23]` for `IPv6`. + If you disable `IPv6` addresses, or otherwise prevent localhost `IPv6` IP addresses, the agent can’t start. To start the agent on nodes that can’t use `IPv6`, follow the steps in [Disable `IPv6` in the EKS Pod Identity Agent](pod-id-agent-config-ipv6.md) to disable the `IPv6` configuration. ## Creating the Amazon EKS Pod Identity Agent ### Agent prerequisites **Important** The nodes where the EKS Pod Identity Agent runs must be able to access the EKS Auth API. If you are using private subnets for your nodes, you must set up an AWS PrivateLink interface endpoint for the EKS Auth API. For more information, see [Access Amazon EKS using AWS PrivateLink](vpc-interface-endpoints.md). + An existing Amazon EKS cluster. To deploy one, see [Get started with Amazon EKS](getting-started.md). The cluster version and platform version must be the same or later than the versions listed in [EKS Pod Identity cluster versions](pod-identities.md#pod-id-cluster-versions). + The node role has permissions for the agent to do the `AssumeRoleForPodIdentity` action in the EKS Auth API. You can use the [AWS managed policy: AmazonEKSWorkerNodePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-amazoneksworkernodepolicy) or add a custom policy similar to the following: ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "eks-auth:AssumeRoleForPodIdentity" ], "Resource": "*" } ] } ``` This action can be limited by tags to restrict which roles can be assumed by pods that use the agent. + The nodes can reach and download images from Amazon ECR. The container image for the add-on is in the registries listed in [View Amazon container image registries for Amazon EKS add-ons](add-ons-images.md). Note that you can change the image location and provide `imagePullSecrets` for EKS add-ons in the **Optional configuration settings** in the AWS Management Console, and in the `--configuration-values` in the AWS CLI. ### Setup agent with AWS console 1. Open the [Amazon EKS console](https://console.aws.amazon.com/eks/home#/clusters). 1. In the left navigation pane, select **Clusters**, and then select the name of the cluster that you want to configure the EKS Pod Identity Agent add-on for. 1. Choose the **Add-ons** tab. 1. Choose **Get more add-ons**. 1. Select the box in the top right of the add-on box for EKS Pod Identity Agent and then choose **Next**. 1. On the **Configure selected add-ons settings** page, select any version in the **Version** dropdown list. 1. (Optional) Expand **Optional configuration settings** to enter additional configuration. For example, you can provide an alternative container image location and `ImagePullSecrets`. The JSON Schema with accepted keys is shown in **Add-on configuration schema**. Enter the configuration keys and values in **Configuration values**. 1. Choose **Next**. 1. Confirm that the EKS Pod Identity Agent pods are running on your cluster. ``` kubectl get pods -n kube-system | grep 'eks-pod-identity-agent' ``` An example output is as follows. ``` eks-pod-identity-agent-gmqp7 1/1 Running 1 (24h ago) 24h eks-pod-identity-agent-prnsh 1/1 Running 1 (24h ago) 24h ``` You can now use EKS Pod Identity associations in your cluster. For more information, see [Assign an IAM role to a Kubernetes service account](pod-id-association.md). ### Setup agent with AWS CLI 1. Run the following AWS CLI command. Replace `my-cluster` with the name of your cluster. ``` aws eks create-addon --cluster-name my-cluster --addon-name eks-pod-identity-agent --addon-version v1.0.0-eksbuild.1 ``` **Note** The EKS Pod Identity Agent doesn’t use the `service-account-role-arn` for *IAM roles for service accounts*. You must provide the EKS Pod Identity Agent with permissions in the node role. 1. Confirm that the EKS Pod Identity Agent pods are running on your cluster. ``` kubectl get pods -n kube-system | grep 'eks-pod-identity-agent' ``` An example output is as follows. ``` eks-pod-identity-agent-gmqp7 1/1 Running 1 (24h ago) 24h eks-pod-identity-agent-prnsh 1/1 Running 1 (24h ago) 24h ``` You can now use EKS Pod Identity associations in your cluster. For more information, see [Assign an IAM role to a Kubernetes service account](pod-id-association.md). # Assign an IAM role to a Kubernetes service account This topic covers how to configure a Kubernetes service account to assume an AWS Identity and Access Management (IAM) role with EKS Pod Identity. Any Pods that are configured to use the service account can then access any AWS service that the role has permissions to access. To create an EKS Pod Identity association, there is only a single step; you create the association in EKS through the AWS Management Console, AWS CLI, AWS SDKs, AWS CloudFormation and other tools. There isn’t any data or metadata about the associations inside the cluster in any Kubernetes objects and you don’t add any annotations to the service accounts. **Prerequisites** + An existing cluster. If you don’t have one, you can create one by following one of the guides in [Get started with Amazon EKS](getting-started.md). + The IAM principal that is creating the association must have `iam:PassRole`. + The latest version of the AWS CLI installed and configured on your device or AWS CloudShell. You can check your current version with `aws --version | cut -d / -f2 | cut -d ' ' -f1`. Package managers such as `yum`, `apt-get`, or Homebrew for macOS are often several versions behind the latest version of the AWS CLI. To install the latest version, see [Installing](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) and [Quick configuration with aws configure](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config) in the AWS Command Line Interface User Guide. The AWS CLI version installed in the AWS CloudShell may also be several versions behind the latest version. To update it, see [Installing AWS CLI to your home directory](https://docs.aws.amazon.com/cloudshell/latest/userguide/vm-specs.html#install-cli-software) in the AWS CloudShell User Guide. + The `kubectl` command line tool is installed on your device or AWS CloudShell. The version can be the same as or up to one minor version earlier or later than the Kubernetes version of your cluster. For example, if your cluster version is `1.29`, you can use `kubectl` version `1.28`, `1.29`, or `1.30` with it. To install or upgrade `kubectl`, see [Set up `kubectl` and `eksctl`](install-kubectl.md). + An existing `kubectl` `config` file that contains your cluster configuration. To create a `kubectl` `config` file, see [Connect kubectl to an EKS cluster by creating a kubeconfig file](create-kubeconfig.md). ## Create a Pod Identity association (AWS Console) 1. Open the [Amazon EKS console](https://console.aws.amazon.com/eks/home#/clusters). 1. In the left navigation pane, select **Clusters**, and then select the name of the cluster that you want to configure the EKS Pod Identity Agent add-on for. 1. Choose the **Access** tab. 1. In the **Pod Identity associations**, choose **Create**. 1. For the **IAM role**, select the IAM role with the permissions that you want the workload to have. **Note** The list only contains roles that have the following trust policy which allows EKS Pod Identity to use them. ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AllowEksAuthToAssumeRoleForPodIdentity", "Effect": "Allow", "Principal": { "Service": "pods.eks.amazonaws.com" }, "Action": [ "sts:AssumeRole", "sts:TagSession" ] } ] } ``` `sts:AssumeRole` — EKS Pod Identity uses `AssumeRole` to assume the IAM role before passing the temporary credentials to your pods. `sts:TagSession` — EKS Pod Identity uses `TagSession` to include *session tags* in the requests to AWS STS. You can use these tags in the *condition keys* in the trust policy to restrict which service accounts, namespaces, and clusters can use this role. 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). 1. For the **Kubernetes namespace**, select the Kubernetes namespace that contains the service account and workload. Optionally, you can specify a namespace by name that doesn’t exist in the cluster. 1. For the **Kubernetes service account**, select the Kubernetes service account to use. The manifest for your Kubernetes workload must specify this service account. Optionally, you can specify a service account by name that doesn’t exist in the cluster. 1. (Optional) Select **Disable session tags** to disable the default session tags that Pod Identity automatically adds when it assumes the role. 1. (Optional) Toggle **Configure session policy** to configure an IAM policy to apply additional restrictions to this Pod Identity association beyond the permissions defined in the IAM policy attached to the IAM role. **Note** A session policy can only be applied when the **Disable session tags** setting is checked. 1. (Optional) For the **Tags**, choose **Add tag** to add metadata in a key and value pair. These tags are applied to the association and can be used in IAM policies. You can repeat this step to add multiple tags. 1. Choose **Create**. ## Create a Pod Identity association (AWS CLI) 1. If you want to associate an existing IAM policy to your IAM role, skip to the next step. Create an IAM policy. You can create your own policy, or copy an AWS managed policy that already grants some of the permissions that you need and customize it to your specific requirements. For more information, see [Creating IAM policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) in the *IAM User Guide*. 1. Create a file that includes the permissions for the AWS services that you want your Pods to access. For a list of all actions for all AWS services, see the [Service Authorization Reference](https://docs.aws.amazon.com/service-authorization/latest/reference/). You can run the following command to create an example policy file that allows read-only access to an Amazon S3 bucket. You can optionally store configuration information or a bootstrap script in this bucket, and the containers in your Pod can read the file from the bucket and load it into your application. If you want to create this example policy, copy the following contents to your device. Replace *my-pod-secrets-bucket* with your bucket name and run the command. ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "s3:GetObject", "Resource": "arn:aws:s3:::my-pod-secrets-bucket" } ] } ``` 1. Create the IAM policy. ``` aws iam create-policy --policy-name my-policy --policy-document file://my-policy.json ``` 1. Create an IAM role and associate it with a Kubernetes service account. 1. If you have an existing Kubernetes service account that you want to assume an IAM role, then you can skip this step. Create a Kubernetes service account. Copy the following contents to your device. Replace *my-service-account* with your desired name and *default* with a different namespace, if necessary. If you change *default*, the namespace must already exist. ``` cat >my-service-account.yaml < 1. Confirm that the IAM role’s trust policy is configured correctly. ``` aws iam get-role --role-name my-role --query Role.AssumeRolePolicyDocument ``` An example output is as follows. ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "Allow EKS Auth service to assume this role for Pod Identities", "Effect": "Allow", "Principal": { "Service": "pods.eks.amazonaws.com" }, "Action": [ "sts:AssumeRole", "sts:TagSession" ] } ] } ``` 1. Confirm that the policy that you attached to your role in a previous step is attached to the role. ``` aws iam list-attached-role-policies --role-name my-role --query 'AttachedPolicies[].PolicyArn' --output text ``` An example output is as follows. ``` arn:aws:iam::111122223333:policy/my-policy ``` 1. Set a variable to store the Amazon Resource Name (ARN) of the policy that you want to use. Replace *my-policy* with the name of the policy that you want to confirm permissions for. ``` export policy_arn=arn:aws:iam::111122223333:policy/my-policy ``` 1. View the default version of the policy. ``` aws iam get-policy --policy-arn $policy_arn ``` An example output is as follows. ``` { "Policy": { "PolicyName": "my-policy", "PolicyId": "EXAMPLEBIOWGLDEXAMPLE", "Arn": "arn:aws:iam::111122223333:policy/my-policy", "Path": "/", "DefaultVersionId": "v1", [...] } } ``` 1. View the policy contents to make sure that the policy includes all the permissions that your Pod needs. If necessary, replace *1* in the following command with the version that’s returned in the previous output. ``` aws iam get-policy-version --policy-arn $policy_arn --version-id v1 ``` An example output is as follows. ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "s3:GetObject", "Resource": "arn:aws:s3:::my-pod-secrets-bucket" } ] } ``` If you created the example policy in a previous step, then your output is the same. If you created a different policy, then the *example* content is different. ## Next Steps [Configure Pods to access AWS services with service accounts](pod-id-configure-pods.md) # Access AWS Resources using EKS Pod Identity Target IAM Roles When running applications on Amazon Elastic Kubernetes Service (Amazon EKS), you might need to access AWS resources that exist in different AWS accounts. This guide shows you how to set up cross account access using EKS Pod Identity, which enables your Kubernetes pods to access other AWS resources using target roles. ## Prerequisites Before you begin, ensure you have completed the following steps: + [Set up the Amazon EKS Pod Identity Agent](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-agent-setup.html) + [Create an EKS Pod Identity role](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html) ## How It Works Pod Identity enables applications in your EKS cluster to access AWS resources across accounts through a process called role chaining. When creating a Pod Identity association, you can provide two IAM roles: an [EKS Pod Identity role](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html) in the same account as your EKS cluster and a Target IAM Role from the account containing your AWS resources you wish to access, (like S3 buckets or RDS Databases). The [EKS Pod Identity role](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html) must be in your EKS cluster’s account due to [IAM PassRole](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_examples_iam-passrole-service.html) requirements, while the Target IAM Role can be in any AWS account. PassRole enables an AWS entity to delegate role assumption to another service. EKS Pod Identity uses PassRole to connect a role to a Kubernetes service account, requiring both the role and the identity passing it to be in the same AWS account as the EKS cluster. When your application pod needs to access AWS resources, it requests credentials from Pod Identity. Pod Identity then automatically performs two role assumptions in sequence: first assuming the [EKS Pod Identity role](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html), then using those credentials to assume the Target IAM Role. This process provides your pod with temporary credentials that have the permissions defined in the target role, allowing secure access to resources in other AWS accounts. ## Caching considerations Due to caching mechanisms, updates to an IAM role in an existing Pod Identity association may not take effect immediately in the pods running on your EKS cluster. The Pod Identity Agent caches IAM credentials based on the association’s configuration at the time the credentials are fetched. If the association includes only an [EKS Pod Identity role](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html) and no Target IAM Role, the cached credentials last for 6 hours. If the association includes both the [EKS Pod Identity role](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html) ARN and a Target IAM Role, the cached credentials last for 59 minutes. Modifying an existing association, such as updating the [EKS Pod Identity role](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html) ARN or adding a Target IAM Role, does not reset the existing cache. As a result, the agent will not recognize updates until the cached credentials refresh. To apply changes sooner, you can recreate the existing pods; otherwise, you will need to wait for the cache to expire. ## Step 1: Create and associate a Target IAM Role In this step, you will establish a secure trust chain by creating and configuring a Target IAM Role. For demonstration, we will create a new Target IAM Role to establish a trust chain between two AWS accounts: the [EKS Pod Identity role](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html) (e.g., `eks-pod-identity-primary-role`) in the EKS cluster’s AWS account gains permission to assume the Target IAM Role (e.g. `eks-pod-identity-aws-resources`) in your target account, enabling access to AWS resources like Amazon S3 buckets. ### Create the Target IAM Role 1. Open the [Amazon IAM console](https://console.aws.amazon.com/iam/home). 1. In the top navigation bar, verify that you are signed into the account containing the AWS resources (like S3 buckets or DynamoDB tables) for your Target IAM Role. 1. In the left navigation pane, choose **Roles**. 1. Choose the **Create role** button, then ** AWS account** under "Trusted entity type." 1. Choose **Another AWS account**, enter your AWS account number (the account where your [EKS Pod Identity role](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html) exists), then choose **Next**. 1. Add the permission policies you would like to associate to the role (e.g., AmazonS3FullAccess), then choose **Next**. 1. Enter a role name, such as `MyCustomIAMTargetRole`, then choose **Create role**. ### Update the Target IAM Role trust policy 1. After creating the role, you’ll be returned to the **Roles** list. Find and select the new role you created in the previous step (e.g., `MyCustomIAMTargetRole`). 1. Select the **Trust relationships** tab. 1. Click **Edit trust policy** on the right side. 1. In the policy editor, replace the default JSON with your trust policy. Replace the placeholder values for role name and `111122223333` in the IAM role ARN with the AWS account ID hosting your EKS cluster. You can also optionally use PrincipalTags in the role trust policy to authorize only specific service accounts from a given cluster and namespace to assume your target role . For example: ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::111122223333:root" }, "Action": [ "sts:AssumeRole", "sts:TagSession" ], "Condition": { "StringEquals": { "aws:RequestTag/eks-cluster-arn": "arn:aws:eks:us-east-1:111122223333:cluster/example-cluster", "aws:RequestTag/kubernetes-namespace": "ExampleNameSpace", "aws:RequestTag/kubernetes-service-account": "ExampleServiceAccountName" }, "ArnEquals": { "aws:PrincipalARN": "arn:aws:iam::111122223333:role/eks-pod-identity-primary-role" } } } ] } ``` The above policy lets the role `eks-pod-identity-primary-role` from AWS account 111122223333 with the relevant [EKS Pod Identity Session Tags](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-abac.html) assume this role. If you [Disabled Session Tags](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-abac.html#pod-id-abac-tags) in your EKS Pod Identity, EKS Pod Identity also sets the `sts:ExternalId` with information about the cluster, namespace, and service account of a pod when assuming a target role. ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::111122223333:root" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "sts:ExternalId": "region/111122223333/cluster-name/namespace/service-account-name" }, "ArnEquals": { "aws:PrincipalARN": "arn:aws:iam::111122223333:role/eks-pod-identity-primary-role" } } }, { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::111122223333:root" }, "Action": "sts:TagSession" } ] } ``` The above policy helps ensure that only the expected cluster, namespace and service account can assume the target role. ### Update the permission policy for EKS Pod Identity role In this step, you will update the permission policy of the [EKS Pod Identity role](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html) associated with your Amazon EKS cluster by adding the Target IAM Role ARN as a resource. 1. Open the [Amazon EKS console](https://console.aws.amazon.com/eks/home#/clusters). 1. In the left navigation pane, select **Clusters**, and then select the name of your EKS cluster. 1. Choose the **Access** tab. 1. Under **Pod Identity associations**, select your [EKS Pod Identity role](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html). 1. Choose **Permissions**, **Add permissions**, then **Create inline policy**. 1. Choose **JSON** on the right side. 1. In the policy editor, replace the default JSON with your permission policy. Replace the placeholder value for role name and `222233334444` in the IAM role ARN with your Target IAM Role. For example: ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "sts:AssumeRole", "sts:TagSession" ], "Resource": "arn:aws:iam::222233334444:role/eks-pod-identity-aws-resources" } ] } ``` ## Step 2: Associate the Target IAM Role to a Kubernetes service account In this step, you will create an association between the Target IAM role and the Kubernetes service account in your EKS cluster. 1. Open the [Amazon EKS console](https://console.aws.amazon.com/eks/home#/clusters). 1. In the left navigation pane, select **Clusters**, and then select the name of the cluster that you want to add the association to. 1. Choose the **Access** tab. 1. In the **Pod Identity associations**, choose **Create**. 1. Choose the [EKS Pod Identity role](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html) in **IAM role** for your workloads to assume. 1. Choose the Target IAM role in **Target IAM role** that will be assumed by the [EKS Pod Identity role](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html). 1. In the **Kubernetes namespace** field, enter the name of the namespace where you want to create the association (e.g., `my-app-namespace`). This defines where the service account resides. 1. In the **Kubernetes service account** field, enter the name of the service account (e.g., `my-service-account`) that will use the IAM credentials. This links the IAM role to the service account. 1. (Optional) Select **Disable session tags** to disable the default session tags that Pod Identity automatically adds when it assumes the role. 1. (Optional) Toggle **Configure session policy** to configure an IAM policy to apply additional restrictions to this Pod Identity association beyond the permissions defined in the IAM policy attached to the **Target IAM role**. **Note** 1. A session policy can only be applied when the **Disable session tags** setting is checked. 2. If you specify a session policy, then the policy restrictions apply to the **Target IAM role**'s permissions and not the **IAM role** associated with this Pod Identity association. 1. Choose **Create** to create the association. # Configure Pods to access AWS services with service accounts If a Pod needs to access AWS services, then you must configure it to use a Kubernetes service account. The service account must be associated to an AWS Identity and Access Management (IAM) role that has permissions to access the AWS services. + An existing cluster. If you don’t have one, you can create one using one of the guides in [Get started with Amazon EKS](getting-started.md). + An existing Kubernetes service account and an EKS Pod Identity association that associates the service account with an IAM role. The role must have an associated IAM policy that contains the permissions that you want your Pods to have to use AWS services. For more information about how to create the service account and role, and configure them, see [Assign an IAM role to a Kubernetes service account](pod-id-association.md). + The latest version of the AWS CLI installed and configured on your device or AWS CloudShell. You can check your current version with `aws --version | cut -d / -f2 | cut -d ' ' -f1`. Package managers such as `yum`, `apt-get`, or Homebrew for macOS are often several versions behind the latest version of the AWS CLI. To install the latest version, see [Installing](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) and [Quick configuration with aws configure](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config) in the AWS Command Line Interface User Guide. The AWS CLI version installed in the AWS CloudShell may also be several versions behind the latest version. To update it, see [Installing AWS CLI to your home directory](https://docs.aws.amazon.com/cloudshell/latest/userguide/vm-specs.html#install-cli-software) in the AWS CloudShell User Guide. + The `kubectl` command line tool is installed on your device or AWS CloudShell. The version can be the same as or up to one minor version earlier or later than the Kubernetes version of your cluster. For example, if your cluster version is `1.29`, you can use `kubectl` version `1.28`, `1.29`, or `1.30` with it. To install or upgrade `kubectl`, see [Set up `kubectl` and `eksctl`](install-kubectl.md). + An existing `kubectl` `config` file that contains your cluster configuration. To create a `kubectl` `config` file, see [Connect kubectl to an EKS cluster by creating a kubeconfig file](create-kubeconfig.md). 1. Use the following command to create a deployment manifest that you can deploy a Pod to confirm configuration with. Replace the example values with your own values. ``` cat >my-deployment.yaml < Attribute-based access control (ABAC) grants rights to users through policies which combine attributes together. EKS Pod Identity attaches tags to the temporary credentials to each Pod with attributes such as cluster name, namespace, and service account name. These role session tags enable administrators to author a single role that can work across service accounts by allowing access to AWS resources based on matching tags. By adding support for role session tags, you can enforce tighter security boundaries between clusters, and workloads within clusters, while reusing the same IAM roles and IAM policies. ## Sample policy with tags Below is an IAM policy example that grants `s3:GetObject` permissions when the corresponding object is tagged with the EKS cluster name. ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:ListBucket" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "s3:GetObject", "s3:GetObjectTagging" ], "Resource": "*", "Condition": { "StringEquals": { "s3:ExistingObjectTag/eks-cluster-name": "${aws:PrincipalTag/eks-cluster-name}" } } } ] } ``` ## Enable or disable session tags EKS Pod Identity adds a pre-defined set of session tags when it assumes the role. These session tags enable administrators to author a single role that can work across resources by allowing access to AWS resources based on matching tags. ### Enable session tags Session tags are automatically enabled with EKS Pod Identity—​no action is required on your part. By default, EKS Pod Identity attaches a set of predefined tags to your session. To reference these tags in policies, use the syntax `${aws:PrincipalTag/` followed by the tag key. For example, `${aws:PrincipalTag/kubernetes-namespace}`. + `eks-cluster-arn` + `eks-cluster-name` + `kubernetes-namespace` + `kubernetes-service-account` + `kubernetes-pod-name` + `kubernetes-pod-uid` ### Disable session tags AWS compresses inline session policies, managed policy ARNs, and session tags into a packed binary format that has a separate limit. If you receive a `PackedPolicyTooLarge` error indicating the packed binary format has exceeded the size limit, you can attempt to reduce the size by disabling the session tags added by EKS Pod Identity. To disable these session tags, follow these steps: 1. Open the [Amazon EKS console](https://console.aws.amazon.com/eks/home#/clusters). 1. In the left navigation pane, select **Clusters**, and then select the name of the cluster that you want to modify. 1. Choose the **Access** tab. 1. In the **Pod Identity associations**, choose the association ID you would like to modify in **Association ID**, then choose **Edit**. 1. Under **Session tags**, choose **Disable session tags**. 1. Choose **Save changes**. ## Cross-account tags All of the session tags that are added by EKS Pod Identity are *transitive*; the tag keys and values are passed to any `AssumeRole` actions that your workloads use to switch roles into another account. You can use these tags in policies in other accounts to limit access in cross-account scenarios. For more information, see [Chaining roles with session tags](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_session-tags.html#id_session-tags_role-chaining) in the *IAM User Guide*. ## Custom tags EKS Pod Identity can’t add additional custom tags to the `AssumeRole` action that it performs. However, tags that you apply to the IAM role are always available through the same format: `${aws:PrincipalTag/` followed by the key, for example `${aws:PrincipalTag/MyCustomTag}`. **Note** Tags added to the session through the `sts:AssumeRole` request take precedence in the case of conflict. For example, say that: Amazon EKS adds a key `eks-cluster-name` and value `my-cluster` to the session when EKS assumes the customer role and You add an `eks-cluster-name` tag to the IAM role with the value `my-own-cluster`. In this case, the former takes precedence and the value for the `eks-cluster-name` tag will be `my-cluster`. # Use pod identity with the AWS SDK ## Using EKS Pod Identity credentials To use the credentials from a EKS Pod Identity association, your code can use any AWS SDK to create a client for an AWS service with an SDK, and by default the SDK searches in a chain of locations for AWS Identity and Access Management credentials to use. The EKS Pod Identity credentials will be used if you don’t specify a credential provider when you create the client or otherwise initialized the SDK. This works because EKS Pod Identities have been added to the *Container credential provider* which is searched in a step in the default credential chain. If your workloads currently use credentials that are earlier in the chain of credentials, those credentials will continue to be used even if you configure an EKS Pod Identity association for the same workload. For more information about how EKS Pod Identities work, see [Understand how EKS Pod Identity works](pod-id-how-it-works.md). When using [Learn how EKS Pod Identity grants pods access to AWS services](pod-identities.md), the containers in your Pods must use an AWS SDK version that supports assuming an IAM role from the EKS Pod Identity Agent. Make sure that you’re using the following versions, or later, for your AWS SDK: + Java (Version 2) – [2.21.30](https://github.com/aws/aws-sdk-java-v2/releases/tag/2.21.30) + Java – [1.12.746](https://github.com/aws/aws-sdk-java/releases/tag/1.12.746) + Go v1 – [v1.47.11](https://github.com/aws/aws-sdk-go/releases/tag/v1.47.11) + Go v2 – [release-2023-11-14](https://github.com/aws/aws-sdk-go-v2/releases/tag/release-2023-11-14) + Python (Boto3) – [1.34.41](https://github.com/boto/boto3/releases/tag/1.34.41) + Python (botocore) – [1.34.41](https://github.com/boto/botocore/releases/tag/1.34.41) + AWS CLI – [1.30.0](https://github.com/aws/aws-cli/releases/tag/1.30.0) AWS CLI – [2.15.0](https://github.com/aws/aws-cli/releases/tag/2.15.0) + JavaScript v2 – [2.1550.0](https://github.com/aws/aws-sdk-js/releases/tag/v2.1550.0) + JavaScript v3 – [v3.458.0](https://github.com/aws/aws-sdk-js-v3/releases/tag/v3.458.0) + Kotlin – [v1.0.1](https://github.com/awslabs/aws-sdk-kotlin/releases/tag/v1.0.1) + Ruby – [3.188.0](https://github.com/aws/aws-sdk-ruby/blob/version-3/gems/aws-sdk-core/CHANGELOG.md#31880-2023-11-22) + Rust – [release-2024-03-13](https://github.com/awslabs/aws-sdk-rust/releases/tag/release-2024-03-13) + C\$1\$1 – [1.11.263](https://github.com/aws/aws-sdk-cpp/releases/tag/1.11.263) + .NET – [3.7.734.0](https://github.com/aws/aws-sdk-net/releases/tag/3.7.734.0) + PowerShell – [4.1.502](https://www.powershellgallery.com/packages/AWS.Tools.Common/4.1.502) + PHP – [3.289.0](https://github.com/aws/aws-sdk-php/releases/tag/3.289.0) To ensure that you’re using a supported SDK, follow the installation instructions for your preferred SDK at [Tools to Build on AWS](https://aws.amazon.com/tools/) when you build your containers. For a list of add-ons that support EKS Pod Identity, see [Pod Identity Support Reference](retreive-iam-info.md#pod-id-add-on-versions). # Disable `IPv6` in the EKS Pod Identity Agent ## AWS Management Console 1. To disable `IPv6` in the EKS Pod Identity Agent, add the following configuration to the **Optional configuration settings** of the EKS Add-on. 1. Open the [Amazon EKS console](https://console.aws.amazon.com/eks/home#/clusters). 1. In the left navigation pane, select **Clusters**, and then select the name of the cluster that you want to configure the add-on for. 1. Choose the **Add-ons** tab. 1. Select the box in the top right of the EKS Pod Identity Agent add-on box and then choose **Edit**. 1. On the **Configure EKS Pod Identity Agent** page: 1. Select the **Version** that you’d like to use. We recommend that you keep the same version as the previous step, and update the version and configuration in separate actions. 1. Expand the **Optional configuration settings**. 1. Enter the JSON key `"agent":` and value of a nested JSON object with a key `"additionalArgs":` in **Configuration values**. The resulting text must be a valid JSON object. If this key and value are the only data in the text box, surround the key and value with curly braces `{ }`. The following example shows network policy is enabled: ``` { "agent": { "additionalArgs": { "-b": "169.254.170.23" } } } ``` This configuration sets the `IPv4` address to be the only address used by the agent. 1. To apply the new configuration by replacing the EKS Pod Identity Agent pods, choose **Save changes**. Amazon EKS applies changes to the EKS Add-ons by using a *rollout* of the Kubernetes `DaemonSet` for EKS Pod Identity Agent. You can track the status of the rollout in the **Update history** of the add-on in the AWS Management Console and with `kubectl rollout status daemonset/eks-pod-identity-agent --namespace kube-system`. `kubectl rollout` has the following commands: ``` $ kubectl rollout history -- View rollout history pause -- Mark the provided resource as paused restart -- Restart a resource resume -- Resume a paused resource status -- Show the status of the rollout undo -- Undo a previous rollout ``` If the rollout takes too long, Amazon EKS will undo the rollout, and a message with the type of **Addon Update** and a status of **Failed** will be added to the **Update history** of the add-on. To investigate any issues, start from the history of the rollout, and run `kubectl logs` on a EKS Pod Identity Agent pod to see the logs of EKS Pod Identity Agent. 1. If the new entry in the **Update history** has a status of **Successful**, then the rollout has completed and the add-on is using the new configuration in all of the EKS Pod Identity Agent pods. ## AWS CLI 1. To disable `IPv6` in the EKS Pod Identity Agent, add the following configuration to the **configuration values** of the EKS Add-on. Run the following AWS CLI command. Replace `my-cluster` with the name of your cluster and the IAM role ARN with the role that you are using. ``` aws eks update-addon --cluster-name my-cluster --addon-name eks-pod-identity-agent \ --resolve-conflicts PRESERVE --configuration-values '{"agent":{"additionalArgs": { "-b": "169.254.170.23"}}}' ``` This configuration sets the `IPv4` address to be the only address used by the agent. Amazon EKS applies changes to the EKS Add-ons by using a *rollout* of the Kubernetes DaemonSet for EKS Pod Identity Agent. You can track the status of the rollout in the **Update history** of the add-on in the AWS Management Console and with `kubectl rollout status daemonset/eks-pod-identity-agent --namespace kube-system`. `kubectl rollout` has the following commands: ``` kubectl rollout history -- View rollout history pause -- Mark the provided resource as paused restart -- Restart a resource resume -- Resume a paused resource status -- Show the status of the rollout undo -- Undo a previous rollout ``` If the rollout takes too long, Amazon EKS will undo the rollout, and a message with the type of **Addon Update** and a status of **Failed** will be added to the **Update history** of the add-on. To investigate any issues, start from the history of the rollout, and run `kubectl logs` on a EKS Pod Identity Agent pod to see the logs of EKS Pod Identity Agent. # Create IAM role with trust policy required by EKS Pod Identity ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AllowEksAuthToAssumeRoleForPodIdentity", "Effect": "Allow", "Principal": { "Service": "pods.eks.amazonaws.com" }, "Action": [ "sts:AssumeRole", "sts:TagSession" ] } ] } ``` ** `sts:AssumeRole` ** EKS Pod Identity uses `AssumeRole` to assume the IAM role before passing the temporary credentials to your pods. ** `sts:TagSession` ** EKS Pod Identity uses `TagSession` to include *session tags* in the requests to AWS STS. **Setting Conditions** You can use these tags in the *condition keys* in the trust policy to restrict which service accounts, namespaces, and clusters can use this role. For the list of request tags that Pod Identity adds, see [Enable or disable session tags](pod-id-abac.md#pod-id-abac-tags). For example, you can restrict which pods can assume the role a Pod Identity IAM Role to a specific `ServiceAccount` and `Namespace` with the following Trust Policy with the added `Condition`: ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AllowEksAuthToAssumeRoleForPodIdentity", "Effect": "Allow", "Principal": { "Service": "pods.eks.amazonaws.com" }, "Action": [ "sts:AssumeRole", "sts:TagSession" ], "Condition": { "StringEquals": { "aws:RequestTag/kubernetes-namespace": [ "Namespace" ], "aws:RequestTag/kubernetes-service-account": [ "ServiceAccount" ] } } } ] } ``` 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).