[Bug] 2-networking-a-fedramp: the vdss KMS key is created and granted but never attached — NVA boot disks stay Google-managed, while the IL5 stage encrypts its appliance disks with the identical key

[JohnHales]

Bug Description

The FedRAMP High / Moderate networking stage creates a KMS keyring and key for the VDSS host project and grants exactly the identities that would need to use it — then never references the key.

• nva.tf:194 — module "kms", keyring vdss-keyring (:216), key default, HSM.
• nva.tf:209 — roles/cloudkms.cryptoKeyEncrypterDecrypter granted to the NVA service account and to the VDSS host project's compute service agent. That grant pair has no purpose unless a compute resource in that project is meant to use the key.
• nva.tf:75 — the NVA boot_disk is initialize_params { image = "cos-cloud/cos-stable" } with no kms_key_self_link.

Across all nine .tf files in the stage, module.kms appears only at its own definition and in that IAM block. Nothing consumes the key.

The IL5 option, by contrast, creates the identically-named key and uses it four times:

• bastion.tf:36 and bastion.tf:46 — kms_key_self_link = module.kms.keys.default.id on the bastion disks
• ngfw.tf:213-214 — disk_encryption_key { kms_key_self_link = module.kms.keys.default.id } on the NGFW VMs
• ngfw.tf:113 — encryption_key = module.kms.keys.default.id on the NGFW bootstrap bucket

So the two networking options diverge on whether the appliance disks are customer-managed-encrypted, and only the IL5 one does what its own KMS grants imply.

Environment and Deployment Context

• Stellar Engine Version/Commit: v2.13.0 (8f5b67a6); the same file layout is present at v3.0.0 (f64ce6cd), where the directory is renamed 2-networking-a-fedramp.
• Deployment Type:
  • US Region Restricted (e.g., Access Policy constraint)
  • FedRAMP Medium
  • FedRAMP High
  • FedRAMP Moderate
  • DoD IL4
  • DoD IL5
  • Stand-alone / Custom
• FAST Stage (if applicable): Stage 2 (Networking) — the a-fedramp option
  • Stage 0 (Bootstrap)
  • Stage 1 (Resource Management)
  • Stage 2 (Networking)
  • Stage 3 (Security)

Steps to Reproduce

1. Deploy fast/stages-aw/2-networking-a-fedramp (FedRAMP High).
2. Confirm the key exists: gcloud kms keys list --project <prefix>-net-vdss-host --location ,region> --keyring vdss-keyring
3. Inspect either NVA instance's boot disk and look for a diskEncryptionKey.kmsKeyName.

Expected Behavior

Either the NVA boot disks are encrypted with the vdss-keyring default key — matching what the stage's own IAM grants imply and what the IL5 option does — or the stage does not create the key and the grants at all.

Actual Behavior

The keyring, the key and both IAM grants are created; no resource references the key. The NVA boot disks are encrypted with Google-managed keys. Verified in a built FedRAMP High organization: the key .../keyRings/vdss-keyring/cryptoKeys/default exists at HSM protection level with no consumer.

Relevant Logs and Errors

None — the apply succeeds and reports no warning. That is the substance of the report: nothing surfaces the gap.

Additional Context

No org policy forces the issue either way in this configuration: 0-bootstrap/data/org-policies/cloudkms_policy.yaml sets gcp.restrictNonCmekServices to deny only documentai.googleapis.com, so compute.googleapis.com is not required to use CMEK and the unencrypted disks apply cleanly.

The practical impact is twofold: dead infrastructure (a key plus two IAM grants that do nothing), and a misleading signal — an operator reading this stage would reasonably conclude the NVA disks are customer-managed-encrypted. If the intent is that FedRAMP High does not need CMEK on the appliance disks, removing the key and its grants would say so far more clearly than leaving them in place.

[AloysJehwin]

Opened #211 for this — passes module.kms.keys.default.id to the NVA template via the same top-level encryption block the IL5 bastion uses, so the existing grants finally do something.

One thing I checked while doing it: the NVA sets create_template = true, and compute-vm's template path emits disk_encryption_key on the boot disk whenever var.encryption is set, so the template route does encrypt it. The encrypt_boot field on that variable looks vestigial — it's declared but never read in the module.