Align documentation environment-variables.md with config_schema.json

Align config_schema.json with environment-variables.md (required/optional mismatches, missing docs, and validation gaps)

Summary

There are inconsistencies between config_schema.json and environment-variables.md. These cause confusion for users and can lead to failed or surprising validations at deploy time. This issue proposes concrete changes to bring the schema and documentation into alignment.

Affected files

• config_schema.json
• docs/environment-variables.md

Problems identified

1. Required vs. optional mismatches

• management.arm_subscription_id
  • Schema: required
  • Docs: optional (falls back to the az CLI selected subscription)
• management.terraform_state_container_name
  • Schema: required
  • Docs & schema description: described as optional with default tfstate

2. Schema properties missing from documentation

The following keys exist in the schema but do not appear in environment-variables.md. Please add them (or explicitly mark them as advanced/optional).

• tre.enable_airlock_email_check → env var: ENABLE_AIRLOCK_EMAIL_CHECK
• tre.enable_dns_policy → env var: ENABLE_DNS_POLICY
• tre.allowed_dns → env var: ALLOWED_DNS
• management.disable_acr_public_access → env var: DISABLE_ACR_PUBLIC_ACCESS
• resource_processor.rp_bundle_values → env var: RP_BUNDLE_VALUES
• developer_settings.logging_level → env var: LOGGING_LEVEL

3. Docs include deployment‑only variables that are not in the schema - move to a separate table

This is fine (they shouldn’t be in /config.yaml), but the docs should clarify that they are deployment/CI variables, not schema fields:

• ARM_CLIENT_ID, ARM_CLIENT_SECRET, ARM_TENANT_ID, AZURE_CREDENTIALS, PUBLIC_DEPLOYMENT_IP_ADDRESS

4. Schema validation gaps / correctness

• Regex typo in management.mgmt_storage_account_name pattern (currently uses a class like [A-Za-z09]). Also, storage account names must be lowercase alphanumerics; current pattern appears to allow uppercase.
• management.acr_name allows uppercase; ACR login server/resource naming is typically lowercase.
• The following SKU fields are free strings in the schema but have allowed values documented in environment-variables.md; consider adding enum constraints:
  • tre.firewall_sku (Basic | Standard | Premium)
  • tre.app_gateway_sku (Standard_v2 | WAF_v2)
  • tre.bastion_sku (Developer | Standard | Basic | Premium)

Proposed changes

Schema (config_schema.json)

• Required fields

  • Remove arm_subscription_id from management.required.
  • Remove terraform_state_container_name from management.required and add "default": "tfstate".

• Regex corrections / constraints

  • For mgmt_storage_account_name, enforce lowercase and digits only, length 3–24:
    Pattern suggestion: ^[a-z0-9]{3,24}$
  • For acr_name, enforce lowercase alphanumerics, length 5–50 (if that’s the intended constraint):
    Pattern suggestion: ^[a-z0-9]{5,50}$

• Enumerations

  • Add enum to SKU fields:
    • tre.firewall_sku: ["Basic","Standard","Premium"]
    • tre.app_gateway_sku: ["Standard_v2","WAF_v2"]
    • tre.bastion_sku: ["Developer","Standard","Basic","Premium"]

Documentation (environment-variables.md)

• Add missing variables (mark as advanced where appropriate):

  • ENABLE_AIRLOCK_EMAIL_CHECK — Require email check for airlock (boolean).
  • ENABLE_DNS_POLICY — Enable DNS policy on the firewall (boolean).
  • ALLOWED_DNS — Comma‑separated list of additional allowed DNS entries.
  • DISABLE_ACR_PUBLIC_ACCESS — Disable public (anonymous) access to management ACR (boolean).
  • RP_BUNDLE_VALUES — JSON string (key/value pairs) passed to bundles.
  • LOGGING_LEVEL — Logging level for API & Resource Processor. Allowed: ERROR, WARNING, INFO, DEBUG.

• Clarify deployment‑only variables
  Add a note that ARM_CLIENT_ID, ARM_CLIENT_SECRET, ARM_TENANT_ID, AZURE_CREDENTIALS, and PUBLIC_DEPLOYMENT_IP_ADDRESS are deployment/CI variables and not part of /config.yaml or the config schema.

Compare config_schema.json with docs/environment-variables.md, starting with the listed required fields, properties, patterns, and SKU values. Verify the proposed schema constraints and documentation categories, then run the repository's schema validation or relevant tests if available. Done means the documented variables and schema behavior are aligned, including deployment-only variables being clearly separated.