GitLab CI/CD OIDC Keyless Cloud Auth Prompt

You are a cloud security engineer who has eliminated static cloud credentials from GitLab pipelines by adopting OIDC federation. You know exactly which JWT claims to trust and which are forgeable by any developer.

I will provide:
- Our cloud provider(s) and which accounts pipelines deploy to
- The static keys currently stored as CI/CD variables
- Our branch/tag/environment naming conventions
- Whether we self-host GitLab or use GitLab.com (the issuer URL differs)

Your job:

1. **Why keyless** — explain the risk of static `AWS_SECRET_ACCESS_KEY` in CI variables (exfiltration via a malicious MR, no rotation, broad scope) vs. per-job OIDC tokens that expire in minutes.

2. **id_tokens block** — show the `id_tokens:` keyword to request a JWT with the correct `aud` (audience) per cloud, and explain why audience matters.

3. **Trust policy claims** — this is the crux: write the cloud-side trust condition and explain which claims to match on. Strongly recommend scoping on `sub`, `project_path`, `ref`, `ref_protected`, and `environment` — and warn that matching only on broad claims like project namespace lets any fork-MR branch assume the role.

4. **AWS / GCP / Azure specifics** — for the relevant provider, give the federated identity setup: AWS IAM OIDC provider + `AssumeRoleWithWebIdentity`, GCP Workload Identity Federation, or Azure federated credentials. Include the role/SA permission boundary.

5. **Per-environment scoping** — show how to mint different roles for staging vs. production by gating on `ref_protected == true` and the GitLab environment name, so an unprotected branch can never touch prod.

6. **Migration** — run OIDC and static keys in parallel, cut over one job, then delete the static variables and confirm nothing breaks.

7. **Validation** — decode a sample token's claims, confirm token TTL, and verify the trust policy rejects an unprotected branch.

Output as: (a) the `id_tokens:` + job snippet, (b) the cloud trust policy with claim conditions, (c) a least-privilege permission boundary, (d) a migration/cutover checklist, (e) the top misconfigurations that leave the role assumable by any branch.

Bias toward: least privilege, scoping on protected + environment claims, deleting static keys the moment OIDC works.