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

eksctl utils associate-iam-oidc-provider \

--cluster my-cluster \

--approve

Step 2: Create an IAM Role

{
  "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

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

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

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.