1 min lesson
IRSA: pods get their own scoped role
Give a practical answer to this: "A teammate proposes attaching the S3 and DynamoDB policies your app needs to the EKS node IAM role 'because it's simpler.' Why is that a poor default and what do you propose instead?"
Step 1 of 2
IRSA: pods get their own scoped rolethe EKS-specific answer
The naive way to give a pod AWS access is to attach a policy to the node's instance role. Then every pod on that node inherits it and one compromised container can act as all of them. IRSA (IAM Roles for Service Accounts) fixes this: the pod's Kubernetes service account is bound to an IAM role through an OIDCOpenID Connect. The modern single sign-on standard, built as an identity layer on top of OAuth 2.0. Where SAML is XML and enterprise-legacy, OIDC is JSON and what newer tools implement first. Press Enter for the full definition. provider, so each workload assumes its own scoped role and gets short-lived credentials.
- Approach
- Node instance role
- Who gets the permissions
- Every pod on the node
- Blast radius
- Whole node's workload set
- Approach
- IRSA / Pod Identity
- Who gets the permissions
- Only the bound service account
- Blast radius
- One workload
- Approach
- Long-lived keys in image
- Who gets the permissions
- Anyone who reads the image
- Blast radius
- Anywhere, until the key is rotated
| Approach | Who gets the permissions | Blast radius |
|---|---|---|
| Node instance role | Every pod on the node | Whole node's workload set |
| IRSA / Pod Identity | Only the bound service account | One workload |
| Long-lived keys in image | Anyone who reads the image | Anywhere, until the key is rotated |
IRSA (or EKS Pod Identity) is the default; node-role permissions and baked-in keys are anti-patterns.
Never bake long-lived access keys into a container image or a committed config. Images get shared, cached and scanned; a key in layer history is a key forever until rotated. Use IRSA for AWS access and a secrets manager for everything else, with rotation on a schedule.