An IAM policy must already bind a role to the principal identifier for this namespace and ServiceAccount name in the cluster workload identity pool
No annotation and no cloud service account are involved, which is the current recommended configuration rather than a legacy one
IAM never checks that the ServiceAccount exists, so the binding can predate the object and the name can be squatted
Creating a ServiceAccount with the bound name, or running a pod under it, claims the identity
Pods then obtain tokens for that principal carrying the roles bound to it, with no annotation anywhere in the chain
Rights needed, any one set:
· any one; creating the bound name claims the identity
· any one; running a pod under the bound name is enough
Note:
Not a defect and nothing to fix.
Binding IAM directly to the pool principal is the documented current approach, so the annotation-based path is the legacy one.
Auditing only for the annotation misses this entirely.