Exploring the new EKS Pod Identity Associations

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.

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"
            ]
        }
    ]
}

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

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

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

Uploding a file on our S3 Bucket

aws s3 cp test.txt s3://mybombaybucket

References

eksctl docs

eks pod identities

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.

Site Terms, Privacy, and more.

Exploring the new EKS Pod Identity Associations

Comments