PV encryption using customer key in GKE (GCP), EKS (AWS)

9/29/2021

Both GKE (GCP) and EKS (AWS) support encryption of dynamically provisioned PV, using customer's own encryption key. This customer key sits in Cloud KMS (GCP) / AWS KMS.

Native integration means, I simply point to KMS ID in storage class.

But the internal behaviour is unclear to me. Where is data encryption key created and stored in cluster? (KMS is for key encryption key, not DEK).
Where is this implementation done - in KMS plugin? Is source code for this plugin open sourced?

-- C. Derx
amazon-eks
amazon-kms
google-cloud-kms
google-kubernetes-engine
kubernetes

1 Answer

9/30/2021
  • By default, Google Cloud encrypts customer content at rest, and GKE manages encryption for you without any action on your part. The Encryption and Decryption of disk content is not done in Kubernetes, nor are encryption keys stored in K8s or etcd. Instead the encryption, decryption, and key management are features of GCP Persistent Disk.
  • When you talk about using a Customer managed encryption key to encrypt an attached GCP Persistent Disk the Kubernetes is not involved and this is completely managed by the Google Compute Engine Persistent Disk CSI Driver, Cloud KMS and the Persistent Disk. The KMS plugin, the DEK's and envelope encryption scheme involvement is only during Kubernetes' secret implementation. The disk-level encryption provided by the CSI plugin uses a similar mechanism, but outside Kubernetes.
  • In other words, the pd.csi.storage.k8s.io CSI will collect the name of a Cloud KMS key and pass it unchanged (see file gce-compute.go, lines 405-425 ) to GCP's v1.compute.disks.insert API call as the DiskEncryptionKey parameter. It's then the GCE PD driver that takes care of asking Cloud KMS to produce a disk encryption key, the key material never reaches Kubernetes and all secret negotiations happen within Google's network.
-- Ashish
Source: StackOverflow