Select your cookie preferences

We use essential cookies and similar tools that are necessary to provide our site and services. We use performance cookies to collect anonymous statistics, so we can understand how customers use our site and make improvements. Essential cookies cannot be deactivated, but you can choose “Customize” or “Decline” to decline performance cookies.

If you agree, AWS and approved third parties will also use cookies to provide useful site features, remember your preferences, and display relevant content, including relevant advertising. To accept or decline all non-essential cookies, choose “Accept” or “Decline.” To make more detailed choices, choose “Customize.”

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
Comments
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
Image not found
EKS Add-ons
Image not found
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
Image not found
IAM role with principal
Image not found
Agent Add-on

 
Image not found
Permissions
Image not found
IAM role creation
3. Map the role directly to the desired ServiceAccount in the Amazon EKS
Image not found
pod identity association
Image not found
Pod Identity Association
Time to Test :
Lets create POD and Service Account :
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
apiVersion: v1
kind: Namespace
metadata:
name: dev-ns
---
apiVersion: v1
kind: ServiceAccount
metadata:
name: dev-sa
namespace: dev-ns
---
apiVersion: v1
kind: Pod
metadata:
name: dev-pod
namespace: dev-ns
spec:
containers:
- name: aws-cli
image: amazon/aws-cli:latest
command: ['sleep', '36000']
restartPolicy: Never
serviceAccountName: dev-sa
Apply your manifest file
1
2
3
4
$ kubectl apply -f pod.yaml
namespace/dev-ns created
serviceaccount/dev-sa created
pod/dev-pod created
Check Access to S3 bucket
1
2
3
4
kubectl -n dev-ns exec -it dev-pod -- /bin/bash
bash-4.2# aws s3 ls
2024-01-01 15:29:34 cloudformation-deployment-123123
2024-01-01 16:40:56 terraform-deployment-123123
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

Comments

Log in to comment