patch serviceaccounts
Annotations on a ServiceAccount are the join point between cluster identity and an external identity provider.
The annotation grants nothing on its own.
It takes effect only where the provider has already been configured to trust this namespace and ServiceAccount name, which RBAC cannot arrange.
Contextual upgrade to T0:
T0 if an external identity provider already trusts this namespace and ServiceAccount name. The annotation then binds pods to that identity and its permissions outside the cluster become reachable from inside it.
Establishing that trust is not a Kubernetes operation, so no RBAC grant can create this precondition; it is a property of the surrounding platform.
- API Group
- (core)
- Scope
- namespaced
- Audit Level
- RequestResponse
Escalation Paths
With patch or update on a namespaced object, set metadata.ownerReferences to point at an owner that does not exist, using a resolvable apiVersion and kind with any name and UID.
The garbage collector resolves the reference, confirms the owner is absent, and deletes the object within seconds on the next sync.
No delete permission on the object is required, and no ownership check runs unless the OwnerReferencesPermissionEnforcement admission plugin is enabled, which it is not by default.
Applies to any namespaced resource the principal can patch or update, turning patch rights into a deletion primitive for objects that delete access would otherwise gate.
Additional rights needed:
Note:
Distinct from CVE-2025-5187 (node self-patch to a cluster-scoped owner, patched).
This is intended behavior for namespaced objects, not a CVE, gated only by the OwnerReferencesPermissionEnforcement admission plugin, which is not enabled by default.
An IAM role must already exist whose trust policy names the cluster OIDC provider and conditions on sub system:serviceaccount:<namespace>:<name> plus aud sts.amazonaws.com
The IAM role trusts the cluster OIDC provider and evaluates whatever token claims its trust policy names, most commonly the subject and the audience
Those conditions are policy specific rather than built into IRSA, and the ServiceAccount annotation takes no part in the authorization decision
A pod running under that ServiceAccount, projecting a serviceAccountToken with audience sts.amazonaws.com, receives an assertion STS accepts
AssumeRoleWithWebIdentity is unauthenticated, so the exchange needs no AWS credentials and returns whatever the role itself grants
create serviceaccounts/token mints the same assertion with no pod involved, and the credentials work from outside the cluster
The eks.amazonaws.com/role-arn annotation only drives the pod-identity-webhook, which injects at admission and so never reaches running pods
That annotation is also the discovery path, since it names the role and the ServiceAccount it trusts, and reading it needs only list serviceaccounts
Additional rights needed:
· any one; running a pod under the bound ServiceAccount claims the role, and setting serviceAccountName needs no permission on the object
· any one; mints the assertion directly, with no pod and no node
· scoped to a trust policy whose subject names a ServiceAccount that does not exist yet
· squatting the bound name, then running under it
· scoped to using the webhook rather than a hand-built projection
· patch alone is not enough on EKS, since injection happens at pod admission
Note:
Not a defect and nothing to patch.
The IAM trust policy is the anchor, so an audit that looks only for the eks.amazonaws.com/role-arn annotation misses every variant that bypasses the webhook.
An IAM policy binding must already grant this namespace and ServiceAccount roles/iam.workloadIdentityUser on the target GCP service account
Add the iam.gke.io/gcp-service-account annotation naming that service account.
A raw PATCH needs patch alone.
The get that kubectl sends first is a CLI artifact
Already-running pods pick up the new identity within seconds with no restart, so no pod-level access is needed and recycling pods is not a mitigation
Tokens then carry exactly that service account IAM roles, so its cloud permissions become reachable from inside the cluster
Additional rights needed: