Here’s a comprehensive tutorial on how to assign AWS permissions to Pods running in Amazon EKS, covering:

• The problem it solves
• All available options
• Pros and cons of each method
• A comparison table
• Implementation guide for the recommended ones (IRSA and Pod Identity)

---

---

Problem Statement

In Kubernetes (EKS), your Pods often need to access AWS resources like:

• S3 buckets to read/write files
• DynamoDB to store session data
• VPC Lattice for service networking
• CloudWatch for logging

But how do we securely give AWS IAM permissions to a Pod?

---

The Core Challenge

Unlike EC2 instances, Pods don’t have IAM roles by default. So, we need a secure way to assign IAM permissions to Pods.

---

Available Options

Option No.	Method	Recommended	Fine-Grained	Secure	Requires OIDC	Notes
1	IAM Roles for Service Accounts (IRSA)	Yes	Yes	Yes	Yes	Widely used
2	EKS Pod Identity (Agent-based)	Yes	Yes	Yes	No	Newer method
3	EC2 Instance IAM Role	No	No	No	No	All Pods share role
4	AWS Credentials in Secrets/Env Vars	No	Yes	No	No	Insecure
5	Custom Identity Proxy/Sidecar Relay	Maybe	Yes	Yes	No	Complex, flexible

---

Option 1: IAM Roles for Service Accounts (IRSA)

How it works:

• You associate an IAM Role with a Kubernetes Service Account.
• EKS uses OIDC (OpenID Connect) to let your Pod assume that IAM role.

Prerequisites:

• EKS Cluster with OIDC provider enabled
• IAM Role with trust relationship
• Annotated Kubernetes ServiceAccount

Pros:

• Secure & fine-grained
• Widely supported in production
• Works with eksctl, Terraform, AWS CLI

Cons:

• Requires OIDC setup
• Slightly more steps

IRSA Setup Guide:

1. Enable OIDC for your cluster (only once): eksctl utils associate-iam-oidc-provider --cluster <cluster-name> --approve
2. Create IAM policy (example for S3 access): aws iam create-policy \ --policy-name MyAppS3Access \ --policy-document file://s3-policy.json
3. Create IAM role for ServiceAccount: eksctl create iamserviceaccount \ --cluster <cluster-name> \ --namespace <namespace> \ --name <sa-name> \ --attach-policy-arn arn:aws:iam::<account-id>:policy/MyAppS3Access \ --approve
4. Use the ServiceAccount in your deployment: serviceAccountName: <sa-name>

---

Option 2: EKS Pod Identity

How it works:

• Amazon EKS runs a Pod Identity Agent on each node.
• Your Pod’s ServiceAccount is annotated with an IAM role.
• The agent helps the Pod assume that IAM role — no OIDC needed.

Pros:

• No need to set up OIDC
• Easier for beginners
• Native integration, evolving fast

Cons:

• Requires Pod Identity Agent (minor extra setup)
• Newer, evolving feature

Pod Identity Setup Guide:

1. Install Pod Identity Agent: eksctl enable pod-identity --cluster <cluster-name>
2. Create IAM policy: aws iam create-policy \ --policy-name MyAppS3Access \ --policy-document file://s3-policy.json
3. Create IAM role and bind to service account: eksctl create iamidentitymapping \ --cluster <cluster-name> \ --service-name <sa-name> \ --namespace <namespace> \ --arn arn:aws:iam::<account-id>:role/MyAppS3Access
4. Annotate your ServiceAccount: kubectl annotate serviceaccount <sa-name> \ eks.amazonaws.com/role-arn=arn:aws:iam::<account-id>:role/MyAppS3Access \ -n <namespace>

---

Option 3: EC2 IAM Role for Node

How it works:

• Attach the IAM role directly to EC2 instance/node.
• All Pods on that node share the same permissions.

Why it’s bad:

• Not secure for multi-tenant or microservice workloads.
• No fine-grained control — violates least privilege.

---

Option 4: Hardcoded AWS Credentials

How it works:

• Manually inject AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY into the pod.

Why it’s risky:

• Credentials can leak
• Hard to rotate and audit
• Breaks cloud-native best practices

---

Option 5: Custom Sidecar Token Relay

How it works:

• You run a sidecar container (e.g., Vault Agent, identity proxy) alongside your app.
• The sidecar securely handles IAM calls or credential fetching.

When useful:

• Complex enterprise setups with custom identity management
• Using Vault for dynamic credential delivery

---

Final Comparison Table

Feature / Method	IRSA	Pod Identity	EC2 Role	Env Vars	Sidecar Proxy
Secure
Granular per-Pod IAM Roles
OIDC Required
Easy to Set Up	Medium	Easy			Complex
Production-ready		(new)			Yes if done right
AWS-recommended

---

Conclusion: What Should You Use?

If you’re…	Use this method
Starting fresh in 2024+	Pod Identity
Existing setup using IRSA	Stick with IRSA
Insecure or legacy app	Avoid Env/EC2 roles
Complex identity control needed	Sidecar/Proxy + Vault

---