Informazioni sulla crittografia CMEK di Backup per GKE

Autopilot Standard

Per impostazione predefinita, Backup per GKE cripta i contenuti dei clienti at rest. Backup per GKE gestisce la crittografia per te senza ulteriori azioni da parte tua. Questa opzione è denominata crittografia predefinita di Google.

Se vuoi controllare le chiavi di crittografia, puoi utilizzare le chiavi di crittografia gestite dal cliente (CMEK) in Cloud KMS con i servizi integrati con CMEK, incluso Backup per GKE. L'utilizzo delle chiavi Cloud KMS ti consente di controllare il livello di protezione , la località, la pianificazione della rotazione, le autorizzazioni di utilizzo e di accesso e i limiti crittografici. Con Cloud KMS puoi anche visualizzare gli audit log e controllare i cicli di vita delle chiavi. Invece di Google, sei tu ad avere la proprietà e la gestione delle chiavi di crittografia della chiave (KEK) simmetriche che proteggono i tuoi dati. Puoi controllare e gestire queste chiavi in Cloud KMS.

Dopo aver configurato le risorse con le CMEK, l'esperienza di accesso alle risorse di Backup per GKE è simile all'utilizzo della crittografia predefinita di Google. Per saperne di più sulle opzioni di crittografia, consulta Chiavi di crittografia gestite dal cliente (CMEK).

Panoramica

Esistono due tipi di artefatti di dati utente prodotti e archiviati da Backup per GKE:

• Backup della configurazione: un insieme di descrizioni delle risorse Kubernetes estratte dal server API del cluster di cui viene eseguito il backup, che acquisiscono lo stato del cluster.
• Backup dei volumi: un insieme di backup dei volumi che corrispondono alle risorse PersistentVolumeClaim trovate nel backup della configurazione.

Per impostazione predefinita, tutti gli artefatti di backup prodotti da Backup per GKE vengono criptati in stato inattivo utilizzando una chiave fornita da Google.

Tuttavia, puoi scegliere di criptare questi artefatti utilizzando una chiave di crittografia gestita dal cliente (CMEK) gestita con il Cloud Key Management Service.

Abilitare la crittografia CMEK

L'abilitazione della crittografia CMEK prevede due passaggi:

• Assegna una chiave per criptare i backup prodotti per un BackupPlan.

• Concedi l'accesso alle chiavi appropriate da parte dei service account appropriati.

Per qualsiasi scenario di backup specifico, sono potenzialmente coinvolte tre chiavi CMEK:

• bplan_key: questa è la chiave a cui fai riferimento quando crei o aggiorni BackupPlan. Se possibile, questa chiave verrà utilizzata per criptare tutti gli artefatti di backup. Questa chiave deve trovarsi nella stessa regione di BackupPlan (vedi Informazioni sulle località delle risorse).

• orig_disk_key: se hai criptato i volumi di disco permanente utilizzando una chiave CMEK, i backup dei volumi prodotti da Backup per GKE per questi volumi verranno criptati con questa chiave, anche se è registrata una chiave diversa con BackupPlan.

• new_disk_key: questa è la chiave CMEK che vuoi utilizzare per criptare i volumi che hai ripristinato dal backup. A questa chiave fa riferimento StorageClass nel cluster di destinazione del ripristino.

Esistono tre service account diversi che potrebbero richiedere l'accesso alle chiavi CMEK:

• agent_robot: a questo account di servizio deve essere concesso l'accesso a bplan_key. Questo account di servizio avrà il formato: [e-mail], dove PROJECT_NUMBER è il numero del tuo Google Cloud progetto.

• gkebackup_service_agent: quando esegui il backup di volumi non criptati con CMEK, a questo account di servizio deve essere concesso l'accesso a bplan_key. Quando esegui il backup di volumi criptati con CMEK, a questo account di servizio deve essere concesso l'accesso a orig_disk_key. Questo account di servizio avrà il formato: [e-mail], dove PROJECT_NUMBER è il numero del tuo Google Cloud progetto.

