setup-gcp-wif.sh never sets --allowed-audiences when creating a Workload Identity Pool provider (create-aws / create-oidc), and never checks it on the provider-reuse path either.
GCP defaults the allowed audience to the provider's full resource name when --allowed-audiences is omitted, so a freshly-created provider is reasonably scoped. But on reuse, an existing provider with a broader (or attacker-widened) --allowed-audiences list is accepted silently: the script's reuse checks (attribute condition, attribute mapping, and now the exact-match provider-type check fixed in LeanerCloud/cloud-commitments-cli#1673) validate who can federate, but not which token audiences the provider will accept doing so. A provider whose audience list has been expanded to include other relying parties' expected audiences widens what counts as a valid token for this provider without changing the identity restriction, which is a real (if secondary, defense-in-depth) gap.
Where this was found
Flagged during the adversarial review that produced LeanerCloud/cloud-commitments-cli#1673 (issuer/account-id suffix-prefix-match bypass fix), while auditing the same provider-reuse block (arm/CUDly-CrossSubscription/setup-gcp-wif.sh, else branch around line ~250-310). Judged out of scope for that PR because closing this gap requires new CLI surface (an --allowed-audiences flag, a decision on what the expected/default value should be, wiring into both create-aws/create-oidc calls, and a new reuse-time comparison) rather than tightening a comparison that's already present, unlike the mapping/condition/type checks this script already has.
Suggested fix
On the reuse path only: describe the existing provider's allowed audiences and compare against the expected value, using the same "found/expected, delete-and-rerun" die the attribute-condition, attribute-mapping and provider-type checks in that same block already use.
Expected value is GCP's default, the provider's own full resource name, which is what every provider this script creates already has. That is the whole finding: the reuse path is the only place a provider with a widened audience list can be accepted.
Deliberately not doing, absent a concrete need:
- Pinning
--allowed-audiences explicitly at create time. It would set exactly the value GCP already defaults to, so it changes nothing about the providers this script creates, and the reuse check above is what catches the drift the explicit pin is meant to insure against.
- A new
--allowed-audiences CLI flag. Nothing here needs an operator-chosen audience, and the flag would add a supported way to widen the audience list through the script itself, which is the property this issue is about.
Remedy simplified (2026-08-03): the create-time pin and the new CLI flag were dropped, leaving the reuse-path comparison that actually closes the reported gap. Neither addressed a demonstrated defect, and the flag would have added the widening capability the issue exists to prevent.
setup-gcp-wif.shnever sets--allowed-audienceswhen creating a Workload Identity Pool provider (create-aws/create-oidc), and never checks it on the provider-reuse path either.GCP defaults the allowed audience to the provider's full resource name when
--allowed-audiencesis omitted, so a freshly-created provider is reasonably scoped. But on reuse, an existing provider with a broader (or attacker-widened)--allowed-audienceslist is accepted silently: the script's reuse checks (attribute condition, attribute mapping, and now the exact-match provider-type check fixed in LeanerCloud/cloud-commitments-cli#1673) validate who can federate, but not which token audiences the provider will accept doing so. A provider whose audience list has been expanded to include other relying parties' expected audiences widens what counts as a valid token for this provider without changing the identity restriction, which is a real (if secondary, defense-in-depth) gap.Where this was found
Flagged during the adversarial review that produced LeanerCloud/cloud-commitments-cli#1673 (issuer/account-id suffix-prefix-match bypass fix), while auditing the same provider-reuse block (
arm/CUDly-CrossSubscription/setup-gcp-wif.sh,elsebranch around line ~250-310). Judged out of scope for that PR because closing this gap requires new CLI surface (an--allowed-audiencesflag, a decision on what the expected/default value should be, wiring into bothcreate-aws/create-oidccalls, and a new reuse-time comparison) rather than tightening a comparison that's already present, unlike the mapping/condition/type checks this script already has.Suggested fix
On the reuse path only:
describethe existing provider's allowed audiences and compare against the expected value, using the same "found/expected, delete-and-rerun"diethe attribute-condition, attribute-mapping and provider-type checks in that same block already use.Expected value is GCP's default, the provider's own full resource name, which is what every provider this script creates already has. That is the whole finding: the reuse path is the only place a provider with a widened audience list can be accepted.
Deliberately not doing, absent a concrete need:
--allowed-audiencesexplicitly at create time. It would set exactly the value GCP already defaults to, so it changes nothing about the providers this script creates, and the reuse check above is what catches the drift the explicit pin is meant to insure against.--allowed-audiencesCLI flag. Nothing here needs an operator-chosen audience, and the flag would add a supported way to widen the audience list through the script itself, which is the property this issue is about.Remedy simplified (2026-08-03): the create-time pin and the new CLI flag were dropped, leaving the reuse-path comparison that actually closes the reported gap. Neither addressed a demonstrated defect, and the flag would have added the widening capability the issue exists to prevent.