Kubernetes lets a **mutating admission webhook** intercept every pod-creation API call and rewrite the spec in flight. EKS uses this for identity: the pre-installed Pod Identity Webhook watches for pods whose service account carries an `eks.amazonaws.com/role-arn` annotation and injects everything IRSA needs — a second projected OIDC token (audience rewritten from the Kubernetes API server to `sts.amazonaws.com`, expiry extended to 24h) plus the `AWS_ROLE_ARN` and `AWS_WEB_IDENTITY_TOKEN_FILE` environment variables that activate it. The durable concept: **identity plumbing is injected at the platform's interception point, not declared by each workload.** Manifests stay identity-free; the platform team owns the contract centrally (token path, expiry, endpoints) and can change it without touching application repos. Opt-in stays explicit via one annotation. ## Cross-Domain Applications - **Service mesh** — Envoy sidecars are injected by the same admission mechanism; [[SPIFFE Workload Attestation]] delivers their certificates via SDS - **Secrets** — Vault Agent Injector mounts secrets through an identical webhook - **Observability** — APM agents auto-injected into pods without image changes The injected variables only work because of [[Credential Chain Precedence as Integration Surface]] — SDKs find them before falling back to the node role. ## Source [Diving into IAM Roles for Service Accounts](https://aws.amazon.com/blogs/containers/diving-into-iam-roles-for-service-accounts/) — Gaurav Pilay, AWS Containers Blog, 2022-02-28. --- *Source: Diving into IAM Roles for Service Accounts (Gaurav Pilay, AWS Containers Blog 2022)*