# How to secure Kubernetes workloads using Pod Identity

By Ilya Pisatzkov

Solution Architect

When running workloads in Kubernetes, applications often need to interact with external cloud services -like pulling data from an S3 bucket.

Traditionally, this meant hardcoding secrets or access keys into pods, which is risky, hard to rotate, and painful to manage at scale. **In short, the old approach tied application identity directly to long-lived secrets, which doesn’t scale well and introduces security risks.**

Pod Identity solves this by giving pods a secure, temporary identity without relying on static credentials.

## **What is Pod Identity?**

Pod Identity is a way to connect Kubernetes Service Accounts with cloud provider identities (like AWS IAM Roles).

This means that instead of storing access keys inside your pod, the pod automatically receives short-lived credentials from the cloud provider — securely and transparently.

Think of it like a digital passport –  this is known as the **“identity federation”** concept:

- The **Kubernetes Service Account** is the pod’s _passport holder_.
- The **IAM Role / Cloud Identity** is the _visa_ that grants access to specific destinations (cloud services).
- The pod presents this identity whenever it makes a request, and the cloud validates it.

## **AWS: Two Mechanisms**

In AWS EKS, there are two ways to implement Pod Identity:

### **1. IRSA (IAM Roles for Service Accounts) — the old way**

- Introduced in 2019.
- Works by linking a Service Account → IAM Role using an OIDC provider.
- Requires extra setup (OIDC provider, IAM trust policy, annotations).
- Still widely used today and fully supported.

### **2. EKS Pod Identity — the new way**

- Launched at AWS re:Invent 2023.
- Natively integrates with EKS, no OIDC provider required.
- You create **Pod Identity Associations** between Service Accounts and IAM Roles (AWS entity — typically provisioned via Terraform).
- Simpler, less error-prone, and recommended for new clusters.

👉 **In short:**

- **IRSA** = battle-tested but more complex.
- **EKS Pod Identity** = the new, preferred method.

## **Example: IRSA in Action**

If you’re on an existing cluster and still using IRSA, here’s how it works:

**Step 1: Enable OIDC for Your EKS Cluster**

```shell
eksctl utils associate-iam-oidc-provider \

--cluster my-cluster \

--approve
```

**Step 2: Create an IAM Role**

```json
{
  "Version": "2012-10-17",
  "Statement": [\
    {\
      "Effect": "Allow",\
      "Action": ["s3:GetObject"],\
      "Resource": ["arn:aws:s3:::my-app-bucket/*"]\
    }\
  ]
}
```

**Step 3: Link Service Account to the Role**

```yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  name: s3-reader
  namespace: default
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/S3ReadOnlyRole
```

**Step 4: Deploy a Pod Using the Service Account**

```yaml
apiVersion: v1
kind: Pod
metadata:
  name: s3-test
spec:
  serviceAccountName: s3-reader
  containers:
    - name: aws-cli
      image: amazon/aws-cli
      command: ["sh", "-c", "aws s3 ls s3://my-app-bucket"]
```

**Example: EKS Pod Identity (Recommended)**

With EKS Pod Identity, the steps are simpler:

**Step 1: Create a Pod Identity Association**

```shell
aws eks create-pod-identity-association \

--cluster-name my-cluster \

--namespace default \

--service-account s3-reader \

--role-arn arn:aws:iam::123456789012:role/S3ReadOnlyRole
```

**Step 2: Deploy a Pod** No annotations required – just use the Service Account.

EKS handles the identity mapping automatically.

**Benefits of Pod Identity (Both IRSA & EKS Pod Identity)**

- **No static secrets** → Credentials are short-lived and auto-rotated.
- **Auditability** → AWS CloudTrail logs clearly show which IAM role (and therefore which pod identity) accessed a resource.
- **Security by design** → No need to embed keys; access is granted per pod.
- **Least privilege** → Assign the minimal IAM policy needed to each workload.

**Final Thoughts**

Pod Identity is becoming the **widely adopted method** for secure access in AWS Kubernetes environments.

On AWS, **IRSA** has been the go-to method for years, but **EKS Pod Identity** is the newer, simpler, and recommended approach for new deployments.