Wire Azure terraform into CI/CD (IaC runner: staging auto-apply, prod gated)

[Kenny-Heitritter]

Question

Azure terraform is not applied by CI today — .github/workflows/terraform-staging.yml / terraform-prod.yml only target the GCP working dirs; Azure is applied by hand.

Extend _iac-runner.yml + the staging/prod workflows to cover terraform/environments/{staging,prod}/azure — staging auto-apply, prod gated (mirror the GCP setup). Decide + implement how the runner authenticates to Azure (WIF / OIDC / service principal) and reaches the GCS-backed state. Validate by applying the existing staging Azure config unchanged (no model change needed).

Frontier: independent of model identity — takeable now. Blocks the Azure deploy tickets so their applies go through the pipeline (no manual applies).

[Kenny-Heitritter]

Progress — wiring implemented and OIDC validated; apply-validation blocked

PR: qBraid/qbraid-infrastructure#623 (draft — deliberately not mergeable yet, see below).

Auth decision: GitHub OIDC → Entra federated identity, keyless

Chosen over a service principal with a client secret because it mirrors the GCP WIF posture already in the repo — nothing long-lived in GitHub secrets. azurerm 4.x performs the token exchange itself off the ACTIONS_ID_TOKEN_REQUEST_* variables the job already receives from permissions: id-token: write, so there is no azure/login step and no client secret anywhere.

The runner gained four optional inputs — azure_client_id, azure_client_id_apply, azure_tenant_id, azure_subscription_id — exported as ARM_* job env. ARM_USE_OIDC is true only when azure_client_id is set, so they are inert for GCP/AWS working dirs (no environment outside environments/*/azure declares azurerm).

Federated subjects carry the plan/apply split the way wif_provider_apply does for GCP: pull_request and ref:refs/heads/main for plan, environment:production-terraform for the prod apply — a PR plan can never mint apply-capable credentials.

Two auth planes, one run

Azure working dirs authenticate to both clouds. Their state lives in the same GCS bucket as the sibling GCP env under prefix <env>/azure — the env's Terraform SA already holds unconditioned project-level roles/storage.admin, so no new state grant was needed. This is why the existing runner was extended rather than a separate Azure runner built.

env labels must differ

New callers use staging-azure / prod-azure, not staging / prod. env seeds the commit status context (terraform-plan-<env> / result), the apply concurrency group, and the planfile artifact name — sharing it would make the GCP and Azure callers clobber each other's statuses and queue behind each other's applies. The GCP callers also gained a !terraform/environments/*/azure/** push-path negation so an Azure-only change no longer fires a no-op GCP plan.

Provisioned (staging)

Entra app gh-actions-stg-terraform-azure, client 30bd423c-fbdb-4a36-aee6-450188f277e9, tenant 82978b56-041c-46ae-9fcc-ce27b734f040, federated on pull_request + ref:refs/heads/main, holding Contributor + Security Admin at subscription 5d311adb-…. Security Admin is required by the Defender pricing plans and security contact in monitoring.tf. No azurerm_role_assignment exists in these dirs, so User Access Administrator was deliberately withheld. All three IDs are non-secret and inlined, as the WIF provider paths and SA emails already are.

Validated

CI run 30122392376: Terraform Init and Terraform Plan both succeeded on staging-azure, reading live Azure attributes (login_server = "qbraidstagingqgss.azurecr.io", location = "centralus") and matching a local az login plan exactly. The OIDC federation works end to end.

Blocked: cannot complete "validate by applying the config unchanged"

The plan is 5 to add, 3 to change, 13 to destroy. Nine orphaned qgss resources sit in state with no config (deleted in e3c51e5 without a state cleanup), and destroying azurerm_resource_group.qgss would take the live qbraid-staging-qgss RG with it — including an AKS cluster and Postgres server that are not in state at all.

This is not merely cosmetic: the destructive-change guard only runs when auto_apply == 'false' (.github/actions/iac-destructive-guard/action.yml:63-65), so staging applies have no destroy protection. Merging anomalyco#623 with auto_apply: true ahead of the fix would destroy that stack on the next push to the path, unapproved.

Spun out as #43, which now blocks this ticket. anomalyco#623 stays draft until it lands.

Prod

terraform-prod-azure.yml ships complete but dormant — the prod Azure identity cannot be created without prod subscription access (5c689abb-… is not visible from the staging operator's account). Its pull_request trigger is path-scoped so it stays quiet rather than failing a check on every PR. The exact bootstrap checklist (app + 3 federated credentials + Contributor + state-bucket check + which fields to fill and which trigger to widen) is in the file header, for #34 to execute alongside the prod deploy.