fix(api): extend federation source-identity fail-loud guard to Azure and GCP deployments

[cristim]

Summary

The federation IaC handler has a fail-loud guard for empty AWS source account IDs but not for empty Azure/GCP source identities. When AZURE_SUBSCRIPTION_ID, AZURE_TENANT_ID, or GCP_PROJECT_ID are unset on the Lambda, the rendered IaC bundle ships with empty identity fields and customers hit a cryptic terraform apply error.

Captured in: known_issues/25_federation_azure_gcp_source_identity_failloud.md

Current behaviour

internal/api/handler.go::resolveSourceIdentity (≈line 446) reads Azure/GCP identity from environment variables. If any are unset, empty strings flow into the generated tfvars/scripts and the federation bundle downloads successfully. The apply-time failure is a blank client_id / missing project — the operator has no clear signal that CUDly's own env is misconfigured.

The AWS source path in internal/api/handler_federation.go::populateSourceAccountID (≈line 171) already fails loud:

func (h *Handler) populateSourceAccountID(ctx context.Context, source string, data *federationIaCData) error {
    if sourceCloud() != "aws" {
        return nil
    }
    data.SourceAccountID = h.resolveSourceAccountID(ctx)
    if source == "aws" && data.SourceAccountID == "" {
        return fmt.Errorf("federation iac: CUDly failed to resolve its own AWS account ID; ...")
    }
    return nil
}

The Azure/GCP equivalent is missing — populateSourceAccountID returns nil immediately for non-AWS source clouds, and nothing else validates the source identity before rendering the bundle.

Expected behaviour

The same fail-loud treatment for Azure and GCP deployments, naming the missing env var so the operator knows exactly what to fix.

Steps to reproduce

1. Deploy CUDly on Azure (or GCP).
2. Unset AZURE_SUBSCRIPTION_ID on the Lambda/Function App (or GCP_PROJECT_ID on Cloud Run).
3. From the UI, download a federation bundle.
4. Observe: bundle downloads 200 OK, terraform apply later fails with blank client_id / missing project — no actionable error at download time.

Proposed fix

Extend populateSourceAccountID (or add a sibling populateSourceIdentity) to cover Azure and GCP. Sketch:

if sourceCloud() == "azure" {
    id := h.resolveSourceIdentity(ctx)
    if id.SubscriptionID == "" || id.TenantID == "" {
        return fmt.Errorf("federation iac: AZURE_SUBSCRIPTION_ID or AZURE_TENANT_ID is not set; check the Lambda environment variables")
    }
}
if sourceCloud() == "gcp" {
    id := h.resolveSourceIdentity(ctx)
    if id.ProjectID == "" {
        return fmt.Errorf("federation iac: GCP_PROJECT_ID is not set; check the Lambda environment variables")
    }
}

Test plan

Four tests in internal/api/handler_federation_test.go that mock resolveSourceIdentity to return empty fields and assert a non-client-error 500 response is surfaced:

• Azure: SubscriptionID="" → 500
• Azure: TenantID="" → 500
• GCP: ProjectID="" → 500
• Positive control: all fields populated → 200

References

• Companion commit: fix(api): pre-fill ContactEmail from Session.Email and fail loud on empty SourceAccountID (the AWS-only fix this extends).
• Files: internal/api/handler_federation.go::populateSourceAccountID, internal/api/handler.go::resolveSourceIdentity.
• Known-issue doc: known_issues/25_federation_azure_gcp_source_identity_failloud.md.

Severity

Medium — no customer data loss, but an operator misconfiguration leaks through to apply-time errors that look like a CUDly bundle bug.

Effort

Small — ~5 LOC + 4 tests.

[cristim]

