Repository navigation
fix(ci): align Azure OIDC trust with renamed immutable repository identity #336
Description
Summary
Azure Sanity fails before running its tests after the repository identity changed to LeanerCloud/reserved-instances-cli with immutable OIDC subjects enabled. This blocks normal merging of PR LeanerCloud/cloud-commitments-cli#1889; no check bypass is authorized.
Observed evidence
- Exact PR head:
2b0310847db4232d0c7e28133c3ac1893a15fbf1. - Failed run: https://github.com/LeanerCloud/reserved-instances-cli/actions/runs/35037134858
- Azure Login reports
AADSTS700213, no matching federated identity record forrepo:LeanerCloud@86753534/reserved-instances-cli@1106317010:pull_request. - Read-only GitHub
actions/oidc/customization/subresponse:use_default: true,use_immutable_subject: true, prefixrepo:LeanerCloud@86753534/reserved-instances-cli@1106317010. - Read-only inspection of the
cudly-terraform-deployapplication shows its PR and main credentials still userepo:LeanerCloud/CUDly:pull_requestandrepo:LeanerCloud/CUDly:ref:refs/heads/main. A legacy feature-branch credential also uses the old repository name. No cloud state has been changed.
Reproduction and expected behavior
The Azure Sanity PR workflow receives the new GitHub subject and fails at login, before Build + Run Azure sanity. Its existing issuer and audience are https://token.actions.githubusercontent.com and api://AzureADTokenExchange.
Expected: the intended CI identity accepts the current repository's exact scoped subjects, without broadening issuer, audience or resource permissions, and the sanity tests run successfully. Main-branch trust needs checking before merging so the subsequent deployment is not stranded. Main deployment failure has not been exercised in this investigation.
Proposed fix and boundary
After explicit operator approval, verify the application's client ID against the configured CI identity and update the bootstrap-managed PR/main federated subjects to match current GitHub claims. Preserve scope and have a rollback to the prior subject values. Keep the Terraform source in terraform/environments/azure/ci-cd-permissions/sp.tf and associated configuration consistent with the actual trust; current expressions at lines39-58 use the old name-only subject format. Do not disable immutable subjects or skip Azure Sanity to make CI green.
Re-run failed Azure Sanity on the same head after the authorized trust correction. Require all other exact-head CI, substantive CodeRabbit review and independent local review before merge. The bootstrap module is privileged/manual by project policy; this report does not authorize its application.
Severity: high, urgency now, internal shipping impact. Found while following PR LeanerCloud/cloud-commitments-cli#1889; tracked separately from its audit-log changes.
Activity
cristim commentedon Sep 15, 2026
Coordination update requested by the user: the cudly-split session owns the broader rename/split plan at /Users/cristi/Dropbox_Maestral/devel/cudly-split (CODEX-BRIEF.md, HANDOVER.md, PLAN.md). Its intended destinations are cloud-commitments-{cli,go,mcp,platform}, with current PRs drained before module normalization and carving. This OIDC blocker must be aligned with that plan, including future platform deployment and go sanity identities; no standalone trust change or Terraform apply has been performed here. A coordination request with current live evidence was posted to the shared agent message bus. Earlier successful deployment run conclusions do not establish that the current PR OIDC subject is trusted; the present Azure login failure and live old-subject credentials are the relevant evidence.
cristim commentedon Sep 28, 2026
Duplicate of #2
This issue's ask ("verify the application's client ID against the
configured CI identity and update the bootstrap-managed PR/main federated
subjects to match current GitHub claims... keep the Terraform source in
terraform/environments/azure/ci-cd-permissions/sp.tfand associatedconfiguration consistent with the actual trust") describes exactly the same
defect and the same fix as #2 in this repo: the live Azure (and AWS/GCP)
OIDC trust still names an identity the repository no longer has, and the fix
is to re-derive the federated-credential subjects from the repository's
current claims and re-apply the bootstrap module.
The repo-identity mismatch this issue hit (
reserved-instances-cli/immutable-subject rename, evidenced against
LeanerCloud/reserved-instances-cliat the time) and the repo-split renamethis issue's own comment flags (
cloud-commitments-platform, coordinatedvia the
cudly-splitsession's plan) are two instances of the same rootcause: GitHub's
sub/repositoryclaims follow the repository's currentname, and this repo's federated credentials are keyed on a name rather than
an immutable id. #2's fix direction is specifically to make the trust
rename-proof (
repository_id/repository_owner_idfor AWS/Azure,attribute.repository_idfor GCP) rather than re-keying it to today's nameonly to have the next rename repeat this same incident. Re-keying to
cloud-commitments-platformwithout that would fix today's break and leavethe exact same class of failure for the next rename.
This issue's own text already anticipates the merge: "This OIDC blocker must
be aligned with [the cudly-split] plan, including future platform deployment
and go sanity identities; no standalone trust change or Terraform apply has
been performed here."
#90 (also in this repo) is the adjacent, narrower fix already landed: it
removes the Azure
pull_request-subject federated credential entirely(unused now that PR sanity checks moved to
cloud-commitments-go), ratherthan trying to re-key it. That leaves #2 as the sole remaining tracker for
the rename-proof re-key + bootstrap re-apply this issue asks for.
Closing as a duplicate of #2. If the immutable-subject /
AADSTS700213failure mode described here needs distinct evidence preserved (e.g. the
specific
use_immutable_subject: trueprefix format), that's capturedin this issue's history for whoever picks up #2 to reference.