Amazon EKS Pod Identity Lab

By /

EKS Pod Identity is the newer, streamlined alternative to IRSA. Unlike IRSA, it does not require configuring an OIDC provider for the cluster, and it does not require annotating Kubernetes Service Accounts with IAM Role ARNs.

Install the EKS Pod Identity Agent, create an IAM role with the correct trust policy, map it to a Kubernetes Service Account using Pod Identity Associations, and verify S3 access from a test Pod.

Prerequisites

  • An active Amazon EKS cluster (Kubernetes version 1.24 or later).
  • kubectl, eksctl, and aws CLI tools configured and authenticated.

Step 1: Install the EKS Pod Identity Agent Add-on

EKS Pod Identity requires a specific add-on running on your worker nodes to intercept the AWS credential requests from pods.

Bash
export CLUSTER_NAME="my-eks-cluster"
export AWS_REGION="us-east-1"

eksctl create addon \
    --cluster $CLUSTER_NAME \
    --name eks-pod-identity-agent \
    --region $AWS_REGION \
    --approve

Step 2: Create the IAM Role and Trust Policy

EKS Pod Identity uses a different trust policy than IRSA. Instead of trusting an OIDC provider, it trusts the pods.eks.amazonaws.com service principal.

1: Create the Trust Policy document:

Bash
cat <<EOF > trust-policy.json
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "pods.eks.amazonaws.com"
            },
            "Action": [
                "sts:AssumeRole",
                "sts:TagSession"
            ]
        }
    ]
}
EOF

2: Create the IAM Role:

Bash
ROLE_ARN=$(aws iam create-role \
    --role-name EKSPodIdentityS3Role \
    --assume-role-policy-document file://trust-policy.json \
    --query 'Role.Arn' \
    --output text)

echo $ROLE_ARN

3: Attach a Permissions Policy: For this lab, we will attach the AWS-managed ReadOnly S3 policy.

Bash
aws iam attach-role-policy \
    --role-name EKSPodIdentityS3Role \
    --policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess

Step 3: Create the Pod Identity Association

This step links your IAM Role to a specific Kubernetes Namespace and Service Account directly within the AWS API.

Bash
aws eks create-pod-identity-association \
    --cluster-name $CLUSTER_NAME \
    --role-arn $ROLE_ARN \
    --namespace default \
    --service-account pod-id-sa

Step 4: Deploy the Kubernetes Resources

Notice that unlike IRSA, the Kubernetes Service Account does not need an eks.amazonaws.com/role-arn annotation. The EKS Pod Identity Agent handles the mapping automatically based on the association created in Step 3.

Bash
cat <<EOF > test-pod-identity.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  name: pod-id-sa
  namespace: default
---
apiVersion: v1
kind: Pod
metadata:
  name: aws-cli-pod-identity
  namespace: default
spec:
  serviceAccountName: pod-id-sa
  containers:
  - name: aws-cli
    image: amazon/aws-cli:latest
    command: ["sleep", "3600"]
  restartPolicy: Never
EOF

kubectl apply -f test-pod-identity.yaml

Wait for the Pod to be in the Running state:

Bash
kubectl get pods aws-cli-pod-identity -w

Step 5: Verify EKS Pod Identity Configuration

Exec into the Pod to verify that credentials are being successfully intercepted and vended by the Pod Identity Agent.

1: Verify Identity: Check which IAM role the Pod is assuming.

Bash
kubectl exec -it aws-cli-pod-identity -- aws sts get-caller-identity

Expected Output: The Arn should reflect an assumed role based on EKSPodIdentityS3Role, formatted like arn:aws:sts::<ACCOUNT_ID>:assumed-role/EKSPodIdentityS3Role/eks-....

2: Test S3 Access:

Bash
kubectl exec -it aws-cli-pod-identity -- aws s3 ls

Expected Output: A list of S3 buckets in your account.

3: Check the Environment (Optional Validation): With EKS Pod Identity, you will notice that AWS SDKs use a different credential provider chain variable.

Bash
kubectl exec -it aws-cli-pod-identity -- env | grep AWS_CONTAINER_AUTHORIZATION_TOKEN

Expected Output: You should see an environment variable pointing to the token file managed by the Pod Identity agent, rather than the AWS_WEB_IDENTITY_TOKEN_FILE used by IRSA.

    Step 6: Teardown

    Remove the resources to clean up your environment.

    Bash
    # Delete Kubernetes resources
kubectl delete -f test-pod-identity.yaml

# Delete the Pod Identity Association
ASSOCIATION_ID=$(aws eks list-pod-identity-associations --cluster-name $CLUSTER_NAME --namespace default --service-account pod-id-sa --query 'associations[0].associationId' --output text)

aws eks delete-pod-identity-association \
    --cluster-name $CLUSTER_NAME \
    --association-id $ASSOCIATION_ID

# Detach policy and delete IAM role
aws iam detach-role-policy \
    --role-name EKSPodIdentityS3Role \
    --policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess

aws iam delete-role --role-name EKSPodIdentityS3Role

# Clean up local files
rm trust-policy.json test-pod-identity.yaml

# (Optional) Delete the add-on if you no longer need it
eksctl delete addon --cluster $CLUSTER_NAME --name eks-pod-identity-agent

    Leave a Comment

    Your email address will not be published. Required fields are marked *

    Scroll to Top