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 ServiceRisk Level
LowAddress
SecurityCompliance Standards
- CIS GKE
- Securities and Exchange Board of India (SEBI) - Cloud Security Adoption Framework
Triage and Remediation
- Remediation
Remediation
Manual Steps
Manual Steps
-
Identify disks in use by the cluster (pods + node boot disks)
- On any machine with
gcloudaccess:
- On any machine with
-
Review PDs backing PersistentVolumes for CMEK usage
- For each PV in the cluster, get its disk name and location (any machine with
kubectlandgcloud): - For each PD found (example disk name and zone):
- Decide: if
.diskEncryptionKey.kmsKeyNameisnull, that disk is not CMEK-encrypted and should be considered for migration.
- For each PV in the cluster, get its disk name and location (any machine with
-
Check StorageClasses used for dynamic PD provisioning
- On any machine with
kubectlaccess: - 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.
- On any machine with
-
Review KMS key configuration and IAM access
- On any machine with
gcloudaccess, list KMS keys intended for GKE use: - Check that the GKE node service accounts and GKE PD CSI SA (if used) have appropriate
cloudkms.cryptoKeyEncrypterDecrypteron the chosen key: - Decide: ensure only intended principals are allowed and that GKE identities can use the key.
- On any machine with
-
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
bootDiskKmsKeyand CMEK-enabled StorageClasses (viakmsKeyName/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.
- For new clusters / node pools, follow the GKE CMEK guide to create or update clusters with CMEK-specified
-
Re-verify after changes
- For newly created or migrated PVs, re-run:
Confirm it shows the intended KMS key.
- Re-check
StorageClassdefinitions to ensure all default / actively used classes specify the appropriate CMEK key parameter.
- For newly created or migrated PVs, re-run:
Using kubectl
Using kubectl
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.Automation
Automation
- 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_namecontains 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 yamlgcloud compute disks describe <disk> --zone <zone> --project <project>

