EKS Pod Identity Agent is a new way to manage IAM roles for pods, designed to replace the older IAM Roles for Service Accounts (IRSA) mechanism.
Let’s see it in action. Imagine you have a pod that needs to access an S3 bucket.
First, you need to create an IAM role that has the necessary permissions for S3 access. Let’s say this role is named s3-reader-role.
{
"Version": "2012-01-01",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::your-bucket-name",
"arn:aws:s3:::your-bucket-name/*"
]
}
]
}
Next, you create an IAM Identity Provider for your EKS cluster if you haven’t already. This is a one-time setup.
Then, you create a Kubernetes ServiceAccount. This ServiceAccount will be associated with the IAM role.
apiVersion: v1
kind: ServiceAccount
metadata:
name: s3-reader-sa
namespace: default
Now, you attach the IAM role to this ServiceAccount using an annotation. This is where the Pod Identity Agent comes in. Instead of the older eks.amazonaws.com/role-arn annotation, you’ll use a new annotation that points to the IAM role.
apiVersion: v1
kind: ServiceAccount
metadata:
name: s3-reader-sa
namespace: default
annotations:
pod-identity.eks.amazonaws.com/role: arn:aws:iam::111122223333:role/s3-reader-role
Finally, you configure your pod to use this ServiceAccount.
apiVersion: v1
kind: Pod
metadata:
name: s3-access-pod
namespace: default
spec:
serviceAccountName: s3-reader-sa
containers:
- name: app
image: amazon/aws-cli:latest # Example image that can use AWS credentials
command: ["aws", "s3", "ls", "s3://your-bucket-name"]
When the pod starts, the EKS Pod Identity Agent, running as a daemonset on your cluster nodes, intercepts the request for AWS credentials. It then uses the annotation on the ServiceAccount to find the corresponding IAM role. The agent exchanges these Kubernetes identities for temporary AWS credentials, which are then injected into the pod’s environment. This means your application inside the pod can make authenticated calls to AWS services using the permissions granted by s3-reader-role without needing to manage static credentials or IAM users.
The core problem this solves is the secure and dynamic provisioning of AWS credentials to pods running on EKS. Traditionally, this involved complex configurations or less secure methods like embedding access keys. IRSA improved this by leveraging IAM roles, but Pod Identity Agent streamlines it further. It decouples the IAM role from the pod’s definition by associating it with a ServiceAccount, making role management more flexible. The agent handles the complex credential exchange process automatically, ensuring that pods always have up-to-date, temporary credentials.
The Pod Identity Agent doesn’t directly inject credentials as environment variables. Instead, it leverages the AWS SDK’s credential provider chain. When an SDK-enabled application running in the pod requests credentials, it checks various sources, including a specific file path managed by the agent. This file contains information that allows the SDK to make an STS (Security Token Service) call to obtain temporary credentials, effectively acting as an intermediary. This design allows applications to continue using their existing AWS SDK configurations without modification, as long as they are configured to use the default credential provider chain.
The next step is to understand how to configure fine-grained access policies for your pods using this new mechanism.