Using customer-managed encryption keys (CMEK)

Beta

Este produto ou recurso está em um estado de pré-lançamento e pode ser alterado ou ter suporte limitado. Para mais informações, consulte Estágios de lançamento do produto.

This topic describes how to use Customer Managed Encryption Keys (CMEK) on Google Kubernetes Engine (GKE). If you have a need to control management of your keys, you can use Cloud Key Management Service and CMEK to protect Persistent Disks in your GKE cluster.

Overview

By default, Google Cloud Platform encrypts customer content at rest, and GKE manages encryption for you without any action on your part.

If you want to control and manage encryption key rotation yourself, you can use Customer Managed Encryption Keys (CMEK). These keys are used to encrypt the data encryption keys that encrypt your data. For more information, see Key management.

CMEK-encrypted disks are available in GKE as a dynamically provisioned PersistentVolume.

In GKE, CMEK can protect data on persistent disks attached to nodes in your cluster. Boot disks and control plane disks cannot be protected with CMEK.

Note: You cannot use your own keys with local SSDs. Local SSDs are already protected with an ephemeral encryption key that Google does not retain. See restrictions for customer-managed encryption keys.

Before you begin

Complete these instructions to encrypt newly created Persistent Disks. You can enable CMEK on a new or existing cluster, using a new or existing Cloud KMS key.

These instructions need to be completed once per GKE cluster. They create:

• A new GKE cluster (if necessary).
• A new Cloud KMS key ring, key, and key version (if necessary).
• A StorageClass that enables disks provisioned by Kubernetes to automatically be encrypted with that Cloud KMS key.

Note: If you are configuring CMEK with a regional cluster, the cluster must run GKE 1.14 or higher and the Compute Engine Persistent Disk CSI Driver v0.5.1 or higher.

1. If necessary, Create a GKE Cluster.
2. Deploy the Compute Engine Persistent Disk CSI Driver to your cluster.

3. Enable the Cloud KMS API and create a key by completing the "Before you begin" section of Protecting Resources with Cloud KMS Keys, following the next step below.

   1. Create a key ring in the same region as your GKE Cluster.
   2. Assign the Cloud KMS CryptoKey Encrypter/Decrypter role (roles/cloudkms.cryptoKeyEncrypterDecrypter) to the Compute Engine Service Agent (service-[PROJECT_NUMBER]@compute-system.iam.gserviceaccount.com). This allows GKE to access the key.

Create a StorageClass referencing the new KMS key

1. Copy the content below into a YAML file. For the rest of this page, we will call it gcepd-sc.yaml. This configuration enables dynamic provisioning of encrypted volumes.

   apiVersion: storage.k8s.io/v1beta1
   kind: StorageClass
   metadata:
     name: csi-gce-pd
   provisioner: pd.csi.storage.gke.io
   parameters:
     type: pd-standard
     disk-encryption-kms-key: projects/[KMS_PROJECT_ID]/locations/[REGION]/keyRings/[KEY_RING]/cryptoKeys/[KEY]
   

   • disk-encryption-kms-key must be the fully qualified resource identifier for the key that will be used to encrypt new disks. Replace the items inside square brackets as appropriate to reference your KMS key.
   • The values in disk-encryption-kms-key (for example: keyRings and cryptoKeys) are case sensitive. Provisioning a new volume with incorrect values results in an invalidResourceUsage error.
   • You can set the StorageClass as the default.
   Note: if you already have an existing StorageClass for provisioner:pd.csi.storage.gke.io, you may modify that StorageClass to include the new "disk-encryption-kms-key" parameter and re-apply the configuration.

2. Deploy the StorageClass on your GKE cluster using kubectl:

   kubectl apply -f gcepd-sc.yaml

3. Finally, verify that your StorageClass used the Compute Engine Persistent Disk CSI driver and includes the ID of your Key.

In the output of the command, verify:

• The provisioner is set as pd.csi.storage.gke.io.

• The ID of your key follows disk-encryption-kms-key.

  kubectl describe storageclass csi-gce-pd

  Name:                  csi-gce-pd
  IsDefaultClass:        No
  Annotations:           None
  Provisioner:           pd.csi.storage.gke.io
  Parameters:
  **disk-encryption-kms-key=projects/my-project/locations/my-location/keyRings/my-keyring/cryptoKeys/my-key,type=pd-standard**
  AllowVolumeExpansion:  unset
  MountOptions:          none
  ReclaimPolicy:         Delete
  VolumeBindingMode:     WaitForFirstConsumer
  Events:                none
  

Create an encrypted Persistent Disk in GKE

In this section, you will dynamically provision encrypted Kubernetes storage volumes with your new StorageClass and Cloud KMS key.

Dynamically provision an encrypted Compute Engine Persistent Disk

1. Copy the contents below into a new file named pvc.yaml, and update storageClassName with the name of your newly created StorageClass.

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: podpvc
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: csi-gce-pd
  resources:
    requests:
      storage: 6Gi

Note: If you marked the new StorageClass as default, then you may omit "storageClassName".

1. Apply the PersistentVolumeClaim (PVC) on your GKE cluster using kubectl:

   kubectl apply -f pvc.yaml

2. Verify the PVC is created and bound to a newly provisioned PersistentVolume by getting the status of your cluster's PersistentVolumeClaim.

   kubectl get pvc

   NAME      STATUS    VOLUME
   CAPACITY   ACCESS MODES   STORAGECLASS   AGE
   podpvc     Bound     pvc-e36abf50-84f3-11e8-8538-42010a800002   10Gi
       RWO            csi-gce-pd     9s
   

You can now use your CMEK-protected Persistent Disk with your GKE cluster.

Removing CMEK protection from a Persistent Disk

To remove CMEK protection from a Persistent Disk, follow the instructions in the Compute Engine documentation.

Next Steps

For more information on CMEK, see:

• Cloud Key Management Service FAQ
• Protecting resources with Cloud KMS Keys