Amazon EKS Interview: Explain how IAM Roles for Service Accounts (IRSA) works internally, including the OIDC provider trust chain, and describe a production scenario where IRSA misconfiguration caused a security incident.
Quick Answer
IRSA uses a projected service account token (JWT) that is exchanged for temporary AWS credentials via STS AssumeRoleWithWebIdentity. The trust chain goes: Pod -> Projected SA Token -> EKS OIDC Provider -> AWS STS -> IAM Role. Misconfiguration of the trust policy's condition keys can allow cross-namespace or cross-cluster role assumption.
Detailed Answer
IRSA Internal Mechanics
When a pod uses IRSA, Kubernetes injects a projected service account token volume at /var/run/secrets/eks.amazonaws.com/serviceaccount/token. This is a time-limited JWT (default 24h, configurable) signed by the cluster's OIDC provider. The AWS SDK's credential chain detects the AWS_WEB_IDENTITY_TOKEN_FILE and AWS_ROLE_ARN environment variables and calls sts:AssumeRoleWithWebIdentity with the JWT. STS validates the token against the registered OIDC provider URL and checks the IAM role's trust policy conditions.
Trust Policy Deep Dive
The IAM role trust policy must include conditions that restrict which service accounts can assume the role. The critical fields are sub (system:serviceaccount:NAMESPACE:SA_NAME) and aud (sts.amazonaws.com). A dangerous misconfiguration is using StringLike with wildcards: system:serviceaccount:*:* allows ANY service account in ANY namespace to assume the role.
Production Security Incident Scenario
A team creates an IAM role for their S3 backup service with trust policy condition system:serviceaccount:production:*. This was intended only for their backup-sa, but a developer in the same namespace creates a new service account that automatically gets access to the S3 role. If an attacker compromises any pod in the production namespace, they can create a pod with any service account name and exfiltrate S3 data.
Defense in Depth
Always use exact service account names in trust policies, never wildcards. Enable CloudTrail logging for STS AssumeRoleWithWebIdentity calls. Use EKS Pod Identity (the newer alternative to IRSA) which simplifies the mapping and avoids OIDC trust policy complexity. Implement OPA/Kyverno policies to restrict which service accounts can be used in which namespaces.