logo
Exploring the new EKS Pod Identity Associations

Exploring the new EKS Pod Identity Associations

Amazon EKS team has added a new feature called Pod Identity Associations which helps Kubernetes Applications to manage IAM Credentials with more ease. In EKS Pod Identity we map a role to a service account in a namespace and configure our application to use that service account. We can achieve this by directly communicating with the EKS API rather than the IAM API which eliminates the need to modify IAM Role Trust Policy and with no need to reference an OIDC Provider.

Published Jan 7, 2024
Pre-Requisites
  • An EKS Cluster (v1.27) with the latest platform version.
  • An IAM User/Role with necessary permissions to call the EKS API, create an S3 Bucket, create/update an IAM Role.
  • eksctl (0.167.0).
Installing eks-pod-identity-agent addon
For Pod Idenity Associations to work we need to install an addon to our cluster.
eksctl create addon --cluster eks-demo-cluster --name eks-pod-identity-agent --region ap-south-1
Creating an S3 Bucket
I created an S3 Bucket by the name of mybombaybucket to be used for this demo.
My S3 Bucket
Creating an IAM Role
I created an IAM Role by the name of S3-Edit-Role-for-Pod with a custom trust policy and an inline policy attached to it.
Trust Policy:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "pods.eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
]
}
]
}
Inline Policy:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"s3:ListAccessPointsForObjectLambda",
"s3:GetAccessPoint",
"s3:PutAccountPublicAccessBlock",
"s3:ListAccessPoints",
"s3:CreateStorageLensGroup",
"s3:ListJobs",
"s3:PutStorageLensConfiguration",
"s3:ListMultiRegionAccessPoints",
"s3:ListStorageLensGroups",
"s3:ListStorageLensConfigurations",
"s3:GetAccountPublicAccessBlock",
"s3:ListAllMyBuckets",
"s3:ListAccessGrantsInstances",
"s3:PutAccessPointPublicAccessBlock",
"s3:CreateJob"
],
"Resource": "*"
},
{
"Sid": "VisualEditor1",
"Effect": "Allow",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::mybombaybucket/*",
"arn:aws:s3:::mybombaybucket"
]
}
]
}
My IAM Role
Creating a Service Account
I created a new service account in the default namespace with the above IAM Role attached to it, and we shall later link this service account to our pod.
1
2
3
4
5
6
7
apiVersion: v1
kind: ServiceAccount
metadata:
annotations:
eks.amazonaws.com/role-arn: arn:aws:iam::<ACCOUNTID>:role/S3-Edit-Role-for-Pod
name: my-serviceaccount
namespace: default
Listing Service Accounts in default namespace
Creating a Pod linking custom Service Account
kubectl run ubuntu --image=ubuntu --overrides='{ "spec": { "serviceAccount": "my-serviceaccount" } }' -- sleep 3600
Listing Pods in the default namespace
Execing into the Pod and accessing S3
kubectl exec -it ubuntu -- /bin/bash
Installing curl, unzip and aws-cli
apt update && apt install unzip curl -y
curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
unzip awscliv2.zip
./aws/install
aws-cli installed
At this moment, we can check the sts get-caller-identity
To get the output of this command I was facing some issue running export AWS_PAGER="" fixed the issue.
aws sts get-caller-identity
Assumed Role within the Pod
Uploding a file on our S3 Bucket
aws s3 cp test.txt s3://mybombaybucket
File uploaded to S3 Bucket
File Uploaded from Pod to S3 Bucket
References
Conclusion
Pod Identity Associations will help us to map a single IAM Role to multiple clusters without the need to update trust policy. We can also replicate effortlessly the pod identity associations across pods in multiple clusters. Additionally it will give us a lot of security benefits such as Least Privilege, Credential Isolation, Auditability, Reusability and better Scalability.