Not run here either; both are shown from Microsoft's and Google's documentation. Azure 6 trusts GitHub 29 through a federated identity credential on a Microsoft Entra app registration (or a user-assigned managed identity), with the fixed audience api://AzureADTokenExchange. A plain credential matches sub exactly, with no wildcards, so each environment or branch needs its own:
{
"name": "booknest-production",
"issuer": "https://token.actions.githubusercontent.com",
"subject": "repo:binarybehemoth@15277380/booknest@1387250434:environment:production",
"audiences": ["api://AzureADTokenExchange"]
}It is registered with az ad app federated-credential create --id <app-object-id> --parameters credential.json, and the workflow signs in with azure/login@v3, given the app's client-id, tenant-id and subscription-id, which are identifiers, not secrets.
Google Cloud 1 uses Workload Identity Federation: a pool, an OIDC provider in it that maps token claims to attributes, and an attribute condition that rejects tokens from anyone else:
gcloud iam workload-identity-pools create github --location=global
gcloud iam workload-identity-pools providers create-oidc booknest --location=global \
--workload-identity-pool=github --issuer-uri=https://token.actions.githubusercontent.com \
--attribute-mapping=google.subject=assertion.sub,attribute.repository=assertion.repository \
--attribute-condition="assertion.repository_owner_id == '15277380'"Roles are then granted to principalSet://iam.googleapis.com/<pool-id>/attribute.repository/binarybehemoth/booknest, and the workflow uses google-github-actions/auth@v3 with the provider's full resource name. The three clouds differ in vocabulary, but the pattern is the same: trust one issuer, check the audience, and match sub (or another claim) as narrowly as the deployment allows.