IAM & governance: access entries, Pod Identity, IRSA, policies

Three questions, three mechanisms

Almost every EKS security discussion comes down to one of three questions. Keep them separate and the design stays clear:

IAM building blocks, in one table

Policy evaluation, simplified: an explicit deny anywhere wins; otherwise the action must be allowed by the identity policy and not blocked by the boundary or SCP.

The platform's own roles

People and pipelines: access entries

Set the cluster's authentication mode to API for new clusters. API_AND_CONFIG_MAP exists for migrating from the legacy aws-auth ConfigMap; the switch to API is one-way.

An access entry says "this IAM principal may use this cluster". What it may then do comes from either:

• Access policies, AWS-managed permission sets, scoped to the cluster or to namespaces:

• or Kubernetes groups on the entry, bound by your own RoleBindings, for anything the managed policies don't express.

$ aws eks create-access-entry --cluster-name prod \
    --principal-arn arn:aws:iam::111122223333:role/aws-reserved/sso.amazonaws.com/AWSReservedSSO_ShopDev_abc123
$ aws eks associate-access-policy --cluster-name prod \
    --principal-arn arn:aws:iam::111122223333:role/aws-reserved/sso.amazonaws.com/AWSReservedSSO_ShopDev_abc123 \
    --policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSEditPolicy \
    --access-scope type=namespace,namespaces=shop

Rules that keep this clean:

• Map roles, never IAM users. People arrive through IAM Identity Center permission sets; CI through its own OIDC-federated role.
• Create the cluster with bootstrap_cluster_creator_admin_permissions off (in Terraform) and grant admin explicitly, so admin access doesn't silently belong to whichever identity happened to run create.
• Keep one break-glass role with cluster-admin, protected by MFA, alarmed on use, and tested twice a year.

Workloads: Pod Identity

EKS Pod Identity gives a pod the credentials of an IAM role, chosen per namespace + ServiceAccount:

1. Install the eks-pod-identity-agent managed add-on (a DaemonSet on each node).
2. Create a role whose trust policy allows the Pod Identity service principal:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "Service": "pods.eks.amazonaws.com" },
    "Action": ["sts:AssumeRole", "sts:TagSession"]
  }]
}

3. Attach a least-privilege permissions policy:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": ["s3:GetObject"],
    "Resource": "arn:aws:s3:::shop-assets-prod/orders/*"
  }]
}

4. Associate the role with the ServiceAccount:

$ aws eks create-pod-identity-association --cluster-name prod \
    --namespace shop --service-account orders \
    --role-arn arn:aws:iam::111122223333:role/shop-orders

Pods with serviceAccountName: orders now get that role's temporary credentials; AWS SDKs find them automatically. No annotations, no per-cluster OIDC setup.

One policy for many teams: session tags (ABAC)

Pod Identity adds session tags such as kubernetes-namespace, kubernetes-service-account and eks-cluster-name. Policies can use them, so one role and policy can serve every namespace safely:

{
  "Effect": "Allow",
  "Action": ["s3:GetObject", "s3:PutObject"],
  "Resource": "arn:aws:s3:::team-data-prod/${aws:PrincipalTag/kubernetes-namespace}/*"
}

A pod in namespace shop can only touch team-data-prod/shop/*.

Workloads: IRSA

IAM Roles for Service Accounts is the older mechanism, still everywhere:

1. Register the cluster's OIDC issuer as an IAM identity provider.
2. The role's trust policy allows sts:AssumeRoleWithWebIdentity for exactly one ServiceAccount:

{
  "Effect": "Allow",
  "Principal": { "Federated": "arn:aws:iam::111122223333:oidc-provider/oidc.eks.eu-west-1.amazonaws.com/id/EXAMPLE123" },
  "Action": "sts:AssumeRoleWithWebIdentity",
  "Condition": {
    "StringEquals": {
      "oidc.eks.eu-west-1.amazonaws.com/id/EXAMPLE123:sub": "system:serviceaccount:shop:orders",
      "oidc.eks.eu-west-1.amazonaws.com/id/EXAMPLE123:aud": "sts.amazonaws.com"
    }
  }
}

3. Annotate the ServiceAccount: eks.amazonaws.com/role-arn: arn:aws:iam::111122223333:role/shop-orders.

Always check which role a pod actually gets (aws sts get-caller-identity from inside it). Mistakes here are silent.

Close the back door: the node role

If a pod can reach the instance metadata service, it can use the node role, which is shared by every pod on that node. Enforce IMDSv2 with a hop limit of 1 in the node launch template (the default on EKS Auto Mode and many current templates, but verify), keep the node role minimal, and move the CNI's permissions off it.

Governance: guard-rails that scale with teams

Identity decides who; governance bounds what and how much.

Example: a namespace that can't be abused by accident:

apiVersion: v1
kind: Namespace
metadata:
  name: shop
  labels:
    pod-security.kubernetes.io/enforce: restricted
    team: shop
    cost-centre: cc-1042
---
apiVersion: v1
kind: ResourceQuota
metadata: { name: shop-quota, namespace: shop }
spec:
  hard:
    requests.cpu: "40"
    requests.memory: 80Gi
    limits.memory: 120Gi
    persistentvolumeclaims: "20"
    services.loadbalancer: "2"
---
apiVersion: v1
kind: LimitRange
metadata: { name: shop-defaults, namespace: shop }
spec:
  limits:
    - type: Container
      default: { cpu: 500m, memory: 512Mi }
      defaultRequest: { cpu: 100m, memory: 128Mi }

Recap

• Keep three things separate: cluster access (access entries + RBAC), pod permissions (Pod Identity / IRSA), governance (quotas, admission, Pod Security, network policy, tags, audit).
• People via SSO roles, CI via OIDC roles, never IAM users or shared kubeconfigs; keep a tested break-glass role.
• Pod Identity for new workloads (fixed service principal, associations, ABAC tags); IRSA where needed; always verify the effective role.
• Minimal node role, IMDSv2 hop limit 1, CNI and controllers on their own roles.
• Permissions boundaries and SCPs make delegation safe as the platform grows.