AWS Logo
Menu
AWS: EKS Pod Identity feature , a better approach compared to IRSA

AWS: EKS Pod Identity feature , a better approach compared to IRSA

AWS: EKS Pod Identity feature , a better approach compared to IRSA

kuberneteseksawsreinvent2023tutorialsaws
Tariq A Sheikh
Published Jan 30, 2024
AWS ReInvent:2023 released a new feature, EKS Pod Identity, that aims to simplify granting AWS services access to pods running in an EKS cluster. In this post, I will deep dive into this feature, how to enable it and how it can help solve growing challenges for managing permissions across many of your EKS clusters.
Previous Approach : IRSA
Previously, applications in a pod leveraged Identity and Access Management (IAM) permissions to make API requests to AWS services. AWS released IAM roles for Service Accounts (IRSA) which allows users to leverage existing Kubernetes workload identities to securely retrieve temporary AWS credentials and access AWS services.
Simply put, we used the IAM Roles for Service Accounts (IRSA) model, where in order to give a pod access to S3 buckets or RDS database, we had to create follow these steps (as per documentation) :
  1. Create a cluster with eksctl and OIDC provider setup enabled.
  2. Create an IAM role defining access to the target AWS services, for example S3, and annotate a service account with said IAM role.
  3. Configure your pods by using the service account created in the previous step and assume the IAM role.
IRSA approach limitations
There can be mulitude of issues while configuring IRSA i.e. Errors in trust policy specifying OIDC provider, Errors in ServiceAccount (ARN of role). Also, an IAM role was restricted to an EKS cluster
New Approach : EKS Pod Identity
EKS Pod Identity allows you to use the AWS API to define permissions that specific Kubernetes service accounts should have in AWS , follow following steps :
  1. Install Amazon EKS Pod Identity Agent add-on using the Amazon EKS console or AWS Command Line Interface (AWS CLI).
  2. Create an IAM Role, and in the Trust Policy of which we now use Principal: pods.eks.amazonaws.com as the service principal
  3. Map the role directly to the desired ServiceAccount in the Amazon EKS console, APIs, or AWS CLI.
Goal :
We will create a POD in EKS cluster and test its access to AWS service i.e. S3 bucket using EKS Pod Identity Feature.
Configuration Guidelines :
  1. Install Amazon EKS Pod Identity Agent add-on from list of given add-ons
EKS Add-ons
EKS Add-ons
EKS Pod Identity Agent
EKS Pod Identity Agent
2. Create an IAM Role, and in the Trust Policy of which we now use Principal: pods.eks.amazonaws.com as the service principal
IAM role with principal
IAM role with principal
Agent Add-on
Agent Add-on

 
Permissions
Permissions
IAM role creation
IAM role creation
3. Map the role directly to the desired ServiceAccount in the Amazon EKS
pod identity association
pod identity association
Pod Identity Association
Pod Identity Association
Time to Test :
Lets create POD and Service Account :
Apply your manifest file
Check Access to S3 bucket
Feature Support in popular IaCs (Terraform/CloudFormation)
For folks out there who prefer to use IaC (Infrastructure as Code) , you can use terraform to deploy EKS Pod Identity feature as well
Terraform - aws_eks_pod_identity_association
CloudFormation - AWS::EKS::PodIdentityAssociation
Conclusion:
EKS Pod Identity provides a new and better way to grant access to AWS resources to a pod running in a cluster. While IRSA is still out there and useful, it can be deduced that EKS Pod Identity feature provides an easier way to achieve the same outcome.
References:
Always refer to annoucements and official documentation for feature details/restrictions/limitations
 

Comments