Utilizzo delle chiavi di crittografia gestite dal cliente (CMEK)

Questa pagina descrive come utilizzare le chiavi di crittografia gestite dal cliente (CMEK) su Google Kubernetes Engine (GKE). Se devi controllare la gestione delle tue chiavi, puoi utilizzare Cloud Key Management Service e CMEK per proteggere i dischi permanenti collegati e i dischi di avvio personalizzati nel tuo cluster GKE.

Panoramica

Per impostazione predefinita, Trusted Cloud by S3NS cripta i contenuti dei clienti inattivi e GKE gestisce la crittografia per te senza alcuna azione da parte tua.

Se vuoi controllare e gestire personalmente rotazione della chiave di crittografia, puoi utilizzare CMEK. Queste chiavi criptano le chiavi di crittografia dei dati che criptano i tuoi dati. Per maggiori informazioni, consulta Gestione delle chiavi.

Puoi anche criptare i secret nel cluster utilizzando chiavi che gestisci. Per maggiori dettagli, vedi Crittografia dei secret a livello di applicazione.

In GKE, CMEK può proteggere i dati di due tipi di dischi di archiviazione: dischi di avvio dei nodi e dischi collegati.

Dischi di avvio dei nodi

I dischi di avvio dei nodi fanno parte dei pool di nodi del cluster. Puoi creare un disco di avvio dei nodi criptato con CMEK quando crei cluster e pool di nodi.

Dischi collegati

I dischi collegati sono PersistentVolume utilizzati dai pod per l'archiviazione durevole. I dischi permanenti collegati criptati con CMEK sono disponibili in GKE come PersistentVolume con provisioning dinamico.

Per saperne di più sui dischi di archiviazione, vedi Opzioni di archiviazione. I dischi del control plane, utilizzati per i control plane GKE, non possono essere protetti con CMEK.

Prima di iniziare

1. Per svolgere gli esercizi di questo argomento, hai bisogno di due progetti Trusted Cloud :

   • Progetto chiave:è qui che crei una chiave di crittografia.

   • Progetto cluster:qui crei un cluster che attiva CMEK.

2. Nel progetto della chiave, assicurati di aver attivato l'API Cloud KMS.

   Abilita l'API Cloud KMS

3. Nel tuo progetto chiave, l'utente che crea la chiave automatizzata e la chiave deve disporre delle seguenti autorizzazioni IAM:

   • cloudkms.keyRings.getIamPolicy
   • cloudkms.keyRings.setIamPolicy

   Queste autorizzazioni vengono concesse al ruolo Identity and Access Management predefinito roles/cloudkms.admin. Puoi scoprire di più su come concedere le autorizzazioni per gestire le chiavi nella documentazione di Cloud KMS.

4. Nel progetto cluster, assicurati di aver abilitato l'API Cloud KMS.

   Abilita l'API Cloud KMS

5. Assicurati di aver installato gcloud CLI.

6. Aggiorna gcloud all'ultima versione:

   gcloud components update
   

Crea una chiave Cloud KMS

Prima di poter proteggere il disco di avvio del nodo o il disco collegato con una CMEK, devi disporre di un portachiavi e di una chiave Cloud KMS.

La chiave automatizzata e la chiave devono soddisfare i seguenti requisiti:

• La chiave deve utilizzare la crittografia simmetrica.

• Devi concedere le autorizzazioni al account di servizio GKE per utilizzare la chiave.

• Il keyring deve avere una posizione che corrisponda a quella del cluster GKE:

  • Un cluster di zona deve utilizzare un keyring da una località superset. Ad esempio, un cluster nella zona us-central1-a può utilizzare solo una chiave nella regione us-central1.

  • Un cluster regionale deve utilizzare un portachiavi della stessa località. Ad esempio, un cluster nella regione asia-northeast1 deve essere protetto con un keyring della regione asia-northeast1.

  • La regione global di Cloud KMS non è supportata per l'utilizzo con GKE.

Per istruzioni su come creare un portachiavi e una chiave, consulta Creazione di chiavi simmetriche.

Concedere l'autorizzazione per utilizzare la chiave

