Questa pagina descrive come funziona il supporto delle chiavi di crittografia gestite dal cliente (CMEK) in Backup per GKE.
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 in fase di backup, che acquisisce lo stato del cluster.
- Backup di volumi: un insieme di backup di volumi che corrispondono alle risorse
PersistentVolumeClaim
trovate nel backup di configurazione.
Per impostazione predefinita, tutti gli artefatti di backup prodotti da Backup per GKE vengono criptati at-rest utilizzando una chiave fornita da Google.
Tuttavia, puoi scegliere di criptare questi artefatti utilizzando una chiave di crittografia gestita dal cliente (CMEK) gestita con Cloud Key Management Service.
Attivare la crittografia CMEK
L'attivazione della crittografia CMEK prevede due passaggi:
Specifica una chiave per criptare i backup prodotti per una
BackupPlan
.Concedi l'accesso alle chiavi appropriate da parte degli account di servizio appropriati.
Per ogni particolare scenario di backup, potenzialmente sono coinvolte tre chiavi CMEK:
bplan_key
: questa è la chiave a cui fai riferimento durante la creazione o l'aggiornamento diBackupPlan
. Quando possibile, questa chiave verrà utilizzata durante la crittografia di tutti gli artefatti di backup. Questa chiave deve trovarsi nella stessa regione dell'oggettoBackupPlan
stesso (consulta Informazioni sulle località delle risorse).orig_disk_key
: se hai criptato i volumi dei 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 viene registrata una chiave diversa conBackupPlan
.new_disk_key
: questa è la chiave CMEK che vuoi utilizzare per criptare i volumi che hai ripristinato dal backup. Questo viene fatto riferimento daStorageClass
nel cluster di destinazione del ripristino.
Esistono cinque diversi account di servizio che potrebbero richiedere l'accesso alle chiavi CMEK:
agent_wi
: se esegui la versione di anteprima dell'agente (cluster GKE con versione 1.23 o precedente), a questo account di servizio deve essere concesso l'accesso abplan_key
. Questo account di servizio avrà il formato:PROJECT_ID.svc.id.goog[gkebackup/agent]
, dovePROJECT_ID
è l'ID del tuo progetto Google Cloud.agent_robot
: se i tuoi cluster GKE eseguono la versione 1.24 o successive, a questo account di servizio deve essere concesso l'accesso abplan_key
. Questo account di servizio avrà il formato:service-PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com
, dovePROJECT_NUMBER
è il numero del tuo progetto Google Cloud.non_cmek_service_agent
: durante il backup di volumi non criptati con CMEK, è necessario concedere a questo account di servizio l'accesso abplan_key
. Questo account di servizio avrà il modulo:service-PROJECT_NUMBER@gcp-sa-gkebackup.iam.gserviceaccount.com
, dovePROJECT_NUMBER
è il numero del tuo progetto Google Cloud.cmek_service_agent
: durante il backup dei volumi criptati con CMEK, è necessario concedere a questo account di servizio l'accesso aorig_disk_key
. Questo account di servizio avrà il modulo:service-TENANT_PROJECT_NUMBER@compute-system.iam.gserviceaccount.com
, doveTENANT_PROJECT_NUMBER
è il numero del progetto tenant assegnato alla tuaBackupPlan
.compute_service_agent
: questo account di servizio viene utilizzato durante la creazione di nuovi volumi criptati per un cluster e deve disporre dell'accesso anew_disk_key
. Questo account di servizio avrà il formato:service-PROJECT_NUMBER@compute-system.iam.gserviceaccount.com
, dovePROJECT_NUMBER
è il numero del tuo progetto Google Cloud.
Se diskEncryptionKey.kmsKeyServiceAccount è impostato per i dischi, devi eseguire i seguenti passaggi prima di creare un backup:
Disabilita il criterio dell'organizzazione
iam.disableCrossProjectServiceAccountUsage
per abilitare la simulazione dell'identità degli account di servizio tra progetti:gcloud resource-manager org-policies disable-enforce \ iam.disableCrossProjectServiceAccountUsage --project=PROJECT_ID
Concedi a
cmek_service_agent
il ruoloroles/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=service-TENANT_PROJECT_NUMBER@compute-system.iam.gserviceaccount.com \ --role=roles/iam.serviceAccountTokenCreator
La seguente tabella riassume a quali account di servizio deve essere concesso l'accesso alle chiavi in vari scenari:
Artefatto | Account di servizio | Chiave |
---|---|---|
backup della configurazione, cluster 1.23 | agent_wi | bplan_key |
backup della configurazione, cluster 1.24 e versioni successive | agent_robot | bplan_key |
backup del volume criptato con CMEK | cmek_service_agent | orig_disk_key |
backup del volume criptato da Google | non_cmek_service_agent | bplan_key |
nuovo volume criptato con CMEK creato durante il ripristino | compute_service_agent | new_disk_key |
Puoi scegliere di concedere l'accesso alle chiavi a livello di progetto, così da concedere l'accesso a tutte le chiavi nel progetto, oppure alla singola chiave.
Esempio: concedere l'accesso a livello di progetto
gcloud projects add-iam-policy-binding PROJECT_ID \
--member serviceAccount:service-PROJECT_NUMBER@gcp-sa-gkebackup.iam.gserviceaccount.com \
--role roles/cloudkms.cryptoKeyEncrypterDecrypter
Esempio: concedere l'accesso a livello di chiave
gcloud kms keys add-iam-policy-binding key \
--keyring key-ring \
--location location \
--member "serviceAccount:PROJECT_ID.svc.id.goog[gkebackup/agent]" \
--role roles/cloudkms.cryptoKeyEncrypterDecrypter
Considerazioni e limitazioni sull'utilizzo
Se vuoi eseguire il backup di un volume criptato con CMEK, devi concedere l'accesso alla chiave di quel 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 in modo forzato alle chiavi condivise con volumi criptati. Quando sono coinvolti volumi criptati, è possibile che un ripristino non vada a buon fine anche quando è disponibile un backup, in quanto la chiave di crittografia del disco potrebbe non essere archiviata nella stessa regione del backup.