infra 7 : Terraform for Render/Vercel + GitHub OIDC for Azure credentials

[TFT444]

Summary

Closes #160.

• infra/terraform/: Terraform for the current live topology — one Render web service (openshield-api), one Render Postgres (openshield-db), a shared secrets env group, and two Vercel projects (frontend dashboard, website docs site). Every credential-shaped value is a sensitive = true Terraform variable with no default — nothing is applied, no live credentials exist in this repo. See infra/terraform/README.md for the one-time setup and plan/apply flow.
• .github/workflows/terraform-plan.yml: runs terraform fmt/validate on every PR touching infra/terraform/**; also runs terraform plan once TF_API_TOKEN is configured (gracefully skipped until then, workflow still passes).
• deploy.yml: Azure smoke-test authentication switched from a stored AZURE_CLIENT_SECRET to GitHub OIDC federation via azure/login@v3. No application code changes needed — DefaultAzureCredential() already picks up workload-identity federation automatically.
• docs/ci-oidc-setup.md: the one-time az ad app federated-credential create commands needed on the existing openshield-scanner service principal (I have no Azure access to run these myself).
• docs/secrets-inventory.md: every credential-shaped value in the project and where it lives (GitHub secret vs Render env var vs Terraform variable).

Known scope limits (called out explicitly, not silently swept under)

• [INFRA 7] Infrastructure as Code: Terraform for Render/Vercel + GitHub OIDC for Azure credentials #160 depends on [INFRA 4] Deterministic deploys: Render deploy-hook API, staging environment, worker as separate service #157 (service topology), which isn't merged yet — PR Infra: add deterministic Render deploy pipeline and separate worker services #172 is in progress and adds its own render.yaml blueprint. This PR models today's live topology only; reconciling Terraform vs the render.yaml blueprint is a follow-up once Infra: add deterministic Render deploy pipeline and separate worker services #172 lands (documented in infra/terraform/README.md).
• No live infra access. I have no Render/Vercel/Azure/Terraform Cloud credentials, so terraform plan has never run against real infrastructure. Verified instead via terraform fmt -check and terraform validate (both pass, provider schemas confirmed against each provider's own docs). The plan tier variables (render_postgres_plan, render_web_service_plan) are documented best-guesses from docs/api-render-deploy.md — flagged inline as needing confirmation against the real dashboard before the first apply.
• AZURE_CLIENT_SECRET is not deleted — that's a manual, deliberate step for whoever holds repo admin access, done only after confirming OIDC actually works in a real deploy.yml run (see docs/ci-oidc-setup.md).
• OIDC scope: applies only to deploy.yml's maintainer-owned smoke-test Azure identity, not to how the product itself authenticates to end users' own Azure subscriptions (those are user-supplied credentials; OIDC federation is inherent to GitHub Actions and can't apply there).

Security/quality pass

• gitleaks scan of every new commit: 0 leaks.
• trivy config scan of infra/terraform/: 0 misconfigurations.
• All 13 credential-shaped Terraform variables are sensitive = true with no defaults; confirmed AZURE_CLIENT_SECRET appears nowhere under infra/.
• New/modified workflow permissions are minimal (terraform-plan.yml: contents: read, pull-requests: write; deploy.yml: added only id-token: write, contents: read).
• outputs.tf exposes only non-sensitive identifiers/URLs, never connection_info or env var values.

Test plan

• terraform fmt -check -recursive — clean
• terraform validate (local backend override, no live credentials) — Success! The configuration is valid.
• Both new/modified workflow YAML files parse correctly
• ruff check / ruff format --check — clean (this PR touches no .py files)
• Full pytest suite: 260 passed, same 2 pre-existing unrelated local failures, zero regressions
• gitleaks + trivy config — clean

[github-actions]

Dependency Review

✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.

OpenSSF Scorecard

Package	Version	Score	Details
actions/actions/checkout	34e114876b0b11c390a56381ad16ebd13914f8d5	🟢 7	Details Check Score Reason Dangerous-Workflow 🟢 10 no dangerous workflow patterns detected Code-Review 🟢 10 all changesets reviewed Maintained 🟢 10 18 commit(s) and 0 issue activity found in the last 90 days -- score normalized to 10 CII-Best-Practices ⚠️ 0 no effort to earn an OpenSSF best practices badge detected Binary-Artifacts 🟢 10 no binaries found in the repo Token-Permissions ⚠️ 0 detected GitHub workflow tokens with excessive permissions Packaging ⚠️ -1 packaging workflow not detected Fuzzing ⚠️ 0 project is not fuzzed License 🟢 10 license file detected Pinned-Dependencies 🟢 3 dependency not pinned by hash detected -- score normalized to 3 Signed-Releases ⚠️ -1 no releases found Security-Policy 🟢 9 security policy file detected SAST 🟢 10 SAST tool is run on all commits Branch-Protection 🟢 6 branch protection is not maximal on development and all release branches
actions/hashicorp/setup-terraform	b9cd54a3c349d3f38e8881555d616ced269862dd	🟢 6.4	Details Check Score Reason Maintained 🟢 10 13 commit(s) and 2 issue activity found in the last 90 days -- score normalized to 10 Code-Review 🟢 6 Found 6/10 approved changesets -- score normalized to 6 Binary-Artifacts 🟢 10 no binaries found in the repo Packaging ⚠️ -1 packaging workflow not detected CII-Best-Practices ⚠️ 0 no effort to earn an OpenSSF best practices badge detected Dangerous-Workflow 🟢 10 no dangerous workflow patterns detected Token-Permissions ⚠️ 0 detected GitHub workflow tokens with excessive permissions Pinned-Dependencies 🟢 10 all dependencies are pinned License 🟢 10 license file detected Fuzzing ⚠️ 0 project is not fuzzed Signed-Releases ⚠️ -1 no releases found Security-Policy 🟢 10 security policy file detected Branch-Protection 🟢 6 branch protection is not maximal on development and all release branches SAST ⚠️ 0 SAST tool is not run on all commits -- score normalized to 0

Scanned Files

• .github/workflows/terraform-plan.yml

[m-khan-97]

Reviewed the full diff — this is exceptionally well-scoped for a "we have zero live infra access" constraint. A few things stood out as particularly well-reasoned:

• Correctly limits OIDC to CI, not runtime. AZURE_CLIENT_SECRET is deliberately kept out of the Terraform-managed env group and left as a manual Render dashboard entry, not deleted. That's the right call — Render's compute has no Azure workload-identity federation, so the long-running API/worker service still needs a standing credential; only the ephemeral GitHub Actions runner in deploy.yml can use OIDC. Good to see that distinction actually reflected in the code, not just asserted in prose.
• Honest about the danger zone. The README is explicit that the Render web service, Postgres instance, and both Vercel projects already exist and must be terraform import-ed before any real terraform apply, or it'll attempt to create duplicates. That's the single most important thing whoever does the first real apply needs to not skip — worth restating out loud here since it's easy to gloss over in a large README.
• Full CI is green, including terraform fmt/validate actually running (not just claimed), and the known overlap with #172's render.yaml blueprint is flagged as an explicit unresolved follow-up rather than silently left for someone to discover later.

Two minor, non-blocking notes:

1. docs/ci-oidc-setup.md and docs/secrets-inventory.md describe the Azure identity on the Render web service as distinct from "end-user scan credentials" / "the product feature itself," implying a BYOC flow. As far as I can tell from the current codebase, there's only one server-side Azure service principal in play (AZURE_SUBSCRIPTION_ID/CLIENT_ID/TENANT_ID env vars used by both the API's own scans and the smoke test) — there's no per-user credential flow today. Worth softening that language slightly so it doesn't read as describing a feature that doesn't exist yet.
2. The planning doc under docs/superpowers/specs/2026-07-12-terraform-oidc-design.md references azure/login@v2 in a couple of spots while the shipped workflow and the paired plan doc both correctly use v3. Harmless since it's scratch/planning material, not user-facing docs, but a quick pass would keep it internally consistent.

Neither blocks this. Approving — nice work handling a "no credentials, be honest about it" constraint without pretending the risk isn't there.

[Vishnu2707]

Approved, as this addresses the clear scope of the work.