A studio's CI pushes images to Artifact Registry through a workload identity pool whose OIDC provider is bound pool-wide to the Artifact Registry Writer role. A reviewer shows that a pipeline from an unrelated repository in the same CI tenant can push. No credential file may be stored in CI. What should you do?
- A.
Add an attribute condition accepting only the studio's repository claim, and bind the role to that narrowed principal set.
- B.
Move the binding to the default Cloud Build service account and trigger builds by webhook.
- C.
Create a service account key for a dedicated push account and store it as an encrypted variable in the pipeline.
- D.
Keep the pool-wide binding but reduce the provider's token lifetime to the minimum.
Show answer
Answer: A
An attribute condition on the provider plus a binding to the narrowed principal set restricts token exchange to the studio's own repository.
- A. Attribute conditions reject token exchange for other repositories, and binding to the narrowed principal set stops an accepted token from mapping to broad access.
- B. Changing build systems does not repair the trust relationship, and exposing the broad default Cloud Build identity to an external trigger widens the problem.
- C. A downloadable key is exactly the credential Workload Identity Federation exists to remove, and the requirement forbids storing credential files.
- D. Token lifetime limits how long a credential lasts, not who may obtain one; an unrelated pipeline can keep requesting fresh tokens.