[Bug] kms_protection_level is required by four FAST stages but is set by nothing, and 0-bootstrap builds its keys from the raw variable instead of the regime-aware local it computes

[JohnHales]

Bug Description

v3.0.0 made the KMS protection level configurable for FedRAMP Moderate. The variable was added to
four stages, and a regime-aware default was written — but the default is never used, and the variable
is never supplied.

1. Stage 0 computes the right default and then ignores it.

# fast/stages-aw/0-bootstrap/main.tf:39
kms_protection_level = coalesce(var.kms_protection_level,
  var.assured_workloads.regime == "FEDRAMP_MODERATE" ? "SOFTWARE" : "HSM")

local.kms_protection_level is referenced nowhere else in the stage. The keys are built from the
variable directly:

# fast/stages-aw/0-bootstrap/kms.tf:15-20
locals {
  version_template = {
    algorithm        = "GOOGLE_SYMMETRIC_ENCRYPTION"
    protection_level = var.kms_protection_level
  }
}

At v2.13.0 the same lines read protection_level = "HSM", unconditionally.

2. The variable has no default and no source. 0-bootstrap/variables.tf:228 declares it
nullable = true with no default, so Terraform prompts for it. It does not appear in
terraform.tfvars.sample, and docs/ddg.md never mentions it, so an operator following the
deployment guide has nothing telling them the value exists.

3. Stage 0 does not pass it on, and three more stages require it. outputs.tf exposes a
standalone output "kms_protection_level", but the value is in neither local.tfvars nor
local.tfvars_globals — the two maps that become the .auto.tfvars.json files the later stages
consume. Meanwhile 1-resman/variables.tf:259, 2-networking-a-fedramp/variables.tf:239 and
3-security/variables.tf:192 each declare kms_protection_level with no default and no
tfdoc:variable:source annotation. Each of those stages therefore stops and prompts as well.

The net effect on a documented deployment is four interactive prompts for a variable the guide does
not describe. Pressing Enter supplies "": in Stage 0 the unused coalesce cannot save it, because
kms.tf reads the variable, so "" reaches the key. Supplying null produces the same result the
other way — the organization's logging and GCS keys are created without HSM protection on a
FedRAMP High deployment, which is the case the hardcoded "HSM" used to guarantee.

Environment and Deployment Context

• Stellar Engine Version/Commit: main @ 6d7d08c0 (2026-09-09); introduced in v3.0.0 (f64ce6cd) by PR Add support for FedRAMP Moderate Assured Workloads deployments #162. At v2.13.0 (8f5b67a6) 0-bootstrap/kms.tf:18 is protection_level = "HSM" and no stage declares the variable.
• Deployment Type:
  • US Region Restricted (e.g., Access Policy constraint)
  • FedRAMP Moderate
  • FedRAMP High
  • DoD IL4
  • DoD IL5
  • Stand-alone / Custom
• FAST Stage (if applicable): all four
  • Stage 0 (Bootstrap)
  • Stage 1 (Resource Management)
  • Stage 2 (Networking)
  • Stage 3 (Security)

Steps to Reproduce

1. Follow docs/ddg.md to prepare fast/stages-aw/0-bootstrap/terraform.tfvars from terraform.tfvars.sample, with assured_workloads.regime = "FEDRAMP_HIGH".
2. terraform plan. Terraform prompts: var.kms_protection_level — Enter a value:.
3. Press Enter. Inspect the planned google_kms_crypto_key resources in the log-export project: version_template.protection_level is "", not HSM.
4. Continue to Stage 1, Stage 2 and Stage 3. Each prompts for the same variable, because it is in neither .auto.tfvars.json Stage 0 generates.

Expected Behavior

A FedRAMP High deployment that follows the deployment guide produces HSM-protected keys with no prompt, exactly as it did at v2.13.0. A FedRAMP Moderate deployment gets SOFTWARE from the regime, or from one explicit setting. Downstream stages inherit the value from Stage 0's outputs like every other shared value.

Actual Behavior

Four prompts for an undocumented variable; an empty answer silently degrades the organization's KMS protection level on a FedRAMP High deployment.

Relevant Logs and Errors

var.kms_protection_level
  KMS protection level.

  Enter a value:

Additional Context

• Suggested fix, three small changes: (1) kms.tf uses local.kms_protection_level instead of var.kms_protection_level, so the regime default applies; (2) add kms_protection_level to local.tfvars in 0-bootstrap/outputs.tf and mark the downstream declarations # tfdoc:variable:source 0-bootstrap; (3) add a commented line to terraform.tfvars.sample and a row to the DDG variables table.
• A default = null on the four declarations would remove the prompts on its own, but on its own it would also make the FedRAMP High degradation silent rather than interactive — (1) is the part that matters.
• Related: PR fix(3-security): apply kms_protection_level to keys that set no version_template #212 (ec82b554) made 3-security apply this variable to keys that set no version_template, which is the fix for [Bug] 3-security: keyring-level version_template is silently discarded — keys without a per-key version_template are created as SOFTWARE, not HSM #107. That change is correct and is not affected by this report; it inherits the same unset value.