Accounts, access, and workload identity

Identity has four connected layers: the AWS organization, IAM, EKS cluster access, and Kubernetes RBAC.

People

Federate people through IAM Identity Center. Use short-lived role sessions and groups. Avoid permanent IAM users and access keys.

EKS access entries associate an IAM principal with cluster access. EKS access policies can grant common permissions, while Kubernetes RBAC handles fine-grained namespaced roles. Keep platform administration separate from application deployment. Remove emergency access after the incident.

Pods

Use EKS Pod Identity or IAM Roles for Service Accounts (IRSA) to give a Kubernetes service account short-lived AWS credentials. Use a dedicated service account per responsibility. Do not put access keys in images, ConfigMaps, or Secrets.

Pod Identity uses the EKS Auth API and an agent on nodes; applications need a current AWS SDK. IRSA uses a cluster OIDC provider and web-identity federation. Choose a standard and understand its prerequisites.

Governance

• Separate production, non-production, security, networking, and log archive accounts where the organization needs those boundaries.
• Apply Service Control Policies as guardrails, not workload permissions.
• Centralize CloudTrail and AWS Config evidence in protected accounts.
• Use permission boundaries where delegated role creation needs a ceiling.
• Treat namespace isolation as useful but not automatically hostile-tenant safe.

Feynman check

IAM answers “may this AWS identity call this AWS API?” RBAC answers “may this authenticated identity change this Kubernetes object?” A secure design needs both answers.