• compute_service_agent: questo account di servizio viene utilizzato quando crei nuovi volumi criptati per un cluster e deve avere accesso a new_disk_key. Questo account di servizio avrà il formato: [e-mail], dove PROJECT_NUMBER è il numero del tuo Google Cloud progetto.

Se diskEncryptionKey.kmsKeyServiceAccount è impostato per i dischi, prima di creare un backup devi eseguire i seguenti passaggi:

• Disabilita il criterio dell'organizzazione iam.disableCrossProjectServiceAccountUsage per abilitare la simulazione dell'identità dei account di servizio tra progetti:

    gcloud resource-manager org-policies disable-enforce \
        iam.disableCrossProjectServiceAccountUsage
        --project=PROJECT_ID
  

• Concedi a gkebackup_service_agent il ruolo roles/iam.serviceAccountTokenCreator per creare credenziali di breve durata:

    gcloud iam service-accounts add-iam-policy-binding \
      # Replace the email with the value from
      # `diskEncryptionKey.kmsKeyServiceAccount`
      your-kms-key-service-acount@PROJECT_ID.iam.gserviceaccount.com \
      --member=[e-mail] \
      --role=roles/iam.serviceAccountTokenCreator
  

Se esegui un'operazione di backup o ripristino tra progetti, devono essere elencati tre nomi di progetto:

• cluster_project: il progetto che contiene il cluster di cui vuoi eseguire il backup.

• backup_project: il progetto in cui vuoi archiviare i backup.

• restore_project: il progetto che contiene il cluster di destinazione del ripristino.

La tabella seguente riassume a quali chiavi devono essere concessi i service account in vari scenari:

Artefatto	Service account	Numero progetto	Chiave
Cluster di backup della configurazione	agent_robot	cluster_project (durante il backup) restore_project (durante il ripristino)	bplan_key
Backup del volume criptato con CMEK	gkebackup_service_agent	backup_project	orig_disk_key
Backup del volume criptato con Google	gkebackup_service_agent	backup_project	bplan_key
Nuovo volume criptato con CMEK creato durante il ripristino	compute_service_agent	restore_project	new_disk_key

Puoi scegliere di concedere l'accesso alle chiavi a livello di progetto, il che concede l'accesso a tutte le chiavi del progetto, o alla singola chiave.

Concedere l'accesso a livello di progetto

Puoi concedere l'accesso alle chiavi a livello di progetto, il che concede l'accesso a tutte le chiavi del progetto.

Per concedere l'accesso a livello di progetto, attieniti alle istruzioni riportate di seguito.

Console

1. Nella Google Cloud console vai alla pagina IAM.

   Vai a IAM

2. Fai clic su Concedi l'accesso.

3. Nel campo Nuove entità, inserisci l'indirizzo email del account di servizio.

4. Nell'elenco Seleziona un ruolo, seleziona il ruolo Cloud KMS CryptoKey Encrypter/Decrypter.

5. Fai clic su Salva.

gcloud

1. Concedi l'accesso a livello di progetto.

   gcloud projects add-iam-policy-binding PROJECT_ID \
   --member serviceAccount:[e-mail] \
   --role roles/cloudkms.cryptoKeyEncrypterDecrypter
   

   Sostituisci quanto segue:

   • PROJECT_ID: l'ID del progetto a cui vuoi concedere l'accesso.
   • PROJECT_NUMBER: il numero del progetto a cui vuoi concedere l'accesso.

Terraform

1. Concedi l'accesso a livello di progetto.

   resource "google_project_iam_member" "example_iam_member" {
   project = "PROJECT_ID"
   role    = "roles/cloudkms.cryptoKeyEncrypterDecrypter"
   member  = "serviceAccount:[e-mail]"
   }
   

   Sostituisci quanto segue:

   • PROJECT_ID: l'ID del progetto a cui vuoi concedere l'accesso.
   • PROJECT_NUMBER: il numero del progetto a cui vuoi concedere l'accesso.

Concedere l'accesso a livello di chiave

Per concedere l'accesso a livello di singola chiave, attieniti alle istruzioni riportate di seguito.

Console

