Repository navigation
fix(ci): align Azure OIDC trust with renamed immutable repository identity #336
Description
Activity
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.
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 associated
configuration 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 rename
this issue's own comment flags (cloud-commitments-platform, coordinated
via thecudly-splitsession's plan) are two instances of the same root
cause: GitHub'ssub/repositoryclaims follow the repository's current
name, 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 name
only to have the next rename repeat this same incident. Re-keying to
cloud-commitments-platformwithout that would fix today's break and leave
the 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 Azurepull_request-subject federated credential entirely
(unused now that PR sanity checks moved tocloud-commitments-go), rather
than 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 /
AADSTS700213
failure mode described here needs distinct evidence preserved (e.g. the
specificuse_immutable_subject: trueprefix format), that's captured
in this issue's history for whoever picks up #2 to reference.
Summary
Azure Sanity fails before running its tests after the repository identity changed to
LeanerCloud/reserved-instances-cliwith immutable OIDC subjects enabled. This blocks normal merging of PR LeanerCloud/cloud-commitments-cli#1889; no check bypass is authorized.Observed evidence
2b0310847db4232d0c7e28133c3ac1893a15fbf1.AADSTS700213, no matching federated identity record forrepo:LeanerCloud@86753534/reserved-instances-cli@1106317010:pull_request.actions/oidc/customization/subresponse:use_default: true,use_immutable_subject: true, prefixrepo:LeanerCloud@86753534/reserved-instances-cli@1106317010.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 arehttps://token.actions.githubusercontent.comandapi://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.tfand 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.