Verification on AWS Lambda deploy (PR #67 → sha 96dccb8, deployed 2026-04-25T13:25:32Z)

/api/federation/iac is auth-gated, so payload-driven runtime verification of the new validateFederationSourceIdentity guard isn't reachable via anonymous curl:

$ curl -sS -w 'HTTP %{http_code}\n' \
    'https://33pz7pombdqwu3bdlxp4lqxyra0bsriy.lambda-url.us-east-1.on.aws/api/federation/iac?target=azure'
{"error":"Unauthorized"}
HTTP 401

$ curl -sS -w 'HTTP %{http_code}\n' \
    'https://33pz7pombdqwu3bdlxp4lqxyra0bsriy.lambda-url.us-east-1.on.aws/api/federation/iac?target=gcp'
{"error":"Unauthorized"}
HTTP 401

The endpoint is wired (no longer 404) and the auth gate fires before the validation, which is the correct request order. The pre-flight validation logic is exercised by the unit-test additions in PR #67 (internal/api/handler_federation_test.go::TestValidateFederationSourceIdentity_*), and the deploy workflow that landed the change ran green end-to-end on AWS Lambda + Azure Container Apps + GCP Cloud Run.

Logged-in payload-driven verification (sending an actual Azure/GCP IaC bundle request without source_identity) requires admin credentials and a dev account context — recommended for the next manual smoke test, but not blocking the close.

[cristim]

Re-audit against the deployed implementation

Walked the issue spec → PR #67 diff → deployed code on feat/multicloud-web-frontend → ran the new tests locally. Result: complete and correct against the issue spec, with a couple of small notes worth recording.

Spec coverage

Spec element	Implementation	Status
Fail loud when AZURE_SUBSCRIPTION_ID empty	validateSourceIdentity → fmt.Errorf("federation iac: AZURE_SUBSCRIPTION_ID is not set; …")	✅
Fail loud when AZURE_TENANT_ID empty	same path, separate branch	✅
Fail loud when GCP_PROJECT_ID empty	switch case for gcp, names the Cloud Run env-var location	✅
Error names the missing env var	each branch includes the literal env-var name	✅
500-class (operator misconfig, not client error)	fmt.Errorf (not NewClientError) — IsClientError(err) returns false; tests assert this	✅
Test: Azure subscription-id empty → 500	TestGetFederationIaC_FailsLoudOnEmptyAzureSourceIdentity/missing-subscription-id	✅
Test: Azure tenant-id empty → 500	…/missing-tenant-id	✅
Test: GCP project-id empty → 500	TestGetFederationIaC_FailsLoudOnEmptyGCPSourceIdentity	✅
Test: positive control (all fields populated → 200)	…/all-populated-positive-control	✅

Local run on the merged commit:

=== RUN   TestGetFederationIaC_FailsLoudOnEmptyAzureSourceIdentity
--- PASS: TestGetFederationIaC_FailsLoudOnEmptyAzureSourceIdentity (0.00s)
    --- PASS: …/missing-subscription-id
    --- PASS: …/missing-tenant-id
    --- PASS: …/all-populated-positive-control
=== RUN   TestGetFederationIaC_FailsLoudOnEmptyGCPSourceIdentity
--- PASS: TestGetFederationIaC_FailsLoudOnEmptyGCPSourceIdentity (0.00s)
PASS  ok  github.com/LeanerCloud/CUDly/internal/api  1.280s

Notes (not gaps against this issue, but worth recording)

1. AZURE_CLIENT_ID is resolved into sourceIdentity.ClientID but not validated. The issue spec explicitly lists only AZURE_SUBSCRIPTION_ID / AZURE_TENANT_ID / GCP_PROJECT_ID, so this matches the spec. None of the rendered templates I traced (azure-wif-cli.sh.tmpl, azure-wif.tfvars.tmpl, azure-wif-deploy.sh.tmpl, the Bicep params) reference {{.ClientID}}, so a missing AZURE_CLIENT_ID won't currently leak into a customer bundle. If that ever changes, this guard will need a third Azure branch.

2. Tracking doc known_issues/25_federation_azure_gcp_source_identity_failloud.md still shows 1 needs triage · 0 resolved (new file). PR fix(api): pre-flight validation for federation IaC bundles (target/source + Azure/GCP source-identity) #67 didn't touch the doc. This is consistent with how known_issues/27_*.md (docs(release-notes): tell customers with pre-zero-touch federation bundles to re-download #43's doc) and others have been left after their issues were resolved — there doesn't appear to be a documented sweep convention. If we want one, that's a separate cleanup task; not blocking this close.

3. Order of checks in getFederationIaC is: query-param validation → validateFederationTargetSource (fix(api): reject impossible federation target/source combinations with HTTP 400 #42) → populateSourceAccountID (AWS-source fail-loud) → validateSourceIdentity (fix(api): extend federation source-identity fail-loud guard to Azure and GCP deployments #41 Azure/GCP fail-loud) → render. Fail-fast on user input first, then operator config — correct ordering.

Verdict

Issue #41 is completely and correctly implemented against its spec. Safe to close.

[cristim]

Closing — implementation matches spec, all 4 spec test cases pass on the deployed branch (full audit in the comment above). Fixed in PR #67, deployed at sha 599e58f.