IRSA Flow (Pod → SA → IAM Role → STS)

What it is: The step-by-step flow of how IRSA enforces AWS permissions per Pod.

What it’s for:

• Implement least privilege for microservices on EKS.
• Explain why node instance role is too broad.

Flow (high level):

• Create separate Kubernetes service accounts (UI-SA, Data-SA).
• Create separate IAM roles (UI-Role, Data-Role).
• Attach minimal policies:
  • UI-Role → DynamoDB-only policy
  • Data-Role → S3-only policy
• Configure OIDC provider for the cluster (OIDC Provider).
• Annotate each service account with its role ARN (IRSA mapping).
• Pods use their service account; AWS STS issues temporary credentials for that role.

Why not “node instance role” (EC2 instance profile):

• Node role is shared by all Pods on the node.
• If you attach both S3 and DynamoDB policies there, every Pod can access both → violates least privilege.

Hard words:

• *flow* /floʊ/: luồng
• *minimal* /ˈmɪnɪməl/: tối thiểu
• *temporary credentials* /ˈtɛmpəˌrɛri krəˈdɛnʃəlz/: thông tin tạm thời
• *violates* /ˈvaɪəleɪts/: vi phạm