Devi concedere il ruolo IAM Autore crittografia/decrittografia CryptoKey Cloud KMS (roles/cloudkms.cryptoKeyEncrypterDecrypter) per la chiave Cloud KMS all' agente di servizio Compute Engine nel progetto del cluster. La concessione di questo ruolo consente ai dischi permanenti GKE di accedere alla tua chiave di crittografia e utilizzarla.

Per concedere il ruolo roles/cloudkms.cryptoKeyEncrypterDecrypter all'agente di servizio Compute Engine, seleziona una delle seguenti opzioni:

gcloud kms keys add-iam-policy-binding KEY_NAME \
    --location LOCATION \
    --keyring RING_NAME \
    --member serviceAccount:service-PROJECT_NUMBER@compute-system.s3ns-system.iam.gserviceaccount.com \
    --role roles/cloudkms.cryptoKeyEncrypterDecrypter \
    --project KEY_PROJECT_ID

Utilizza i dischi di avvio dei nodi protetti da CMEK

In questa sezione, crei un nuovo cluster o pool di nodi con un disco di avvio protetto da CMEK.

Non puoi abilitare la crittografia gestita dal cliente per i dischi di avvio dei nodi in un cluster esistente, in quanto non puoi modificare il tipo di disco di avvio di un cluster o di un pool di nodi esistente. Tuttavia, puoi creare un nuovo pool di nodi per il cluster con la crittografia gestita dal cliente abilitata ed eliminare il pool di nodi precedente.

Inoltre, non puoi disabilitare la crittografia gestita dal cliente per i dischi di avvio dei nodi in un cluster esistente o in un pool di nodi esistente. Tuttavia, puoi creare un nuovo node pool per il tuo cluster con la crittografia gestita dal cliente disattivata ed eliminare il pool di nodi precedente.

Crea un cluster con un disco di avvio dei nodi protetto da CMEK

Puoi creare un cluster con un disco di avvio del nodo protetto da CMEK utilizzando gcloud CLI o la console Trusted Cloud .

Per i cluster Standard, solo un disco permanente standard (pd-standard) o un disco permanente SSD (pd-ssd) può essere criptato con una chiave CMEK.

gcloud container clusters create CLUSTER_NAME \
    --cluster-version=latest \
    --location CONTROL_PLANE_LOCATION \
    --boot-disk-kms-key projects/KEY_PROJECT_ID/locations/LOCATION/keyRings/RING_NAME/cryptoKeys/KEY_NAME \
    --project CLUSTER_PROJECT_ID \
    --disk-type DISK_TYPE

gcloud container clusters create-auto CLUSTER_NAME \
    --cluster-version=latest \
    --location CONTROL_PLANE_LOCATION \
    --boot-disk-kms-key projects/KEY_PROJECT_ID/locations/LOCATION/keyRings/RING_NAME/cryptoKeys/KEY_NAME \
    --project CLUSTER_PROJECT_ID

Crea un nuovo pool di nodi con dischi di avvio dei nodi protetti da CMEK

Per creare un nuovo pool di nodi con CMEK abilitato in un cluster standard esistente, puoi utilizzare gcloud CLI o la console Trusted Cloud .

gcloud container node-pools create NODE_POOL_NAME \
    --location CONTROL_PLANE_LOCATION \
    --disk-type DISK_TYPE \
    --boot-disk-kms-key projects/KEY_PROJECT_ID/locations/LOCATION/keyRings/RING_NAME/cryptoKeys/KEY_NAME \
    --project CLUSTER_PROJECT_ID \
    --cluster CLUSTER_NAME

Utilizzare istanze Filestore o dischi permanenti protetti da CMEK

Le seguenti informazioni riguardano la crittografia delle istanze Filestore o dei dischi permanenti appena creati. Puoi attivare CMEK su un cluster nuovo o esistente, utilizzando una chiave Cloud KMS nuova o esistente.

Queste istruzioni devono essere completate una volta per ogni cluster GKE:

• Crea un cluster GKE, se non ne hai già uno disponibile.
• Esegui il deployment del driver CSI Filestore o del driver CSI per il disco permanente di Compute Engine nel cluster.
• Crea un keyring e una versione della chiave Cloud KMS, se non ne hai già uno disponibile.
• Concedi le autorizzazioni di accesso alla chiave al service account Filestore.
• Crea una StorageClass che consenta di criptare automaticamente i dischi di cui viene eseguito il provisioning da Kubernetes con quella chiave Cloud KMS. Per informazioni dettagliate su come procedere, consulta la sezione seguente.

