05 / Three identity boundaries

Scroll the diagram sideways for readable labels.

Learning objective and mechanism verified

An EKS access entry associates an IAM principal with cluster access. Permissions can use EKS access policies or Kubernetes groups connected to RBAC. Kubernetes RBAC controls cluster API operations; it does not authorize an end user to read a particular business record.

Pod-to-AWS path verified

EKS Pod Identity maps a namespace and ServiceAccount to an IAM role. A supported AWS SDK uses temporary credentials through the default provider chain and the Pod Identity agent path. Auto Mode supplies the relevant integration. The documented Pod Identity worker scope is Linux EC2; do not assume it works on Fargate.

Alternative and limits verified

IRSA uses a projected ServiceAccount OIDC token and AWS STS to obtain temporary role credentials. It remains a relevant option when its supported environment fits. Containers sharing a node are not a strong independent security boundary, and unrestricted instance metadata can expose the node role.

Worked example synthesis

Give a document worker a dedicated ServiceAccount and an IAM role scoped to the required document prefix and actions. Give a deployer only the Kubernetes operations needed for its namespace. Separately enforce tenant and policy access in the application. This is a proposed design; exact IAM conditions depend on the data model.

Decision, pitfall and improvement synthesis

Avoid attaching all workload permissions to the node role or handing every deployer cluster-admin. Inspect actual credential resolution, test both permitted and denied actions, and restrict instance metadata as appropriate. Verify SDK support and identity-agent access before debugging an S3 denial as a networking problem.