A company is using an Amazon Elastic Kubernetes Service (Amazon EKS) cluster. The company must ensure that Kubernetes service accounts in the EKS…

IAM Roles for Service Accounts (IRSA) in Amazon EKS provides granular, pod-level IAM permissions for applications. This is achieved by associating a Kubernetes service account with an IAM role. The core mechanism relies on an OpenID Connect (OIDC) identity provider hosted by the EKS cluster.

First, a trust relationship must be established between the IAM role and the cluster's OIDC provider (Option E). This allows the AWS Security Token Service (STS) to accept and verify tokens from the service account. Second, the specific Kubernetes service account is linked to the IAM role by annotating it with the role's Amazon Resource Name (ARN) (Option D). This combination ensures that only pods using the specified service account can assume the role and receive its permissions.

A. Attaching policies to the EKS node's IAM role grants permissions to all pods on that node, which is not granular and violates the principle of least privilege that IRSA is designed to enforce.

B. Kubernetes network policies manage network traffic flow (Layer 3/4) between pods and do not control access to AWS services, which is an IAM (identity) function.

C. The EKS cluster's IAM role is for the Kubernetes control plane to manage AWS resources (like load balancers), not for granting permissions to individual application workloads.

1. Amazon EKS User Guide

"IAM roles for service accounts": This document outlines the entire IRSA process. It 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 supports the overall concept behind options D and E.

2. Amazon EKS User Guide

"Creating an IAM OIDC provider for your cluster": This section details the prerequisite for IRSA. It explains

"Your cluster has an IAM OIDC identity provider. You use this provider to support using IAM roles for service accounts." This directly supports the requirement in option E.

3. Amazon EKS User Guide

"Configuring a Kubernetes service account to assume an IAM role": This page provides the specific steps for linking the components. It instructs to "Create a Kubernetes service account... Annotate the Kubernetes service account with the ARN of the IAM role that you created." This directly validates the action described in option D.

4. AWS Security Blog

"IAM Roles for Service Accounts": In the section "How it works

" the blog explains

"The cluster’s OIDC provider is used to issue and sign a JSON Web Token (JWT) for the service account... The pod can then use the AWS SDK to assume the IAM role... by presenting the service account’s JWT to the AWS Security Token Service (STS) AssumeRoleWithWebIdentity operation." This confirms the OIDC trust relationship (E) is fundamental to the process.