# Rethinking Authentication: AWS ReInvent 2023 Unveils EKS Pod Identity

Two weeks ago at [AWS ReInvent](https://aws.amazon.com/about-aws/whats-new/2023/11/amazon-eks-pod-identity/), the AWS team released a new add-on for the EKS cluster. This feature simplifies the access to AWS services from EKS pods. This blog is a hands-on demonstration & exploration of this feature.

## Scenario

To demonstrate the new feature, I'll borrow a scenario from my [previous article on IRSA (IAM Roles for Service Accounts)](https://blog.rewanthtammana.com/securing-aws-eks-implementing-least-privilege-access-with-irsa#heading-scenario). In short, we will deploy an application on EKS that fetches random images from the internet every 30 seconds, & uploads them to an s3 bucket. Only this time, instead of IRSA, we will use this new feature.

```bash
IMAGE=rewanthtammana/secure-eks:pod-identity-demo
git clone https://github.com/rewanthtammana/secure-eks
cd secure-eks/pod-identity-demo
docker build -t $IMAGE .
docker push $IMAGE
```

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1702212677048/ccad27a0-fb9c-4fe8-a966-92cdae8857ba.png align="center")

## Hands-on Demo

Let's create an EKS cluster to experiment.

```yaml
#config.yaml
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig

metadata:
  name: pod-identity-demo
  region: us-east-1
  version: '1.26'

nodeGroups:
  - name: ng-general
    instanceType: t2.small
    instanceName: pod-identity-demo-node
    desiredCapacity: 1
```

```bash
eksctl create cluster -f config.yaml
```

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1702212796425/4cabef21-a258-447d-9d20-3f6946771f19.png align="center")

List the cluster.

```bash
eksctl get clusters
```

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1702205929527/af793996-cce8-4c06-87ba-c93e66358df3.png align="center")

`eksctl` integrated this new feature in its recent release. Make sure `eksctl` is updated.

```bash
eksctl version
```

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1702206031156/1cb839e7-89b6-489a-8346-0a998a737c8b.png align="center")

### Enable Add On

We need to have `eks-pod-identity-agent` addon to create a controller to use this feature.

```bash
eksctl create addon --name eks-pod-identity-agent --cluster $CLUSTER_NAME
```

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1702206514451/c489b653-cbd4-48c8-be9a-57991e626478.png align="center")

```bash
kubectl get ds -A
```

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1702206624923/863020ad-210a-4b22-bfc5-fbd523d70349.png align="center")

```bash
export SERVICE_ACCOUNT_NAME=anything
eksctl create podidentityassociation --cluster $CLUSTER_NAME --namespace default --service-account-name $SERVICE_ACCOUNT_NAME --permission-policy-arns $policy_arn
```

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1702206664021/5d8a8c06-f2fe-4310-ada9-06b2816592b6.png align="center")

```bash
aws cloudformation describe-stack-resources --stack-name eksctl-pod-identity-demo-podidentityrole-ns-default-sa-anything
```

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1702206979222/fbce0047-48ab-4636-9a01-3d72e0999a8a.png align="center")

```bash
export role_name=$(aws cloudformation describe-stack-resources --stack-name eksctl-pod-identity-demo-podidentityrole-ns-default-sa-anything | jq -r '.StackResources[].PhysicalResourceId')
echo $role_name
aws iam list-attached-role-policies --role-name $role_name
```

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1702207078257/53bf8126-4af2-40b1-ae1e-df93042ad58b.png align="center")

### Pod Identity Association

List the `podidentityassociation` in the EKS clusters.

```bash
export CLUSTER_NAME=pod-identity-demo
eksctl get podidentityassociation --cluster $CLUSTER_NAME
```

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1702205981148/a82e0cfd-51ba-4b84-bd04-5ebd567483c7.png align="center")

Create an AWS policy to write objects to an s3 bucket.

