What Is AWS EKS Pod Identity? A Comparison with AWS EKS IRSA
AWS has just released a new feature for EKS: Pod Identity. So what makes this feature stand out?
Before we begin, let's briefly recap how we interact with AWS services from inside an EKS Pod:
- Option 1: Create a static user and get an access/secret key -> This is the fastest and simplest approach, but it has serious security problems: the token is long-lived, so if it leaks, anyone can use it. If it's distributed across many systems, replacing/rotating it is a nightmare
- Option 2: Assign a role to the worker node: with this approach, you create a policy/role and attach it to the worker template. This lets you take advantage of the AWS STS endpoint and get a temporary token on each call, closing the security gap of the first option (no long-lived token needed). However, it has a different drawback: because the role is assigned to the worker node, every other Pod on that same worker node can use the role and has full permissions to interact with AWS services
- Option 3: IAM Roles for Service Accounts (IRSA): EKS needs to enable an OIDC provider that is trusted in the AWS IdP, then each IAM role needs a trust condition pointing to the EKS service account, and finally you add an annotation to the service account and assign the service account to the Pod. This way, we get fine-grained control of IAM role access down to the Pod level. The downside, however, is that the setup is fairly complex: in addition to changes outside the EKS cluster (roles, trusted OIDC provider, ...), we also need to modify service account annotations. On top of that, when multiple EKS clusters exist in the same account, things get increasingly complex and you run into limits on the AWS side
Method | How it works | Pros | Cons & Risks |
Option 1: Static User | Create an IAM user, get the | • Fastest. • Simple and easy to implement. | • Poor security: Uses a long-lived token (if the key leaks, anyone can use it). • Hard to operate: Rotating keys that are distributed across many systems is complex and time-consuming. |
Option 2: IAM Role for the Worker Node | Create an IAM role/policy and attach it to the worker node (EC2 instance profile). Uses AWS STS to obtain tokens. | • More secure than Option 1: Uses temporary tokens, so there's no more worry about long-lived credentials. | • Violates the principle of least privilege: Because the role is attached to the node, all Pods running on that node can use the role, creating a major security risk if any one Pod is compromised. |
Option 3: IRSA (IAM Roles for Service Accounts) | Combines an OIDC provider, an AWS IAM trust policy, and a Kubernetes service account (via an annotation). | • Highest security: Fine-grained access control down to the Pod level. • Follows the principle of least privilege. | • Complex configuration: Requires setting up many components (OIDC, trust relationship, K8s service account...). • Hard to scale: Managing many clusters in the same account gets complicated and can hit AWS-side limits. |
And that's why AWS launched EKS Pod Identity
- Above is how Pod Identity works. To enable Pod Identity for your EKS cluster, you need to install the Pod Identity Agent add-on:
- A Pod Identity DaemonSet will then run a pod on every worker node AND inject the Pod Identity Webhook
- Next, you need to create a Pod Identity association (via the console, API, ...) and attach it to a service account: example
- When a Pod is created, the Pod Identity Webhook modifies the Pod spec by injecting additional environment variables
- The AWS SDK running in the Pod then detects them and calls the Pod Identity Agent, which in turn calls the EKS Auth API to validate the request and return a temporary token
- Finally, the SDK uses the token it just obtained to access AWS services
In addition, here are the differences between Pod Identity and IRSA:
Feature | EKS Pod Identity | IRSA |
|---|---|---|
Role Extensibility | No need to update the role's trust policy for each new cluster. | Need to update role's trust policy with new EKS cluster OIDC provider endpoint. |
Cluster Scalability | No need to setup IAM OIDC provider. | Need to setup IAM OIDC provider. Default global limit of 100 OIDC providers for AWS account applies. |
Role Scalability | No need to define trust relationship between IAM role and service account in the trust policy. | Need to define trust relationship between IAM role and service account in the trust policy. Max of 8 trust relationships within a single trust policy applies due to limit on trust policy size. |
Role Reusability | AWS STS temporary credentials supplied by EKS Pod Identity include role session tags, such as cluster name, namespace, service account name. | AWS STS session tags are not supported. You can reuse a role across clusters, but every pod receives all of the role's permissions. |
Supported environments | Only available on Amazon EKS. | IRSA can be used with Amazon EKS, Amazon EKS Anywhere, Red Hat OpenShift Service on AWS, and self-managed Kubernetes clusters on Amazon EC2 instances. |
Supported EKS versions | EKS Kubernetes versions 1.24 or later. | All supported EKS cluster versions. |