1. Nella Google Cloud console vai alla pagina Gestione delle chiavi.

   Vai a Gestione delle chiavi

2. Fai clic sul nome delle chiavi automatizzate.

3. Fai clic sul nome della chiave.

4. Fai clic sulla scheda Autorizzazioni.

5. Fai clic su Concedi l'accesso.

6. Nel campo Nuove entità, inserisci l'indirizzo email del account di servizio.

7. Nell'elenco Seleziona un ruolo, seleziona il ruolo Cloud KMS CryptoKey Encrypter/Decrypter.

8. Fai clic su Salva.

gcloud

1. Concedi l'accesso a livello di singola chiave.

   gcloud kms keys add-iam-policy-binding KEY_NAME \
   --keyring KEY_RING \
   --location LOCATION \
   --member "serviceAccount:[e-mail]" \
   --role roles/cloudkms.cryptoKeyEncrypterDecrypter
   

   Sostituisci quanto segue:

   • KEY_NAME: il nome della chiave.
   • KEY_RING: il nome delle chiavi automatizzate che contengono la chiave.
   • LOCATION: la posizione di Cloud KMS delle chiavi automatizzate.
   • PROJECT_NUMBER: il numero del progetto a cui vuoi concedere l'accesso.

Terraform

1. Concedi l'accesso a livello di singola chiave.

   resource "google_kms_crypto_key_iam_member" "crypto_key_iam_member" {
   crypto_key_id = "projects/PROJECT_ID/locations/LOCATION/keyRings/KEY_RING/cryptoKeys/KEY_NAME"
   role          = "roles/cloudkms.cryptoKeyEncrypterDecrypter"
   member        = "serviceAccount:[e-mail]" 
   }
   

   Sostituisci quanto segue:

   • PROJECT_ID: l'ID del progetto a cui vuoi concedere l'accesso.
   • LOCATION: la posizione di Cloud KMS delle chiavi automatizzate.
   • KEY_RING: il nome delle chiavi automatizzate che contengono la chiave.
   • KEY_NAME: il nome della chiave.
   • PROJECT_NUMBER: il numero del progetto a cui vuoi concedere l'accesso.

Considerazioni e limitazioni sull'utilizzo

• Se vuoi eseguire il backup di un volume criptato con CMEK, devi concedere l'accesso alla chiave del disco, anche se non abiliti la crittografia CMEK in BackupPlan.

• Le chiavi CMEK devono trovarsi nella stessa regione di BackupPlan per garantire che un'interruzione regionale non rimuova l'accesso alla chiave mentre i backup sono ancora accessibili. Tuttavia, questo vincolo non può essere applicato alle chiavi condivise con i volumi criptati. Quando sono coinvolti volumi criptati, è possibile che un ripristino non vada a buon fine anche se è disponibile un backup, perché la chiave di crittografia del disco potrebbe non essere archiviata nella stessa regione del backup.

Utilizzare e gestire le chiavi esterne

Puoi utilizzare Cloud External Key Manager (Cloud EKM) per creare e gestire le chiavi esterne. Le chiavi esterne sono puntatori a chiavi che risiedono all'esterno di Google Cloud. Queste chiavi risiedono con un partner di gestione delle chiavi esterne supportato. Per saperne di più, consulta Cloud External Key Manager.

Dopo aver creato una chiave esterna con Cloud EKM, puoi applicarla a un nuovo piano di backup fornendo l'ID della chiave quando crei un nuovo piano di backup. Questa procedura è la stessa dell'applicazione di una chiave Cloud KMS a un nuovo piano di backup.

Puoi utilizzare Key Access Justifications come parte di Cloud EKM. Key Access Justifications ti consente di visualizzare il motivo di ogni richiesta di Cloud EKM. Inoltre, in base alla giustificazione fornita, puoi approvare o negare automaticamente una richiesta. Per saperne di più, consulta Panoramica.

Nota: per utilizzare Key Access Justifications con Cloud EKM, puoi creare un nuovo piano di backup. Se devi applicare Key Access Justifications a un piano di backup esistente, aggiorna il piano di backup.