0

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
  • 326
  • 2
  • 13

1 Answers1

0
  • 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.
Gellaboina Ashish
  • 543
  • 2
  • 6
  • thanks @Ashish for KMS plugin repo. Two points - 1. I can use PV encryption in GKE without enabling application layer encryption. Clearly, something is still managing GKE KMS communication. 2. Where does it say, that API server creates DEK? That would also mean DEK sits in etcd storage. – C. Derx Oct 01 '21 at 12:14
  • [What happens when you create a Secret](https://cloud.google.com/kubernetes-engine/docs/how-to/encrypting-secrets#what_happens_when_you_create_a_secret) explains how a DEK is created, encrypted and stored. It also states that the KMS plugin handles communication between cluster and the KMS, since GKE is a fully managed K8s service maybe these are handled internally. Yes, the k8s API server stores both the encrypted secret and DEK in etcd and the k8s API server creates a cache entry mapping the encrypted DEK to the plaintext DEK. This lets it decrypt the Secret without using Cloud KMS. – Gellaboina Ashish Oct 01 '21 at 14:21
  • The link above is for "application layer encryption" offered by GKE, which is etcd secret focussed. This is different to PV encryption (I have checked that response to rotation, disable etc. is different in "app layer encryption" and PV one). So, I am not sure if above link is correct representation of PV case. – C. Derx Oct 01 '21 at 15:17
  • Another point: I also created own K8s cluster in GCP using compute engine (not GKE). PV encryption using KEK in Cloud KMS still works, without "K8S KMS Plugin for Google CloudKMS". So I am baffled on implementation under the hood. – C. Derx Oct 01 '21 at 15:21
  • @C.Derx, I've modified my Solution, hope this helps. – Gellaboina Ashish Oct 05 '21 at 10:42