ci: stop printing secret-bearing app setting values

Start with the app-settings diagnostic step in .github/workflows/e2e-azure.yml and read the referenced setting construction in infra/main.bicep. Check how the workflow’s existing tests can exercise the diagnostic with synthetic settings; assert that dummy secrets are never rendered and safe troubleshooting information remains. Done when new settings are omitted or shown by name unless explicitly allowed, while the certification gate and unconditional cleanup remain intact.

Context

Review of azure-functions-validation-python at commit b38d702adb1039ed1eda2ef3799d873af2506f41.

The Azure certification workflow unconditionally writes every application setting's value to its diagnostic log:

az functionapp config appsettings list --name "$APP" --resource-group "$RG" \
  --query "[].{name:name,value:value}" -o table 2>/dev/null || true

This is a concrete secret-bearing logging path in the checked-in configuration:

1. infra/main.bicep constructs a storage connection string containing an AccountKey obtained from storageAccount.listKeys().
2. The same template assigns that connection string to AzureWebJobsStorage.
3. e2e-azure.yml selects and prints all setting values in an if: always() diagnostic step.
4. The checked-in workflow has no explicit masking or safe-value selection before that print operation.

The review inspected the latest successful v0.16.0 Azure job, 115599053509 in run 38485749334. Its retrieved diagnostic output included the AzureWebJobsStorage row with the account-key portion redacted. Disclosure of a usable credential was not verified. The retrieval/redaction result does not demonstrate an in-repository guarantee that only safe values reach the diagnostic sink.

The scope is the temporary E2E storage account and application, not a demonstrated production compromise. The workflow runs cleanup with if: always(), and the observed successful run also completed cleanup. Even with that scope, printing all setting values is unnecessary for determining whether the required names and non-secret runtime configuration are present.

Expected behavior: diagnostics should print setting names and, only when useful, values from an explicit non-secret allowlist. Storage connection strings, keys, and subsequently added secret-bearing settings should not be selected for output in the first place.

No real key or connection string is included in this issue. No Azure resources were accessed using a discovered credential, and no Azure mutation was performed during the review.

Acceptance Checklist

• Replace the full name/value dump with names-only output or an explicit allowlist of non-secret runtime settings.
• Ensure AzureWebJobsStorage connection-string values and any account/function keys are never included in the rendered diagnostic output.
• Keep useful troubleshooting information, such as the presence of required setting names, function discovery status, and safe runtime/version settings.
• Add a focused test using synthetic app settings with a clearly dummy storage key and another dummy secret; assert that neither secret value is rendered.
• Confirm that newly added settings are omitted or shown by name only unless explicitly classified as safe, rather than relying on a blacklist of current secret names.
• Preserve the existing Azure certification gate and unconditional resource-cleanup behavior.
• Verify the changed diagnostic output with dummy data without requiring real credentials or creating an Azure deployment solely for this test.

Out of scope

• Claiming that an active key or production account was compromised; usable-key disclosure was not verified.
• Changing the Azure application architecture or replacing storage authentication across the project.
• Removing useful non-secret diagnostics or weakening the release gate.
• Screenshot provenance/content scanning, which is a different output surface addressed by prior work such as #365.
• Adding new repository label taxonomies.

References

• Application settings diagnostic sink
• Storage account key used to build the connection string
• Connection string assigned to AzureWebJobsStorage
• Resource cleanup behavior
• Latest successful Azure certification job
• Prior screenshot leak-scan issue #365