EKS Pod Identity or IAM Roles for Service Accounts (IRSA) ?

EKS Pod Identity or IAM Roles for Service Accounts (IRSA) ?

Photo by Isfak Himu on Unsplash

Managing secure access to AWS resources has always been a major concern in EKS and a headache for cluster administrators. IRSAs (IAM Roles for Service Accounts), which we’ve covered in detail in this article , have been very useful in facilitating this process since their introduction in 2019, but had many limitations and required significant configuration and maintenance effort.

Then, AWS introduced EKS Pod Identity at the end of2023 , which was a major step forward in simplifying and improving this process. This article looks at what EKS Pod Identity is, how it works and why it’s a game-changer for Kubernetes developers and administrators.

What is Amazon EKS Pod Identity?

Amazon EKS Pod Identity is a new feature that further simplifies the way cluster administrators configure Kubernetes applications to get AWS IAM permissions. It builds on the foundations established by IRSA, but offers a more streamlined approach.

Key aspects of EKS Pod Identity include:

1. Simplified Configuration : Permissions can now be easily configured with fewer steps directly through the EKS console, APIs, and CLI.
2. No OIDC Requirement : Unlike IRSA, EKS Pod Identity doesn’t require setting up an OpenID Connect (OIDC) provider for each cluster.
3. Direct Role-to-Service Account Mapping : EKS Pod Identity allows mapping of IAM roles to service accounts directly in the Amazon EKS console, APIs, or AWS CLI.
4. Cross-Cluster Role Usage : It’s easy to use an IAM role across multiple clusters without updating the role trust policy for each new cluster.
5. Pod Identity Agent : EKS Pod Identity introduces a new component called the Pod Identity Agent that runs as a DaemonSet in the cluster.
6. Role Session Tags : Supports role session tags with attributes such as cluster name, namespace, and service account name.

How Does EKS Pod Identity Work?

The EKS Pod Identity process can be split into the following steps:

1. A pod (the application’s AWS SDK/CLI) requests credentials from the EKS Pod Identity Agent.
2. The pod identity agent calls the Auth EKS AssumeRoleForPodIdentity API, which validates the identity association.
3. After validation, the EKS Auth API calls STS to provide temporary AWS credentials, which it sends back to the pod identity agent.
4. The identity agent passes these credentials to the pod.
5. The pod can now use these temporary credentials to access AWS resources.

This process ensures secure, ephemeral access to AWS resources without the headaches of managing long-term credentials.

Benefits of EKS Pod Identity

1. Simplified Workflow : Cluster administrators no longer need to switch between Amazon EKS and IAM services to authenticate applications to AWS resources.
2. Reduced Configuration Overhead : Eliminates the need for OIDC provider setup and trust policy updates for each new cluster.
3. Improved Scalability : Easier to manage permissions across multiple clusters and namespaces.
4. Enhanced Security : Maintains the principle of least privilege while simplifying the implementation process.
5. Kubernetes-Native Management : Allows for more centralized and Kubernetes-native management of IAM role associations.

How To Setup EKS Pod Identity ?

The process of implementing EKS Pod Identity can be broken down into three simple steps:

0 — Prerequisites:

1. The cluster verison must be ≥ 1.24 (refer to this doc for more details )
2. The identity Agent Daemon works only on the worker nodes that are Linux Amazon EC2 instances.
3. The applicatin should use the latest AWS SDKs (refer to this doc for more details )
4. The EC2 node must have the permissions for the agent to do AssumeRoleForPodIdentity action in the EKS Auth API.

    {  
        "Version": "2012-10-17",  
        "Statement": [  
            {  
                "Effect": "Allow",  
                "Action": [  
                    "eks-auth:AssumeRoleForPodIdentity"  
                ],  
                "Resource": "*"  
            }  
        ]  
    }

1 — Create an IAM Role :

Create an IAM role with the required permissions for your application and specify pods.eks.amazonaws.com as the service principal in its trust policy.

    {  
        "Version": "2012-10-17",  
        "Statement": [  
            {  
                "Effect": "Allow",  
                "Principal": {  
                    "Service": "pods.eks.amazonaws.com"  
                },  
                "Action": [  
                    "sts:AssumeRole",  
                    "sts:TagSession"  
                ]  
            }  
        ]  
    }

2 — Install the EKS Pod Identity Agent :

Install the Amazon EKS Pod Identity Agent add-on using the Amazon EKS console or AWS Command Line Interface (AWS CLI).

Amazon EKS console — Add-ons tab

    aws eks create-addon --cluster-name <cluster-name> --addon-name eks-pod-identity-agent --addon-version v1.0.0-eksbuild.1

3 — Map the Role to a Service Account :

Map the IAM role to a Kubernetes service account directly in the Amazon EKS console, APIs, or AWS CLI.

Using Terraform

You can also use terraform to manage these association with Iac using this module from terraform-aws-modules .

Once these steps are completed, any new pods that use the associated service account will automatically be configured to receive IAM credentials.

Migrating from IRSA to EKS Pod Identity

For those already using IRSA, migration to EKS Pod Identity is straightforward:

1. Upgrade your EKS cluster to version 1.24 or later.
2. Install the EKS Pod Identity Agent Add-on.
3. Update your applications to use supported AWS SDK versions.
4. Modify your IAM roles’ trust policies to include the new EKS service principal.
5. Create EKS Pod Identity associations using the new API.

Conclusion

Amazon EKS Pod Identity represents a significant improvement in IAM authorization management for Kubernetes workloads on AWS. It simplifies configuration and improves scalability and security compared to IRSA. EKS Pod Identity is recommended if you meet the prerequisites for a more streamlined, secure and scalable approach to IAM authorization management.
And for those who can’t meet the conditions yet, and are waiting for future updates, IRSA remains a viable alternative.

ℹ️Architecture diagram in raw format is available here : aws-morocco-samples/aws-eks-pod-identity/materials at main · Z4ck404/aws-morocco-samples

EKS Pod Identity or IAM Roles for Service Accounts (IRSA)? was originally published in AWS Morocco on Medium, where people are continuing theconversation by highlighting and responding to this story.