Review GCP disk encryption key management

Description

GCP disks are encrypted at rest by default. Omitting a customer-supplied key (CSEK) or customer-managed key (CMEK) does not store the disk in plaintext.

Where default encryption does not meet key-control requirements, separating key management can be important. Critical or regulated data may require an explicit customer-managed key.

Potential impact

Key-control and audit requirements for important data may not be met.
Incorrectly restricting key access or losing a key can interrupt disk use and recovery.

Remediation

Where customer control is required, configure a valid kms_key_self_link or a suitably protected raw_key in disk_encryption_key.
Check the KMS key location and service-account permissions. Protect Terraform state containing CSEKs and prepare key recovery procedures.
For existing disks, review supported copy or migration procedures and recovery plans; do not assume a code edit alone changes the key.

Examples

Supply a supported image identifier through var.boot_image. For the after example, provide the full actual KMS key identifier through var.kms_key_self_link and prepare compatible key location and usage permissions.

Before

hcl

resource "google_compute_disk" "example" {
  name  = "test-disk"
  type  = "pd-ssd"
  zone  = "us-central1-a"
  image = var.boot_image

}

After

hcl

resource "google_compute_disk" "example" {
  name  = "test-disk"
  type  = "pd-ssd"
  zone  = "us-central1-a"
  image = var.boot_image

  disk_encryption_key {
    kms_key_self_link = var.kms_key_self_link
  }
}

Explanation:

Before: No customer key is specified, so a Google-managed key is used. This is not an unencrypted disk.
After: A customer-managed KMS key is specified. Verify the actual key association and disk usability and recovery.