Kubernetes has become the de facto standard for container orchestration in the cloud-native world. Among the various Kubernetes offerings, Amazon Elastic Kubernetes Service (EKS) stands out as a popular choice due to its seamless integration with other AWS services and its managed nature.

Recently, AWS EKS introduced a new feature called Pod Identities for Service Account (IAM integration). This feature provides enhanced security and simplifies the management of access permissions for pods running in EKS clusters. In this article, we will explore the details of this feature and how it improves the overall security of your EKS workloads. So, let’s dive in and learn more about Pod Identities for Service Account in AWS EKS!

Understanding Pod Identities

EKS Pod Identities are a feature of AWS EKS (Elastic Kubernetes Service) that allows applications running in EKS to securely access AWS resources using IAM Roles. They are similar to Amazon EC2 instance profile or Lambda execution roles, but specifically designed for Pods in EKS Cluster.

You can say ‘We already have IRSA (IAM Roles for Service Account)!’, but this feature allows for a much easier and smoother integration. Instead of managing the OIDC integration between your EKS Clusters and AWS Account individually for each pod, you can associate an IAM role with a Kubernetes service account using a Trust Policy. This service account is then used by Pods (containers) to automatically obtain the required credentials for accessing AWS services.

Our brand-new Trusted Policy Service Principal.  –> “Principal”: { “Service”: “pods.eks.amazonaws.com”}

Benefit of Pod Identities

• Increase the efficiency with seamless integration with IAM, now you can use the same IAM for different EKS Cluster. Also, it works better with multi-account strategies.
• Enhances auditability, as all actions can be traced back to specific IAM roles with CloudTrail. It offers
• Eliminates the need for third-party tools like kiam or kube2iam.

Restrictions

• You can use it with Linux AMI-based Amazon EC2 instances. Windows EKS AMIs and Fargate are not supported yet.
• Also, you can find list of  the compatible versions of Kubernetes and EKS Platform in the AWS Docs.

Step-by-step guide: Enabling and using Pod Identities in AWS EKS

1. Deploy the Amazon EKS Pod Identity Agent in your EKS Cluster

You can use following commands

Do it with AWS EKS CLI:

aws eks create-addon \
--cluster-name your-cluster-name \
--addon-name eks-pod-identity-agent \
--addon-version v1.0.0-eksbuild.1

OR with eksctl tool:

eksctl create addon --cluster your-cluster-name --name eks-pod-identity-agent

Check your deployed pods in your cluster

kubectl get pods -l app.kubernetes.io/instance=eks-pod-identity-agent -n kube-system 

2. Create an IAM Role to use with your EKS Pod Identity

Copy the following contents to a file named eks-pod-identity-role-trust-policy.json

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "pods.eks.amazonaws.com"
            },
            "Action": [
                "sts:AssumeRole",
                "sts:TagSession"
            ]
        }
    ]
}

Then create the IAM role using AWS CLI using eks-pod-identity-role-trust-policy.json

aws iam create-role \
--role-name your-pod-identity-role \
--assume-role-policy-document file://eks-pod-identity-role-trust-policy.json

Attach the required Amazon EKS managed IAM policy to the role. For instance, we’ll add AWS managed S3ReadOnlyAccess policy.

aws iam attach-role-policy \
--policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess \
--role-name your-pod-identity-role

3. Associate your pod identity role with EKS Service Account

You need to associate the IAM role with Kubernetes cluster service account and namespace.

Do it with AWS EKS CLI

aws eks create-pod-identity-association \
  --cluster-name your-cluster \
  --service-account pod-identity \
  --role-arn arn:aws:iam:::role/pod-idenity-s3-example \
  --namespace default

OR with eksctl tool

eksctl create podidentityassociation \
    --cluster your-cluster-name \
    --namespace default \
    --service-account-name s3-reader-service-account \
    --roleARN arn:aws:iam::01234567891:role/your-pod-identity-role 

4. Check the list of the identity associations

Do it with AWS EKS CLI

aws eks list-pod-identity-associations --cluster-name your-cluster-name

OR with eksctl tool

eksctl get podidentityassociation --cluster your-cluster-name

5. Have a quick test about your pod identity

Apply the following k8s manifest file

apiVersion: apps/v1
kind: Deployment
metadata:
  name: pod-identity-test
  labels:
    app: pod-identity-test
spec:
  replicas: 2
  selector:
    matchLabels:
      app: pod-identity-test
  template:
    metadata:
      labels:
        app: pod-identity-test
    spec:
      serviceAccountName: s3-reader-service-account
      containers:
      - name: s3-reader-service-account
        image: bash:5.2.21-alpine3.19
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: s3-reader-service-account
  labels:
    app: s3-reader-service-account

Apply it with kubectl

kubectl apply -f depployment.yaml

Access the bash inside your container

kubectl get pods
kubectl exec -ti your-pod-name -- bash

List your environment variables for temporary access tokens. Then print out your SERVICE_TOKEN

env | sort
cat $AWS_CONTAINER_AUTHORIZATION_TOKEN_FILE
SERVICE_TOKEN=`cat /var/run/secrets/pods.eks.amazonaws.com/serviceaccount/eks-pod-identity-token`
echo $SERVICE_TOKEN

You can also check AWS access from bash, so you can be sure it is accessing to Amazon S3.

Conclusion

In conclusion, implementing pod identities in EKS provides significant advantages in terms of security and operational overhead. By enforcing strict access controls, enabling Attribute-based access control with IAM policies, and simplifying administrative tasks, pod identities offer an effective solution for complex systems in EKS environments.