```bash
export BUCKET_NAME=random-pod-identity-demo
echo "{
    \"Version\": \"2012-10-17\",
    \"Statement\": [
        {
            \"Effect\": \"Allow\",
            \"Action\": [
                \"s3:PutObject\"
            ],
            \"Resource\": [
                \"arn:aws:s3:::$BUCKET_NAME/*\"
            ]
        }
    ]
}" > s3-$BUCKET_NAME-access.json

export POLICY_NAME=pod-identity-bucket-s3-write-policy
export create_policy_output=$(aws iam create-policy --policy-name $POLICY_NAME --policy-document file://s3-$BUCKET_NAME-access.json)
export policy_arn=$(echo $create_policy_output | jq -r '.Policy.Arn')
echo $policy_arn
```

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1702206213559/1084523c-dccb-47fe-be4a-f7fb819f60f8.png align="center")

Make the s3 bucket, create a service account that was used to create podidentityassociation & create a job using that service account to upload pictures to the s3 bucket.

```bash
aws s3 mb s3://$BUCKET_NAME --region us-east-1
kubectl create sa $SERVICE_ACCOUNT_NAME

echo "apiVersion: batch/v1
kind: Job
metadata:
  name: pod-identity-demo
spec:
  template:
    spec:
      serviceAccountName: $SERVICE_ACCOUNT_NAME
      containers:
      - name: pod-identity-demo-container
        image: rewanthtammana/secure-eks:pod-identity-demo
        env:
        - name: AWS_REGION
          value: us-east-1
        - name: S3_BUCKET_NAME
          value: $BUCKET_NAME
      restartPolicy: Never" | kubectl apply -f-
```

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1702207491885/30799d6b-1a18-485f-94b4-10ef4f9818d9.png align="center")

```bash
kubectl get jobs
kubectl get po -l job-name=pod-identity-demo
kubectl logs -l job-name=pod-identity-demo
```

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1702207626164/def0a47e-82bf-4cb1-a36e-408bd3665a08.png align="center")

## IRSA vs Pod Identity

How does this feature differ from IRSA?

To analyze, let's create a service account that will be used in an IRSA fashion.

```bash
eksctl utils associate-iam-oidc-provider \
  --cluster $CLUSTER_NAME \
  --approve
eksctl create iamserviceaccount --name irsa-demo \
  --namespace default \
  --cluster $CLUSTER_NAME \
  --attach-policy-arn $policy_arn \
  --approve
```

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1702207869319/7d890eea-6a46-46d8-81c0-da310c69c61d.png align="center")

The `anything` service account is used by the Pod Identity feature and `irsa-demo` service account. The key difference is in the annotation.

```bash
kubectl get sa
kubectl get sa $SERVICE_ACCOUNT_NAME -oyaml
kubectl get sa irsa-demo -oyaml
```

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1702207975242/b152cfaa-f1aa-4dae-952f-36f3f629b73a.png align="center")

In the case of IRSA, there's no direct way to identify the list of service accounts that are leveraging IRSA, performing actions, etc. We can definitely have automation & scripts in place to extract the required information but its tedious. With this new AWS feature, this gets a lot easier.

```bash
eksctl get podidentityassociation
```

### Inside of Pod Identity Webhook

```bash
kubectl get po
kubectl exec -it pod-identity-demo-h49cc sh
```

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1702208137422/270a522a-4cf6-46b4-a358-07cf61705d92.png align="center")

When the new feature add-on is enabled, it creates a daemon set that's responsible for all authentication operations & validations.

```bash
kubectl get ds -n kube-system eks-pod-identity-agent -oyaml
```

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1702208573305/96b76e07-d55b-48eb-a87f-4db55c35c34c.png align="center")

```bash
kubectl logs -n kube-system eks-pod-identity-agent-x5wml
```

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1702208721565/f526d4ae-dd65-4b39-9f41-9755385e1ad6.png align="center")

## Cleanup

```bash
aws iam delete-policy --policy-arn $policy_arn
aws s3 rm s3://$BUCKET_NAME --recursive
aws s3 rb s3://$BUCKET_NAME
eksctl delete cluster --name $CLUSTER_NAME
```

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1702208950974/58627432-cb94-43ac-bb41-f0bbb1d3c767.png align="center")

## Conclusion

EKS Pod Identity provides a new simplified & secure way to allow EKS pods to connect with other AWS services. Though AWS has IRSA, managing it at scale is a relatively tedious task when compared with `eks-pod-identity-agent`.

`eksctl get podidentityassociation` lists all the service accounts that are connecting with other AWS resources. Subsequently, we can list all pods using those service accounts to see which resources have elevated permissions & audit them.