> ## Documentation Index
> Fetch the complete documentation index at: https://cloudanix.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Cryptographic Keys

### More Info:

Rotate cryptographic keys on a regular schedule. Thus, key rotation should be enabled on all cryptographic keys. Google will handle the rotation of the encryption key itself, so previous data does not need to be re-encrypted before the rotation occurs.

### Risk Level

Medium

### Address

Security, Operational Maturity

### Compliance Standards

ARPA, MAS

### Triage and Remediation

<Tabs>
  <Tab title="Remediation">
    ### Remediation

    <AccordionGroup>
      <Accordion title="Using Console" defaultOpen="true">
        Below are step‑by‑step console instructions to properly configure and remediate cryptographic key issues for **GCP Compute Engine** using **Cloud KMS (CMEK)**. This covers the most common misconfigurations: using default Google‑managed keys only, not rotating keys, and incorrect IAM on keys.

        ***

        ## 1. Create or Verify a Cloud KMS Key (CMEK)

        1. In the **Google Cloud Console**, go to:\
           **Security → Key Management** (or search “Key Management”).
        2. Ensure you’re in the **correct project** (top nav).
        3. Click **Create key ring**:
           * Name: e.g. `compute-keyring`
           * Location type: usually **Regional**
           * Location: choose the **same region** as your Compute Engine resources.
           * Click **Create**.
        4. On the new key ring, click **Create key**:
           * Name: e.g. `compute-disk-key`
           * Protection level: **Software** (or **HSM** if required by policy).
           * Purpose: **Symmetric encryption/decryption**.
           * **Rotation period**: set per your policy (e.g. `90 days`) and enable **automated rotation**.
           * Click **Create**.

        ***

        ## 2. Grant Compute Engine Permission to Use the Key

        You must allow the **Compute Engine service account** to use the key.

        1. Identify the service account:
           * For project‑wide default, it’s usually:\
             `PROJECT_NUMBER-compute@developer.gserviceaccount.com`
           * To confirm, go to **IAM & Admin → Service Accounts** and find:
             * “Compute Engine default service account” or
             * The custom service account attached to your VM(s).
        2. In the console, go to **Security → Key Management → Key rings**.
        3. Click the key ring, then click your key (e.g. `compute-disk-key`).
        4. Go to the **Permissions** tab.
        5. Click **Grant access**:
           * New principals: add the Compute service account from step 1.
           * Role:
             * Prefer fine‑grained: **Cloud KMS CryptoKey Encrypter/Decrypter**\
               (or at minimum what your policy requires).
           * Click **Save**.

        ***

        ## 3. Use CMEK for New Disks / New VMs

        You cannot change the encryption key of an **existing disk in place**; you must create a new disk or snapshot+disk using the CMEK.

        ### 3.1 New VM with CMEK‑encrypted boot disk

        1. Go to **Compute Engine → VM instances**.
        2. Click **Create instance**.
        3. Under **Boot disk**, click **Change**.
        4. Select your image as usual.
        5. Expand the **Advanced options** or **Encryption** section.
        6. Select **Customer‑managed key (CMEK)**.
        7. Click **Browse** and select your key:
           * Choose the correct **Key ring** and **Key** created earlier.
        8. Click **Select** (for the disk), then **Create** (for the VM).

        ### 3.2 New additional data disk with CMEK

        1. While creating or editing a VM, under **Additional disks**, click **Add new disk**.
        2. Configure disk type/size.
        3. Expand **Encryption** options.
        4. Choose **Customer‑managed key (CMEK)** and select your KMS key.
        5. Save and create/update the VM.

        ***

        ## 4. Migrate Existing Disks to CMEK

        To remediate existing disks not using CMEK:

        ### 4.1 Using snapshots

        1. Go to **Compute Engine → Disks**.
        2. Select the disk you want to remediate.
        3. Click **Create snapshot**:
           * Name the snapshot (e.g. `disk1-snap-cmek-migrate`).
           * Encryption:
             * Choose **Customer‑managed key (CMEK)**.
             * Select your KMS key.
           * Click **Create**.
        4. After snapshot is ready, go to **Compute Engine → Disks → Create disk**:
           * Source type: **Snapshot**.
           * Source snapshot: select the snapshot you just created.
           * Under **Encryption**, choose **Customer‑managed key (CMEK)** and select the same key.
           * Click **Create**.
        5. Stop the VM that used the original disk.
        6. Detach the old disk and attach the new CMEK‑encrypted disk:
           * VM details → **Edit** → detach old disk, add existing disk (the new CMEK disk).
        7. Start the VM and verify it functions correctly.
        8. Once confirmed, delete the old, non‑CMEK disk if no longer needed.

        ***

        ## 5. Fix Key Rotation and Lifecycle

        If the misconfiguration is about non‑rotating or long‑lived keys:

        1. Go to **Security → Key Management**.
        2. Click your key.
        3. Under **Rotation schedule**:
           * Ensure **Automatic rotation** is **enabled**.
           * Set a **rotation period** that complies with policy (e.g. 30–90 days).
        4. If you need a new primary key version immediately:
           * On the **Versions** tab, click **Add new version**.
           * (Optional) After validation, **Disable** or **Destroy** older key versions according to your retention policy.

        Note: Disks already encrypted with a CMEK will automatically use the **primary key version**; using rotation does not require re‑creating disks.

        ***

        ## 6. Tighten IAM on Keys

        To remediate over‑permissive KMS IAM:

        1. Go to **Security → Key Management → Key rings → \[your key] → Permissions**.
        2. Remove broad roles from wide groups/principals:
           * Avoid `roles/owner`, `roles/editor`, or `roles/cloudkms.admin` for large groups.
        3. Only keep:
           * Service accounts that need `Encrypter/Decrypter` to read/write disks.
           * Limited admins for `Cloud KMS Admin` if required.
        4. Click **Save**.

        ***

        ## 7. Validate the Remediation

        1. For each VM:
           * Go to **Compute Engine → VM instances → \[VM]**.
           * Under **Boot disk** / **Additional disks**, check **Encryption** shows your CMEK key.
        2. For the KMS key:
           * Confirm **Rotation** is enabled.
           * Confirm IAM is appropriately restricted.
        3. Optionally, run **Security Command Center** or **Policy Scanner** (if in use) to confirm findings about “cryptographic keys” are cleared.

        If you tell me your specific “cryptographic keys” finding text (from SCC, Forseti, or another tool), I can tailor these steps exactly to that control.
      </Accordion>

      <Accordion title="Using CLI">
        Below is a practical, step‑by‑step way to remediate common **“Cryptographic Keys”** misconfigurations for **GCP Compute Engine** using the **gcloud CLI**, focused on moving from default Google‑managed encryption to **Cloud KMS CMEK** and tightening key controls.

        If your specific finding text is different (e.g., about service account keys or SSH keys), tell me the exact finding and I’ll adapt.

        ***

        ## 1. Prerequisites

        ```bash theme={null}
        # Set your project
        gcloud config set project PROJECT_ID

        # Enable required APIs
        gcloud services enable \
          compute.googleapis.com \
          cloudkms.googleapis.com
        ```

        You’ll need an IAM identity with (at least):

        * `roles/owner` or
        * `roles/compute.admin` + `roles/cloudkms.admin` + `roles/cloudkms.cryptoKeyEncrypterDecrypter`

        ***

        ## 2. Create a KMS Key Ring and Crypto Key

        ```bash theme={null}
        # Variables
        LOCATION="us-central1"           # or your region
        KEYRING="compute-cekm-keyring"
        KEY_NAME="compute-default-key"

        # Create key ring
        gcloud kms keyrings create "$KEYRING" \
          --location="$LOCATION"

        # Create symmetric crypto key
        gcloud kms keys create "$KEY_NAME" \
          --location="$LOCATION" \
          --keyring="$KEYRING" \
          --purpose="encryption" \
          --protection-level="software"   # or hsm if needed
        ```

        ***

        ## 3. Grant Compute Engine Access to the Key

        Identify the Compute Engine service agents (at project level):

        ```bash theme={null}
        PROJECT_NUMBER=$(gcloud projects describe "$(gcloud config get-value project)" --format="value(projectNumber)")
        COMPUTE_SA="service-$PROJECT_NUMBER@compute-system.iam.gserviceaccount.com"
        ```

        Grant it `cryptoKeyEncrypterDecrypter`:

        ```bash theme={null}
        gcloud kms keys add-iam-policy-binding "$KEY_NAME" \
          --keyring="$KEYRING" \
          --location="$LOCATION" \
          --member="serviceAccount:$COMPUTE_SA" \
          --role="roles/cloudkms.cryptoKeyEncrypterDecrypter"
        ```

        If you use a custom service account for VMs, also grant that account:

        ```bash theme={null}
        CUSTOM_SA="my-vm-sa@PROJECT_ID.iam.gserviceaccount.com"

        gcloud kms keys add-iam-policy-binding "$KEY_NAME" \
          --keyring="$KEYRING" \
          --location="$LOCATION" \
          --member="serviceAccount:$CUSTOM_SA" \
          --role="roles/cloudkms.cryptoKeyEncrypterDecrypter"
        ```

        ***

        ## 4. Create New Disks/VMs Encrypted with CMEK

        ### 4.1 New Disk with CMEK

        ```bash theme={null}
        DISK_NAME="my-disk-cmek"
        ZONE="us-central1-a"

        gcloud compute disks create "$DISK_NAME" \
          --zone="$ZONE" \
          --size=100GB \
          --type=pd-balanced \
          --csek-key-file="" \
          --kms-key=projects/$(gcloud config get-value project)/locations/$LOCATION/keyRings/$KEYRING/cryptoKeys/$KEY_NAME
        ```

        ### 4.2 New VM with CMEK Root Disk

        ```bash theme={null}
        VM_NAME="vm-cmek"

        gcloud compute instances create "$VM_NAME" \
          --zone="$ZONE" \
          --machine-type=e2-medium \
          --boot-disk-size=50GB \
          --boot-disk-type=pd-balanced \
          --boot-disk-kms-key=projects/$(gcloud config get-value project)/locations/$LOCATION/keyRings/$KEYRING/cryptoKeys/$KEY_NAME
        ```

        ***

        ## 5. Migrate Existing Disks to CMEK

        You can’t flip an existing disk’s key in place; you must recreate it from a snapshot or image using CMEK.

        ### 5.1 Snapshot the Existing Disk

        ```bash theme={null}
        EXISTING_DISK="old-disk"
        ZONE="us-central1-a"
        SNAPSHOT_NAME="${EXISTING_DISK}-snapshot"

        gcloud compute disks snapshot "$EXISTING_DISK" \
          --zone="$ZONE" \
          --snapshot-names="$SNAPSHOT_NAME"
        ```

        ### 5.2 Create a New Disk from Snapshot Using CMEK

        ```bash theme={null}
        NEW_DISK="${EXISTING_DISK}-cmek"

        gcloud compute disks create "$NEW_DISK" \
          --zone="$ZONE" \
          --source-snapshot="$SNAPSHOT_NAME" \
          --kms-key=projects/$(gcloud config get-value project)/locations/$LOCATION/keyRings/$KEYRING/cryptoKeys/$KEY_NAME
        ```

        ### 5.3 Attach New Disk / Replace Boot Disk

        For data disks, detach the old one and attach the new:

        ```bash theme={null}
        VM_NAME="my-vm"

        # Detach old disk
        gcloud compute instances detach-disk "$VM_NAME" \
          --zone="$ZONE" \
          --disk="$EXISTING_DISK"

        # Attach new disk
        gcloud compute instances attach-disk "$VM_NAME" \
          --zone="$ZONE" \
          --disk="$NEW_DISK"
        ```

        For boot disks, safest route is:

        1. Stop VM.
        2. Create an image from the existing boot disk.
        3. Create a new VM from that image with `--boot-disk-kms-key=...`.
        4. Re‑apply network/metadata settings and delete the old VM.

        Example:

        ```bash theme={null}
        BOOT_DISK="vm-boot-disk"
        IMAGE_NAME="vm-boot-image"

        # Create image from existing boot disk
        gcloud compute images create "$IMAGE_NAME" \
          --source-disk="$BOOT_DISK" \
          --source-disk-zone="$ZONE"

        # Create new VM with CMEK boot disk
        NEW_VM="vm-cmek-boot"

        gcloud compute instances create "$NEW_VM" \
          --zone="$ZONE" \
          --source-machine-image="" \
          --image="$IMAGE_NAME" \
          --boot-disk-kms-key=projects/$(gcloud config get-value project)/locations/$LOCATION/keyRings/$KEYRING/cryptoKeys/$KEY_NAME
        ```

        Then migrate traffic and delete the old instance.

        ***

        ## 6. Enforce Key Rotation

        Set rotation period and next rotation time:

        ```bash theme={null}
        gcloud kms keys update "$KEY_NAME" \
          --location="$LOCATION" \
          --keyring="$KEYRING" \
          --rotation-period="90d" \
          --next-rotation-time="$(date -u -d '90 days' +%Y-%m-%dT%H:%M:%SZ)"
        ```

        KMS handles key versions; CMEK resources continue to work with new versions automatically.

        ***

        ## 7. Harden KMS IAM

        Review and remove overly broad access:

        ```bash theme={null}
        gcloud kms keys get-iam-policy "$KEY_NAME" \
          --location="$LOCATION" \
          --keyring="$KEYRING"
        ```

        Remove any `allUsers`, `allAuthenticatedUsers`, or unnecessary roles, and keep to:

        * `roles/cloudkms.cryptoKeyEncrypterDecrypter` for only required service accounts.
        * `roles/cloudkms.admin` for a small admin group.

        Update via:

        ```bash theme={null}
        gcloud kms keys set-iam-policy "$KEY_NAME" \
          --location="$LOCATION" \
          --keyring="$KEYRING" \
          policy.json
        ```

        (where `policy.json` is your edited IAM policy).

        ***

        If you can paste the exact “Cryptographic Keys” finding text (e.g., from Security Command Center or CIS benchmark), I’ll tailor these commands exactly to that control (disks, snapshots, images, etc.).
      </Accordion>

      <Accordion title="Using Python">
        Below is a concise, step‑by‑step approach to remediate cryptographic key misconfigurations for **Google Compute Engine (GCE)** using **Python**, focusing on:

        * Moving from Google‑managed to **customer‑managed encryption keys (CMEK)**
        * Correct IAM permissions on keys
        * Enforcing proper key rotation and usage

        ***

        ## 1. Identify Where CMEK Should Be Used

        Common targets:

        * Boot disks and data disks on VM instances
        * Images and snapshots

        Check which disks are unencrypted with CMEK (i.e., currently using Google‑managed keys):

        ```bash theme={null}
        gcloud compute disks list --format="table(name,zone,kind,sourceImage,sourceSnapshot,location,users,encryptionKey)"
        ```

        Any disk equal to `Google managed` in `encryptionKey` is a remediation target.

        ***

        ## 2. Set Up KMS for CMEK

        ### 2.1. Enable APIs (one time)

        ```bash theme={null}
        gcloud services enable \
          cloudkms.googleapis.com \
          compute.googleapis.com
        ```

        ### 2.2. Create a Key Ring and Crypto Key

        Using Python (Cloud KMS client):

        ```python theme={null}
        from google.cloud import kms_v1

        project_id = "YOUR_PROJECT_ID"
        location_id = "us-central1"  # match/near your compute region
        key_ring_id = "compute-keyring"
        crypto_key_id = "compute-disk-key"

        client = kms_v1.KeyManagementServiceClient()
        parent = f"projects/{project_id}/locations/{location_id}"

        # Create key ring
        key_ring_name = client.key_ring_path(project_id, location_id, key_ring_id)
        try:
            client.get_key_ring(request={"name": key_ring_name})
        except Exception:
            client.create_key_ring(
                request={"parent": parent, "key_ring_id": key_ring_id, "key_ring": {}}
            )

        # Create crypto key with rotation
        crypto_key_name = client.crypto_key_path(project_id, location_id, key_ring_id, crypto_key_id)
        from google.protobuf import duration_pb2, timestamp_pb2
        import datetime

        rotation_period = duration_pb2.Duration(seconds=60 * 60 * 24 * 30)  # 30 days
        next_rotation = timestamp_pb2.Timestamp()
        next_rotation.FromDatetime(datetime.datetime.utcnow() + datetime.timedelta(days=1))

        crypto_key = {
            "purpose": kms_v1.CryptoKey.CryptoKeyPurpose.ENCRYPT_DECRYPT,
            "rotation_schedule": {
                "rotation_period": rotation_period,
                "next_rotation_time": next_rotation,
            },
        }

        try:
            client.get_crypto_key(request={"name": crypto_key_name})
        except Exception:
            client.create_crypto_key(
                request={
                    "parent": key_ring_name,
                    "crypto_key_id": crypto_key_id,
                    "crypto_key": crypto_key,
                }
            )
        ```

        ***

        ## 3. Grant the Compute Service Account Access to the Key

        Each instance uses a **service account**. That SA needs `roles/cloudkms.cryptoKeyEncrypterDecrypter` on the crypto key.

        Typical default GCE service account:\
        `PROJECT_NUMBER-compute@developer.gserviceaccount.com`

        ```python theme={null}
        from google.cloud import kms_v1
        from google.iam.v1 import policy_pb2

        project_id = "YOUR_PROJECT_ID"
        location_id = "us-central1"
        key_ring_id = "compute-keyring"
        crypto_key_id = "compute-disk-key"
        compute_sa = "PROJECT_NUMBER-compute@developer.gserviceaccount.com"

        client = kms_v1.KeyManagementServiceClient()
        crypto_key_name = client.crypto_key_path(project_id, location_id, key_ring_id, crypto_key_id)

        policy = client.get_iam_policy(request={"resource": crypto_key_name})
        binding = next((b for b in policy.bindings if b.role == "roles/cloudkms.cryptoKeyEncrypterDecrypter"), None)
        if not binding:
            binding = policy_pb2.Binding(role="roles/cloudkms.cryptoKeyEncrypterDecrypter", members=[])
            policy.bindings.append(binding)

        member = f"serviceAccount:{compute_sa}"
        if member not in binding.members:
            binding.members.append(member)

        client.set_iam_policy(request={"resource": crypto_key_name, "policy": policy})
        ```

        ***

        ## 4. Create New Disks/VMs with CMEK (Python)

        CMEK **cannot be applied in-place** to an existing disk. You must create new disks with CMEK and migrate.

        ### 4.1. Create a CMEK‑Encrypted Disk

        ```python theme={null}
        from googleapiclient import discovery
        from google.oauth2 import service_account

        project = "YOUR_PROJECT_ID"
        zone = "us-central1-a"
        disk_name = "cmek-data-disk"
        kms_key = "projects/YOUR_PROJECT_ID/locations/us-central1/keyRings/compute-keyring/cryptoKeys/compute-disk-key"

        credentials = service_account.Credentials.from_service_account_file("path/to/sa.json")
        compute = discovery.build("compute", "v1", credentials=credentials)

        disk_body = {
            "name": disk_name,
            "sizeGb": "100",
            "type": f"projects/{project}/zones/{zone}/diskTypes/pd-balanced",
            "diskEncryptionKey": {
                "kmsKeyName": kms_key
            },
        }

        operation = compute.disks().insert(project=project, zone=zone, body=disk_body).execute()
        ```

        ### 4.2. Create a VM Using CMEK for Boot Disk

        ```python theme={null}
        instance_name = "cmek-instance"
        machine_type = f"zones/{zone}/machineTypes/e2-medium"
        source_image = "projects/debian-cloud/global/images/family/debian-12"

        instance_body = {
            "name": instance_name,
            "machineType": f"projects/{project}/{machine_type}",
            "disks": [
                {
                    "boot": True,
                    "autoDelete": True,
                    "initializeParams": {
                        "sourceImage": source_image,
                        "diskSizeGb": "20",
                        "diskType": f"projects/{project}/zones/{zone}/diskTypes/pd-balanced",
                        "diskEncryptionKey": {"kmsKeyName": kms_key},
                    },
                }
            ],
            "networkInterfaces": [{"network": "global/networks/default", "accessConfigs": [{"type": "ONE_TO_ONE_NAT"}]}],
            "serviceAccounts": [
                {
                    "email": "PROJECT_NUMBER-compute@developer.gserviceaccount.com",
                    "scopes": ["https://www.googleapis.com/auth/cloud-platform"],
                }
            ],
        }

        operation = compute.instances().insert(project=project, zone=zone, body=instance_body).execute()
        ```

        ***

        ## 5. Migrate Existing Disks to CMEK

        For each non‑CMEK disk:

        1. Create a **snapshot** of the disk.
        2. Create a **new disk** from that snapshot with CMEK.
        3. Detach the old disk from the instance.
        4. Attach the new CMEK disk.
        5. Delete the old disk when verified.

        ### 5.1. Snapshot the Existing Disk

        ```python theme={null}
        disk = "old-disk"
        snapshot_name = "old-disk-snap"

        snapshot_body = {"name": snapshot_name}
        operation = compute.disks().createSnapshot(
            project=project, zone=zone, disk=disk, body=snapshot_body
        ).execute()
        ```

        ### 5.2. Create New Disk from Snapshot with CMEK

        ```python theme={null}
        new_disk = "old-disk-cmek"

        disk_body = {
            "name": new_disk,
            "sourceSnapshot": f"projects/{project}/global/snapshots/{snapshot_name}",
            "diskEncryptionKey": {"kmsKeyName": kms_key},
        }

        operation = compute.disks().insert(project=project, zone=zone, body=disk_body).execute()
        ```

        ### 5.3. Detach Old Disk and Attach New Disk

        ```python theme={null}
        instance = "INSTANCE_NAME"
        device_name = "old-disk"

        # Detach old disk
        compute.instances().detachDisk(
            project=project, zone=zone, instance=instance, deviceName=device_name
        ).execute()

        # Attach new CMEK disk
        attach_body = {
            "source": f"projects/{project}/zones/{zone}/disks/{new_disk}",
            "autoDelete": True,
            "boot": False,
            "deviceName": device_name,
        }

        compute.instances().attachDisk(
            project=project, zone=zone, instance=instance, body=attach_body
        ).execute()
        ```

        ***

        ## 6. Harden Key Management

        1. **Restrict IAM** on KMS keys:
           * Only necessary service accounts: `roles/cloudkms.cryptoKeyEncrypterDecrypter`
           * Admins: `roles/cloudkms.admin` with least privilege.
        2. **Enable key rotation** (already set in Step 2.2).
        3. **Disable or destroy** old keys only after:
           * All disks/images/snapshots no longer depend on them.
        4. **Audit**:
           * Enable Cloud Logging & Cloud Audit Logs for KMS.
           * Periodically verify disks use CMEK:

             ```bash theme={null}
             gcloud compute disks list --format="table(name,zone,encryptionKey.kmsKeyName)"
             ```

        ***

        If you paste a specific current configuration (disk/instance JSON or output of `gcloud compute instances describe`), I can give tailored Python snippets to fix exactly that setup.
      </Accordion>

      <Accordion title="Using Terraform">
        ```hcl theme={null}
        # Customer-managed key (CMEK) used for Compute Engine encryption
        resource "google_kms_key_ring" "compute_ring" {
          name     = "COMPUTE_KMS_KEY_RING_NAME"   # e.g. "compute-ring"
          location = "KMS_LOCATION"                # e.g. "us-central1"
        }

        resource "google_kms_crypto_key" "compute_key" {
          name            = "COMPUTE_KMS_KEY_NAME" # e.g. "compute-key"
          key_ring        = google_kms_key_ring.compute_ring.id
          rotation_period = "2592000s"             # 30 days
        }

        # Example: standalone persistent disk encrypted with CMEK
        resource "google_compute_disk" "data_disk" {
          name  = "DISK_NAME"                      # e.g. "app-data-disk"
          type  = "pd-ssd"
          zone  = "COMPUTE_ZONE"                   # e.g. "us-central1-a"
          size  = 100                              # GB

          disk_encryption_key {
            kms_key_self_link = google_kms_crypto_key.compute_key.id
          }
        }

        # Example: Compute instance with CMEK-encrypted boot disk
        resource "google_compute_instance" "vm" {
          name         = "INSTANCE_NAME"           # e.g. "app-vm-1"
          machine_type = "MACHINE_TYPE"            # e.g. "e2-medium"
          zone         = "COMPUTE_ZONE"            # e.g. "us-central1-a"

          boot_disk {
            initialize_params {
              image = "BOOT_IMAGE_SELF_LINK"       # e.g. "projects/debian-cloud/global/images/family/debian-12"
              size  = 50
              type  = "pd-balanced"
            }

            disk_encryption_key {
              kms_key_self_link = google_kms_crypto_key.compute_key.id
            }
          }

          network_interface {
            network    = "NETWORK_SELF_LINK"       # e.g. "projects/PROJECT_ID/global/networks/default"
            subnetwork = "SUBNETWORK_SELF_LINK"    # or omit if using default
          }

          # Attach CMEK-encrypted data disk
          attached_disk {
            source = google_compute_disk.data_disk.id

            disk_encryption_key {
              kms_key_self_link = google_kms_crypto_key.compute_key.id
            }
          }
        }
        ```

        * Substitute:
          * `COMPUTE_KMS_KEY_RING_NAME`, `KMS_LOCATION`, `COMPUTE_KMS_KEY_NAME`, `DISK_NAME`, `COMPUTE_ZONE`, `INSTANCE_NAME`, `MACHINE_TYPE`, `BOOT_IMAGE_SELF_LINK`, `NETWORK_SELF_LINK`, `SUBNETWORK_SELF_LINK` with your actual values and project via the `google` provider.
        * Changing an existing disk’s encryption key typically forces disk replacement; any instance using that disk may be recreated or require reattachment, so plan for downtime or data migration.
        * Verification: `terraform plan` should show the `disk_encryption_key.kms_key_self_link` being added (or changed) on each `google_compute_disk` and `google_compute_instance.boot_disk` / `attached_disk` that needs CMEK.
      </Accordion>
    </AccordionGroup>
  </Tab>
</Tabs>

### Additional Reading:

* [https://cloud.google.com/vpc/docs/using-cryptoKeys](https://cloud.google.com/vpc/docs/using-cryptoKeys)