---
title: "Accounts, access, and workload identity"
chapter: "04"
---

# 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.