Which combination of solutions will meet these requirements?

Explanations:

Attaching the IAM policy directly to the IAM role of the EKS nodes does not provide granular access to specific AWS resources for Kubernetes service accounts. This approach would grant permissions to all pods running on the node, instead of restricting access to specific service accounts.

Implementing network policies within the EKS cluster focuses on controlling traffic between pods and does not manage AWS resource permissions. Network policies can restrict communication between pods but cannot secure access to AWS services based on IAM roles.

Modifying the EKS cluster’s IAM role to include permissions for each Kubernetes service account is not practical as it would require a one-to-one mapping, which is not scalable or flexible. This method does not utilize IAM roles for service accounts (IRSA) effectively.

Defining an IAM role with necessary permissions and annotating Kubernetes service accounts with the ARN of that IAM role allows specific service accounts to assume the role and access AWS resources securely and granularly. This aligns with the principles of IRSA.

Setting up a trust relationship between the IAM roles for the service accounts and an OIDC identity provider is essential for IRSA. It allows Kubernetes service accounts to securely assume the IAM roles, enabling them to access AWS resources as defined by the attached policies.