Crea una StorageClass che faccia riferimento alla chiave Cloud KMS

1. Copia i contenuti riportati di seguito in un file YAML denominato cmek-sc.yaml. Questa configurazione consente il provisioning dinamico dei volumi criptati.

   Istanze Filestore

   apiVersion: storage.k8s.io/v1
   kind: StorageClass
   metadata:
     name: csi-filestore-cmek
   provisioner: filestore.csi.storage.gke.io
   allowVolumeExpansion: true
   parameters:
     tier: enterprise
     instance-encryption-kms-key: projects/KEY_PROJECT_ID/locations/LOCATION/keyRings/RING_NAME/cryptoKeys/KEY_NAME
   

   • Il campo instance-encryption-kms-key deve essere l'identificatore di risorsa completo della chiave che verrà utilizzata per criptare le nuove istanze Filestore.
   • I valori in instance-encryption-kms-key fanno distinzione tra maiuscole e minuscole (ad esempio, keyRings e cryptoKeys). Il provisioning di un nuovo volume con valori errati genera un errore invalidResourceUsage.
   • Non puoi aggiungere il parametro instance-encryption-kms-key a un oggetto StorageClass esistente. Tuttavia, puoi eliminare l'oggetto StorageClass e ricrearlo con lo stesso nome, ma un insieme diverso di parametri.

   Dischi permanenti

   apiVersion: storage.k8s.io/v1
   kind: StorageClass
   metadata:
     name: csi-gce-pd-cmek
   provisioner: pd.csi.storage.gke.io
   volumeBindingMode: "WaitForFirstConsumer"
   allowVolumeExpansion: true
   parameters:
     type: pd-standard
     disk-encryption-kms-key: projects/KEY_PROJECT_ID/locations/LOCATION/keyRings/RING_NAME/cryptoKeys/KEY_NAME
   

   • Il campo disk-encryption-kms-key deve essere l'identificatore di risorsa completo per la chiave che verrà utilizzata per criptare i nuovi dischi.
   • I valori in disk-encryption-kms-key fanno distinzione tra maiuscole e minuscole (ad esempio, keyRings e cryptoKeys). Il provisioning di un nuovo volume con valori errati genera un errore invalidResourceUsage.
   • Non puoi aggiungere il parametro disk-encryption-kms-key a un oggetto StorageClass esistente. Tuttavia, puoi eliminare l'oggetto StorageClass e ricrearlo con lo stesso nome, ma un insieme diverso di parametri. Assicurati che il provisioning del corso esistente sia pd.csi.storage.gke.io.

   Puoi impostare StorageClass come predefinita.

2. Esegui il deployment di StorageClass sul cluster GKE utilizzando kubectl:

   kubectl apply -f cmek-sc.yaml
   

3. Verifica che il tuo StorageClass abbia utilizzato il driver CSI per il disco permanente o Filestore di Compute Engine e includa l'ID della tua chiave:

   Istanze Filestore

   kubectl describe storageclass csi-filestore-cmek
   

   Nell'output del comando, verifica quanto segue:

   • Il provisioner è impostato su filestore.csi.storage.gke.io.
   • L'ID della chiave segue instance-encryption-kms-key.

   Name:                  csi-filestore-cmek
   IsDefaultClass:        No
   Annotations:           None
   Provisioner:           filestore.csi.storage.gke.io
   Parameters:            instance-encryption-kms-key=projects/KEY_PROJECT_ID/locations/LOCATION/keyRings/RING_NAME/cryptoKeys/KEY_NAME,type=pd-standard
   AllowVolumeExpansion:  true
   MountOptions:          none
   ReclaimPolicy:         Delete
   VolumeBindingMode:     WaitForFirstConsumer
   Events:                none
   

   Dischi permanenti

   kubectl describe storageclass csi-gce-pd-cmek
   

   Nell'output del comando, verifica quanto segue:

   • Il provisioning è impostato su pd.csi.storage.gke.io.
   • L'ID della chiave è disk-encryption-kms-key.

   Name:                  csi-gce-pd-cmek
   IsDefaultClass:        No
   Annotations:           None
   Provisioner:           pd.csi.storage.gke.io
   Parameters:            disk-encryption-kms-key=projects/KEY_PROJECT_ID/locations/LOCATION/keyRings/RING_NAME/cryptoKeys/KEY_NAME,type=pd-standard
   AllowVolumeExpansion:  unset
   MountOptions:          none
   ReclaimPolicy:         Delete
   VolumeBindingMode:     WaitForFirstConsumer
   Events:                none
   

