À propos du chiffrement CMEK dans la Sauvegarde pour GKE

Autopilot Standard

Cette page décrit le fonctionnement de la gestion des clés de chiffrement gérées par le client (CMEK) dans le cadre de la Sauvegarde pour GKE.

Présentation

Deux types d'artefacts de données utilisateur sont produits et stockés via la Sauvegarde pour GKE :

Sauvegarde de configurations : ensemble de descriptions de ressources Kubernetes extraites du serveur d'API du cluster en cours de sauvegarde, capturant l'état du cluster.
Sauvegardes de volumes : ensemble de sauvegardes de volume correspondant aux ressources PersistentVolumeClaim trouvées dans la sauvegarde de configuration.

Par défaut, tous les artefacts de sauvegarde générés via la Sauvegarde pour GKE sont chiffrés au repos à l'aide d'une clé fournie par Google.

Toutefois, vous pouvez choisir de chiffrer ces artefacts à l'aide d'une clé de chiffrement gérée par le client (CMEK) via Cloud Key Management Service.

Activer le chiffrement CMEK

L'activation du chiffrement CMEK implique deux étapes :

Désignez une clé pour chiffrer les sauvegardes générées pour un BackupPlan.
Accordez aux comptes de service appropriés l'accès aux clés appropriées.

Pour tout scénario de sauvegarde particulier, il existe potentiellement trois clés CMEK impliquées :

bplan_key : il s'agit de la clé que vous référencez lors de la création ou de la mise à jour du BackupPlan. Dans la mesure du possible, cette clé sera utilisée lors du chiffrement de tous les artefacts de sauvegarde. Cette clé doit se trouver dans la même région que le BackupPlan lui-même (consultez la section À propos des emplacements de ressources).
orig_disk_key : si vous avez chiffré vos volumes de disques persistants à l'aide d'une clé CMEK, les sauvegardes de volume générées par la Sauvegarde pour GKE pour ces volumes sont chiffrées avec cette clé, même si une clé différente est enregistrée auprès du BackupPlan.
new_disk_key : il s'agit de la clé CMEK que vous souhaitez utiliser pour chiffrer les volumes que vous avez restaurés à partir d'une sauvegarde. Il est référencé par la valeur StorageClass dans le cluster cible restauré.

Cinq comptes de service différents peuvent nécessiter l'accès aux clés CMEK :

agent_wi : Si vous exécutez la version preview de l'agent (clusters GKE exécutant la version 1.23 ou antérieure), ce compte de service doit être autorisé à accéder à la clé bplan_key. Ce compte de service se présente sous la forme suivante : PROJECT_ID.svc.id.goog[gkebackup/agent], où PROJECT_ID est l'ID de votre projet Google Cloud.
agent_robot : si vos clusters GKE exécutent la version 1.24 ou une version ultérieure, ce compte de service doit être autorisé à accéder à la clé bplan_key. Ce compte de service se présente sous la forme suivante : service-PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com, où PROJECT_NUMBER est le numéro de votre projet Google Cloud.
non_cmek_service_agent : lors de la sauvegarde de volumes non chiffrés par CMEK, ce compte de service doit disposer d'un accès à la clé bplan_key. Ce compte de service se présente sous la forme suivante : service-PROJECT_NUMBER@gcp-sa-gkebackup.iam.gserviceaccount.com, où PROJECT_NUMBER est le numéro de votre projet Google Cloud.
cmek_service_agent : lors de la sauvegarde de volumes chiffrés par CMEK, ce compte de service doit disposer d'un accès à la clé orig_disk_key. Ce compte de service se présente sous la forme suivante : service-TENANT_PROJECT_NUMBER@compute-system.iam.gserviceaccount.com, où TENANT_PROJECT_NUMBER est le numéro du projet locataire attribué à votre BackupPlan.

Attention : Si le champ d'application de la sauvegarde inclut un volume chiffré par CMEK, la valeur VolumeBackup associée à ce volume échouera. Le champ stateMessage de la ressource VolumeBackup contiendra un message d'erreur qui identifie le compte de service (cmek_service_agent) auquel l'accès à la clé orig_disk_key doit être accordé. Vous pouvez afficher les ressources VolumeBackup à l'aide de la commande gcloud beta container backup-restore volume-backups list en transmettant --format=yaml pour tous les champs.
compute_service_agent : ce compte de service est utilisé lors de la création de nouveaux volumes chiffrés pour un cluster et doit être autorisé à accéder à la clé new_disk_key. Ce compte de service se présente sous la forme suivante : service-PROJECT_NUMBER@compute-system.iam.gserviceaccount.com, où PROJECT_NUMBER est le numéro de votre projet Google Cloud.

Si diskEncryptionKey.kmsKeyServiceAccount est défini pour les disques, vous devez suivre la procédure suivante avant de créer une sauvegarde :

Désactivez la règle d'administration iam.disableCrossProjectServiceAccountUsage pour activer l'emprunt d'identité des comptes de service entre projets :
```
  gcloud resource-manager org-policies disable-enforce \
      iam.disableCrossProjectServiceAccountUsage
      --project=PROJECT_ID
```

Attribuez à cmek_service_agent le rôle roles/iam.serviceAccountTokenCreator pour créer des identifiants éphémères :

  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

Le tableau suivant récapitule les comptes de service autorisés à accéder aux clés dans différents scénarios :

Artefact	Compte de service	Clé
Sauvegarde de configuration, cluster 1.23-	agent_wi	bplan_key
Sauvegarde de configuration, cluster 1.24+	agent_robot	bplan_key
Sauvegarde d'un volume chiffré par CMEK	cmek_service_agent	orig_disk_key
Sauvegarde d'un volume chiffré par Google	non_cmek_service_agent	bplan_key
Nouveau volume chiffré par CMEK créé lors de la restauration	compute_service_agent	new_disk_key

Vous pouvez choisir d'accorder l'accès aux clés au niveau du projet (accorde l'accès à toutes les clés situées sous ce projet) ou à la clé individuelle.

Exemple : Accorder un accès au niveau du projet

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member serviceAccount:service-PROJECT_NUMBER@gcp-sa-gkebackup.iam.gserviceaccount.com \
    --role roles/cloudkms.cryptoKeyEncrypterDecrypter

Exemple : Accorder un accès au niveau de la clé

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

Remarques et limites concernant l'utilisation

Si vous souhaitez sauvegarder un volume chiffré par CMEK, vous devez accorder l'accès à la clé de ce disque, même si vous n'activez pas le chiffrement CMEK dans votre fichier BackupPlan.
Les clés CMEK doivent se trouver dans la même région que le BackupPlan pour garantir qu'une panne régionale ne supprimera pas l'accès à la clé tant que les sauvegardes sont toujours accessibles. Toutefois, cette contrainte ne peut pas être appliquée aux clés partagées avec des volumes chiffrés. En cas de volumes chiffrés, une restauration peut échouer même lorsqu'une sauvegarde est disponible, car la clé de chiffrement du disque peut ne pas être stockée dans la même région que la sauvegarde.