[LeonxLJX]

Fixes #374.

Summary

This PR enhances workload blueprints with CMEK wiring, resource-scoped firewall rules, and bastion VM hardening.

Changes Made

fedramp-high/cloud-spanner

• variables.tf: Added optional kms_key_name variable (default: null) accepting a fully qualified KMS crypto key self link.
• main.tf: Wired kms_key_name = var.kms_key_name into the spanner-instance-se module. When a key is provided, Spanner data at rest is encrypted with CMEK instead of GKEK.
• main.tf: Added google_project_service_identity.spanner and google_kms_crypto_key_iam_member.spanner_sa_kms_access resources (guarded with count) that grant the Spanner API service identity roles/cloudkms.cryptoKeyEncrypterDecrypter on the CMEK key when configured.

il5/bastion-pattern

• main.tf: Scoped the ingress firewall rule with target_tags = ["bastion"] instead of applying it to all instances in the network.
• main.tf: Added tags = ["bastion"] to the bastion VM so the firewall rule matches only the intended target.

Security Impact

• CMEK for Spanner: Allows operators to bring their own encryption key for Cloud Spanner data-at-rest, meeting FedRAMP IL5/IL6 data sovereignty requirements.
• Least-privilege firewall: Restricts the bastion web-access firewall rule to VMs tagged bastion, preventing accidental application to other workload VMs on the shared VPC.
• Audit logging: Both affected blueprints already retain log_config { metadata = "INCLUDE_ALL_METADATA" } on their firewall rules.

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[LeonxLJX]

刚 force push 了 erraform fmt 修复 Repository Lint（for_each map key 对齐）。CI 会重新跑。

[LeonxLJX]

Hi, I just signed the Google Contributor License Agreement (CLA). Could someone please re-run the \cla/google\ check? Thanks!

[aghassemlouei]

Thanks for wiring bastion-pattern firewall scoping and cloud-spanner CMEK toward #374. Running terraform validate and terraform plan surfaced three issues documented inline:

1. blueprints/fedramp-high/cloud-spanner/main.tf fails terraform validate with Unsupported argument: An argument named "kms_key_name" is not expected here because modules/spanner-instance-se configures kms_key_name per database inside var.databases, not at the module root.
2. blueprints/fedramp-high/cloud-spanner/main.tf omits depends_on edges from google_project_service.spanner_api to google_project_service_identity.spanner and from google_kms_crypto_key_iam_member.spanner_sa_kms_access to module.cloud-spanner, causing fresh CMEK deployments to race the KMS IAM grant.
3. Only 2 of the blueprints tracked in #374 are covered here while items in cloud-composer-environment, blueprints/il5/postgresql, and resource-scoped IAM remain open; please switch Fixes #374. to Part of #374. and populate the .github/pull_request_template.md sections.

[aghassemlouei]

modules/spanner-instance-se does not declare a top-level kms_key_name variable, so terraform validate fails here with Error: Unsupported argument: An argument named "kms_key_name" is not expected here. In modules/spanner-instance-se/variables.tf at line 43 and main.tf at line 100, kms_key_name is an attribute on each entry of the databases map via databases = { (var.database_name) = { kms_key_name = var.kms_key_name, ... } }. Wire kms_key_name = var.kms_key_name inside databases[(var.database_name)], update the variable description in variables.tf since CMEK encrypts the Spanner database rather than the instance, and regenerate README.md with tools/tfdoc.py.

[aghassemlouei]

On a fresh project with var.kms_key_name != null, google_project_service_identity.spanner needs depends_on = [google_project_service.spanner_api] and module.cloud-spanner needs depends_on = [google_project_service.spanner_api, google_kms_crypto_key_iam_member.spanner_sa_kms_access] so Spanner database creation waits until the Spanner service agent holds roles/cloudkms.cryptoKeyEncrypterDecrypter on var.kms_key_name.