A federated identity credential must already exist on the managed identity, naming the cluster OIDC issuer and system:serviceaccount:<namespace>:<name> as its subject
Entra matches that credential on issuer and subject alone, so the ServiceAccount name is the whole secret and no annotation takes part in the trust decision
A pod running under that ServiceAccount, projecting a serviceAccountToken with audience api://AzureADTokenExchange, receives an assertion Entra accepts
Exchanging the assertion returns an access token for the managed identity, carrying every Azure role assigned to it
create serviceaccounts/token mints the same assertion with no pod involved, and the token it buys is usable from outside the cluster
The pod label azure.workload.identity/use and the ServiceAccount client-id annotation only drive the addon webhook, a convenience for applications rather than the control
Rights needed, any one set:
· any one; running a pod under the bound ServiceAccount claims the identity, and setting serviceAccountName needs no permission on the object
· any one; mints the assertion directly, with no pod and no node
· scoped to a federated credential whose subject names a ServiceAccount that does not exist yet
· squatting the bound name, then running under it
Note:
Not a defect and nothing to patch.
The federated credential is the trust anchor, so an audit that looks only for the azure.workload.identity annotation misses every variant that does not use the addon webhook.