Kubetier
← Permission Reference
T2

patch serviceaccounts

Annotations on a ServiceAccount are the join point between cluster identity and an external identity provider.

The annotation confers 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

T2Force object deletion with a forged ownerReference

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

  2. The garbage collector resolves the reference, confirms the owner is absent, and deletes the object within seconds on the next sync.

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

  4. 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:

none

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.

K8s docs ↗
T2EKS IRSA role assumption

  1. An IAM role must already exist whose trust policy names the cluster OIDC provider plus this namespace and ServiceAccount

  2. Add the eks.amazonaws.com/role-arn annotation naming that role to the ServiceAccount

  3. Pods using the ServiceAccount receive credentials for the role, bounded by whatever that role grants

Additional rights needed:

none
K8s docs ↗
T2GKE Workload Identity ServiceAccount binding

  1. An IAM policy binding must already grant this namespace and ServiceAccount roles/iam.workloadIdentityUser on the target GCP service account

  2. Add the iam.gke.io/gcp-service-account annotation naming that service account

  3. Pods using the ServiceAccount obtain GCP tokens carrying exactly that account's IAM roles

Additional rights needed:

none
K8s docs ↗
T2AKS Azure Workload Identity abuse

  1. A federated identity credential must already exist on the managed identity, matching the cluster issuer and this namespace and ServiceAccount as subject

  2. Label the ServiceAccount azure.workload.identity/use and annotate it with the identity's client ID

  3. The workload identity webhook projects a token for that managed identity into pods using the ServiceAccount

Additional rights needed:

none
K8s docs ↗
K8s docs ↗