One of the most common mistakes I see in Kubernetes environments is this:
A pod needs access to AWS services, so teams simply attach permissions to the EC2 worker node and call it a day.
It works.
Until one compromised pod suddenly has access to everything the node can access.
That’s when I started appreciating the beauty of IRSA (IAM Roles for Service Accounts) in Amazon EKS.
What is IRSA?
IRSA enables Kubernetes pods running in Amazon EKS to securely access AWS services using dedicated IAM roles.
Instead of storing AWS Access Keys inside Kubernetes Secrets or relying on broad node-level permissions , each workload can assume its own IAM role using a Kubernetes Service Account.
How does it work?
Create an IAM Role with required permissions
Configure the EKS OIDC Provider
Associate the IAM Role with a Kubernetes Service Account
Deploy pods using that Service Account
AWS STS issues temporary credentials to the pod
Pod accesses AWS services securely
No static credentials.
No credential rotation headaches.
No shared node permissions.
Why IRSA Matters
- Eliminates AWS Access Keys from Kubernetes
- Enforces Least-Privilege Access
- Temporary Credentials issued by AWS STS
- Better Auditability with CloudTrail
- Reduced Blast Radius if a Pod is Compromised
- Each Workload Gets Its Own Identity
IRSA vs Node IAM Roles
Node IAM Roles
• All pods inherit node permissions
• Difficult to isolate workloads
• Larger attack surface
• Harder to determine which workload accessed AWS resources
IRSA
• Per-workload IAM permissions
• Better security boundaries
• Improved compliance and auditing
• Fine-grained access control
Real-World Example
Imagine an EKS cluster running:
Payment Service → Access to DynamoDB
Reporting Service → Access to S3
Notification Service → Access to SQS
With Node IAM Roles, all three services could potentially access all resources.
With IRSA, each service receives only the permissions it actually needs.
That’s security done right.!!
"The Bigger Lesson"
Cloud security is moving away from: "Long-lived credentials" To "Identity-based access"
Whether it’s:
• IRSA in EKS
• OIDC in GitHub Actions
• Workload Identity in GCP
• Managed Identities in Azure
The future is the same:
"Stop distributing secrets. Start distributing identities."
How are you managing AWS access for Kubernetes workloads today?