Crea un volume di archiviazione criptato in GKE

In questa sezione, esegui il provisioning dinamico dei volumi di archiviazione Kubernetes criptati con la nuova chiave StorageClass e Cloud KMS.

1. Copia i seguenti contenuti in un nuovo file denominato pvc.yaml e assicurati che il valore di storageClassName corrisponda al nome dell'oggetto StorageClass:

   Istanze Filestore

   kind: PersistentVolumeClaim
   apiVersion: v1
   metadata:
     name: podpvc
   spec:
     accessModes:
       - ReadWriteMany
     storageClassName: csi-filestore-cmek
     resources:
       requests:
         storage: 1Ti
   

   Dischi permanenti

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

2. Applica il PersistentVolumeClaim (PVC) al tuo cluster GKE:

   kubectl apply -f pvc.yaml
   

3. Se il tuo StorageClass ha il campo volumeBindingMode impostato su WaitForFirstConsumer, devi creare un pod per utilizzare la PVC prima di poterla verificare. Copia i seguenti contenuti in un nuovo file denominato pod.yaml e assicurati che il valore di claimName corrisponda al nome dell'oggetto PersistentVolumeClaim:

   apiVersion: v1
   kind: Pod
   metadata:
     name: web-server
   spec:
     containers:
      - name: web-server
        image: nginx
        volumeMounts:
          - mountPath: /var/lib/www/html
            name: mypvc
     volumes:
      - name: mypvc
        persistentVolumeClaim:
          claimName: podpvc
          readOnly: false
   

4. Applica il pod al cluster GKE:

   kubectl apply -f pod.yaml
   

5. Ottieni lo stato di PersistentVolumeClaim del cluster e verifica che il PVC sia creato e associato a un PersistentVolume appena sottoposto a provisioning.

   Istanze Filestore

   kubectl get pvc
   

   L'output è simile al seguente:

   NAME      STATUS    VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS     AGE
   podpvc    Bound     pvc-e36abf50-84f3-11e8-8538-42010a800002   1Ti        RWO            csi-filestore-cmek  9s
   

   Dischi permanenti

   kubectl get pvc
   

   L'output è simile al seguente:

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

Ora puoi utilizzare il Persistent Disk protetto da CMEK con il tuo cluster GKE.

Rimuovere la protezione CMEK

Quando cripti un Persistent Disk utilizzando una chiave Cloud KMS, la crittografia è permanente. Non puoi rimuovere la chiave di crittografia da quel disco specifico, anche se elimini o disattivi la chiave Cloud KMS. L'unico modo per modificare la chiave di crittografia o rimuovere la protezione CMEK da unPersistent Diske è creare un nuovPersistent Diskte basato su uno snapshot del disco esistente. Per ulteriori informazioni, vedi Rimuovere la chiave di crittografia Cloud KMS da un disco permanente.

La crittografia CMEK non può essere rimossa dalle istanze Filestore.

Policy dell'organizzazione GKE e CMEK

GKE supporta le policy dell'organizzazione CMEK (anteprima) che possono richiedere la protezione CMEK e limitare le chiavi Cloud KMS che puoi utilizzare per la protezione CMEK.

Quando container.googleapis.com si trova nell'elenco dei servizi del criterio Deny per il vincolo constraints/gcp.restrictNonCmekServices, GKE rifiuta di creare le seguenti risorse se non abiliti la protezione CMEK:

• Nuovi cluster e node pool
• Nuove istanze Filestore e nuovi dischi permanenti

Quando il vincolo constraints/gcp.restrictNonCmekCryptoKeyProjects è configurato in una policy dell'organizzazione, GKE crea solo risorse protette da CMEK che utilizzano una chiave di crittografia di un progetto, una cartella o un'organizzazione consentiti.

Passaggi successivi

• Leggi le domande frequenti su Cloud Key Management Service.
• Scopri di più sulla protezione delle risorse con le chiavi Cloud KMS.