Skip to main content

More Info:

Use Customer-Managed Encryption Keys (Cmek) To Encrypt Node Boot And Dynamicallyprovisioned Attached Google Compute Engine Persistent Disks (Pds) Using Keys Managed Within Cloud Key Management Service

Risk Level

Low

Address

Security

Compliance Standards

  • CIS GKE
  • Securities and Exchange Board of India (SEBI) - Cloud Security Adoption Framework

Triage and Remediation

Remediation

Manual Steps

  1. Identify disks in use by the cluster (pods + node boot disks)
    • On any machine with gcloud access:
  2. Review PDs backing PersistentVolumes for CMEK usage
    • For each PV in the cluster, get its disk name and location (any machine with kubectl and gcloud):
    • For each PD found (example disk name and zone):
    • Decide: if .diskEncryptionKey.kmsKeyName is null, that disk is not CMEK-encrypted and should be considered for migration.
  3. Check StorageClasses used for dynamic PD provisioning
    • On any machine with kubectl access:
    • For each StorageClass, look for:
      • parameters.kmsKeyName (GCE PD driver)
      • Or parameters.csi.storage.gke.io/kms-key (GKE PD CSI driver)
    • Decide: StorageClasses without a CMEK parameter will provision non‑CMEK disks and should be updated or replaced.
  4. Review KMS key configuration and IAM access
    • On any machine with gcloud access, list KMS keys intended for GKE use:
    • Check that the GKE node service accounts and GKE PD CSI SA (if used) have appropriate cloudkms.cryptoKeyEncrypterDecrypter on the chosen key:
    • Decide: ensure only intended principals are allowed and that GKE identities can use the key.
  5. Plan and apply configuration changes to enable CMEK
    • For new clusters / node pools, follow the GKE CMEK guide to create or update clusters with CMEK-specified bootDiskKmsKey and CMEK-enabled StorageClasses (via kmsKeyName/CSI parameter).
    • For existing non‑CMEK disks, plan a migration: create CMEK-enabled StorageClasses, create new CMEK-backed PVs, and migrate data (e.g., backup/restore, application-level replication) because encryption type cannot be changed in-place.
  6. Re-verify after changes
    • For newly created or migrated PVs, re-run:
      Confirm it shows the intended KMS key.
    • Re-check StorageClass definitions to ensure all default / actively used classes specify the appropriate CMEK key parameter.
kubectl cannot configure Customer-Managed Encryption Keys for GKE node boot disks or dynamically provisioned persistent disks; this is set at the GKE/Compute Engine and Cloud KMS level via the Google Cloud console, gcloud, or IaC. Use kubectl only to identify affected PersistentVolumes if needed, then follow the guidance in the Manual Steps section to apply CMEK at the cloud provider configuration layer.
Explanation of output and what indicates a problem:
  • The script prints a CSV header:
    • pv_name,storage_class,driver,type,pd_identifier,zone_or_region,kms_key_name
  • For each GCE PD-backed PersistentVolume:
    • kms_key_name = GOOGLE-MANAGED-DEFAULT
      → The disk is not using CMEK (uses Google-managed keys) and is non-compliant with the intent of CIS GKE 5.9.1.
    • kms_key_name contains a full KMS resource, for example:
      projects/PROJECT/locations/LOCATION/keyRings/RING/cryptoKeys/KEY
      → The disk is using CMEK (candidate for compliance; you still must review that the key/rotation/policy meet your org’s requirements).
  • Lines with UNKNOWN (...) in the last field mean the script could not determine encryption status for that PV (for example, missing zone or node information). These need manual investigation with:
    • kubectl get pv <pv_name> -o yaml
    • gcloud compute disks describe <disk> --zone <zone> --project <project>

Additional Reading: