One IAM role for every service, and no neighbour's secrets

The IAM sprawl problem

A role per service means a Terraform change for every new service, dozens of near-identical policies, and the steady temptation to reuse one role for "just this other service".

Session tags do the scoping

EKS Pod Identity tags every session with the pod's namespace and service account. One shared application role can then use those tags in resource paths:

statement {
  sid     = "OwnSecretsOnly"
  actions = ["secretsmanager:GetSecretValue"]
  resources = [
    "arn:aws:secretsmanager:${region}:${account}:secret:${cell}/services/$${aws:PrincipalTag/kubernetes-namespace}/$${aws:PrincipalTag/kubernetes-service-account}/*"
  ]
}

A pod in payments running as api reads <cell>/services/payments/api/* and nothing else. Tables and buckets follow the same prefix rule. A label change cannot widen it: the tags come from the platform, not from the pod.

Where it stops

• A workload that needs something outside its prefix gets its own role, declared in code with the reason.
• External Secrets syncing into a namespace is limited to that namespace's prefix by an admission policy, so the cluster-wide secret store cannot become a back door.
• Every role, shared or not, carries a permissions boundary the organization requires.