The most effective and secure method to grant granular AWS permissions to specific pods within an Amazon EKS cluster is by using IAM Roles for Service Accounts (IRSA). This approach adheres to the principle of least privilege. The solution involves creating distinct Kubernetes service accounts for the UI and the data services. Corresponding IAM roles are then created, one with a policy granting only DynamoDB access and the other with a policy granting only S3 access. Each service account is configured to assume its respective IAM role. When a pod is deployed with a specific service account, it automatically receives temporary credentials for the associated IAM role, ensuring it can only access the intended AWS service.

A: Attaching policies to the EC2 instance profile grants permissions to all pods on that node, which violates the principle of least privilege as the UI pod could access S3 and vice-versa.

B: IAM policies cannot be attached directly to EKS pods. Policies are associated with IAM identities (like roles), which pods can then assume via a service account.

D: This option correctly identifies the IRSA mechanism but incorrectly maps the permissions. It grants S3 access to the UI and DynamoDB access to the data services, which is the reverse of the stated requirement.

1. AWS EKS User Guide

"IAM roles for service accounts": This document states

"With IAM roles for service accounts

you can associate an IAM role with a Kubernetes service account. This service account can then provide AWS permissions to the containers in any pod that uses that service account." This directly supports the mechanism of associating a role with a service account as described in the correct answer. (Source: AWS Official Documentation

Amazon EKS User Guide

Section: Identity and access management > IAM roles for service accounts).

2. AWS EKS Best Practices Guides

"IAM Roles for Service Accounts (IRSA)": This guide explicitly recommends

"We recommend using IAM Roles for Service Accounts (IRSA) to assign IAM permissions to your pods." It further warns against attaching permissions to nodes: "Avoid assigning IAM permissions directly to nodes. This would grant those permissions to any pod that is scheduled on that node." This directly refutes option A and endorses the approach in option C. (Source: AWS Official Documentation

Amazon EKS Best Practices Guide for Security

Section: Identity and Access Management > IAM Roles for Service Accounts (IRSA)).

3. AWS Whitepaper

"Amazon Elastic Kubernetes Service (EKS) running on AWS Fargate Security Overview": While focused on Fargate

the principle is identical for EC2 nodes. Page 10 discusses IRSA

explaining that it allows for "fine-grained permission management" by associating IAM roles with Kubernetes service accounts

which is the core concept of the correct solution. (Source: AWS Whitepapers & Guides

Document ID: AWS-EKS-Fargate-Security-Overview-2020

Page 10

Section: IAM Roles for Service Accounts).