create serviceaccounts
A new ServiceAccount carries no permissions, so the risk is not the object but what can be annotated onto it.
Where an external identity provider already trusts a namespace and ServiceAccount name, creating that exact name claims the identity.
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
An IAM role must already exist whose trust policy names the cluster OIDC provider plus this namespace and ServiceAccount
Add the eks.amazonaws.com/role-arn annotation naming that role to the ServiceAccount
Pods using the ServiceAccount receive credentials for the role, bounded by whatever that role grants
Additional rights needed:
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
Pods using the ServiceAccount obtain GCP tokens carrying exactly that account's IAM roles
Additional rights needed:
A federated identity credential must already exist on the managed identity, matching the cluster issuer and this namespace and ServiceAccount as subject
Label the ServiceAccount azure.workload.identity/use and annotate it with the identity's client ID
The workload identity webhook projects a token for that managed identity into pods using the ServiceAccount
Additional rights needed: