Información acerca de CMEK en Copia de seguridad para GKE

Autopilot Estándar

En esta página, se describe cómo funciona la compatibilidad con la clave de encriptación administrada por el cliente (CMEK) en Copia de seguridad para GKE.

Descripción general

Existen dos tipos de artefactos de datos del usuario que la Copia de seguridad para GKE produce y almacena:

Copia de seguridad de configuración: Un conjunto de descripciones de recursos de Kubernetes extraído del servidor de la API del clúster que se somete a una copia de seguridad y que captura el estado del clúster.
Copias de seguridad de volúmenes: Un conjunto de copias de seguridad de volúmenes que corresponden a los recursos PersistentVolumeClaim que se encuentran en la copia de seguridad de la configuración.

De forma predeterminada, todos los artefactos que produce la Copia de seguridad para GKE se encriptan en reposo con una clave proporcionada por Google.

Sin embargo, puedes elegir que estos artefactos se encripten a través de una clave de encriptación administrada por el cliente (CMEK) que se administra con Cloud Key Management Service.

Habilita la encriptación de CMEK

La habilitación de la encriptación de CMEK implica dos pasos:

Designa una clave para encriptar las copias de seguridad producidas para un BackupPlan.
Otorga acceso a las claves correspondientes mediante las cuentas de servicio adecuadas.

Para cualquier situación de copia de seguridad específica, puede haber tres claves CMEK involucradas:

bplan_key: Esta es la clave a la que haces referencia cuando creas o actualizas BackupPlan. Cuando sea posible, esta clave se usará para encriptar todos los artefactos de la copia de seguridad. Esta clave debe estar en la misma región que el BackupPlan (consulta Acerca de las ubicaciones de los recursos).
orig_disk_key: Si encriptaste los volúmenes de discos persistentes con una clave CMEK, las copias de seguridad de volumen que produce la Copia de seguridad para GKE para esos volúmenes se encriptarán con esta clave, incluso si se registra una clave diferente con el BackupPlan.
new_disk_key: Esta es la clave CMEK que deseas usar para encriptar volúmenes que restableciste desde la copia de seguridad. StorageClass hace referencia a esta en el clúster de destino del restablecimiento.

Hay cinco cuentas de servicio diferentes que pueden requerir acceso a las claves CMEK:

agent_wi: Si ejecutas la versión de vista previa del agente (clústeres de GKE que ejecutan la versión 1.23 o una anterior), esta cuenta de servicio debe tener acceso a bplan_key. Esta cuenta de servicio tendrá el siguiente formato: PROJECT_ID.svc.id.goog[gkebackup/agent], en el que PROJECT_ID es el ID de tu proyecto de Google Cloud.
agent_robot: si tus clústeres de GKE ejecutan la versión 1.24 o superior, esta cuenta de servicio debe tener acceso a bplan_key. Esta cuenta de servicio tendrá el siguiente formato: service-PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com, en el que PROJECT_NUMBER es el número de tu proyecto de Google Cloud.
non_cmek_service_agent: Cuando se crean copias de seguridad de volúmenes no encriptados con CMEK, esta cuenta de servicio debe tener acceso a bplan_key. Esta cuenta de servicio tendrá el siguiente formato: service-PROJECT_NUMBER@gcp-sa-gkebackup.iam.gserviceaccount.com, en el que PROJECT_NUMBER es el número de tu proyecto de Google Cloud.
cmek_service_agent: Cuando se crean copias de seguridad de volúmenes encriptados con CMEK, esta cuenta de servicio debe tener acceso a orig_disk_key. Esta cuenta de servicio tendrá el siguiente formato: service-TENANT_PROJECT_NUMBER@compute-system.iam.gserviceaccount.com, en el que TENANT_PROJECT_NUMBER es el número del proyecto de usuario asignado a tu BackupPlan.

Precaución: Si el permiso de la copia de seguridad incluye un volumen encriptado con CMEK, fallará el VolumeBackup asociado a ese volumen. El campo stateMessage del recurso VolumeBackup contendrá un mensaje de error que identifica la cuenta de servicio (la cmek_service_agent) que se debe otorgar Acceso a orig_disk_key Puedes ver los recursos VolumeBackup con el comando gcloud beta container backup-restore volume-backups list y pasar --format=yaml para ver todos los campos.
compute_service_agent: Esta cuenta de servicio se usa cuando se crean nuevos volúmenes encriptados para un clúster y se le debe otorgar acceso a new_disk_key. Esta cuenta de servicio tendrá el siguiente formato: service-PROJECT_NUMBER@compute-system.iam.gserviceaccount.com, en el que PROJECT_NUMBER es el número de tu proyecto de Google Cloud.

Si diskEncryptionKey.kmsKeyServiceAccount está configurado para los discos, deberás realizar los siguientes pasos antes de crear una copia de seguridad:

Inhabilita la política de la organización iam.disableCrossProjectServiceAccountUsage para habilitar el uso de la identidad temporal como cuenta de servicio en todos los proyectos:
```
  gcloud resource-manager org-policies disable-enforce \
      iam.disableCrossProjectServiceAccountUsage
      --project=PROJECT_ID
```

Otorga a cmek_service_agent el rol de roles/iam.serviceAccountTokenCreator para crear credenciales de corta duración:

  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

En la siguiente tabla, se resume qué cuentas de servicio deben tener acceso a qué claves en varias situaciones:

Artefacto	Cuenta de servicio	Clave
copia de seguridad de configuración, clúster 1.23 o anterior	agent_wi	bplan_key
copia de seguridad de configuración, clúster 1.24 o superior	agent_robot	bplan_key
copia de seguridad del volumen encriptado con CMEK	cmek_service_agent	orig_disk_key
copia de seguridad del volumen encriptado por Google	non_cmek_service_agent	bplan_key
Volumen nuevo encriptado con CMEK creado durante el restablecimiento	compute_service_agent	new_disk_key

Puedes optar por otorgar acceso a las claves a nivel de proyecto, lo que otorga acceso a todas las claves de ese proyecto o a la clave individual.

Ejemplo: Otorga acceso a nivel de proyecto

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

Ejemplo: Otorga acceso a nivel de clave

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

Limitaciones y consideraciones de uso

Si deseas crear una copia de seguridad de un volumen encriptado con CMEK, debes otorgar acceso a la clave de ese disco, incluso si no habilitas la encriptación de CMEK en el BackupPlan.
Las claves CMEK deben estar en la misma región que BackupPlan para garantizar que una interrupción regional no quite el acceso a la clave mientras las copias de seguridad aún son accesibles. Sin embargo, esta restricción no se puede aplicar para las claves compartidas con volúmenes encriptados. Cuando se usan volúmenes encriptados, es posible que una restauración falle, incluso cuando hay una copia de seguridad disponible, porque la clave de encriptación del disco puede no estar almacenada en la misma región que la copia de seguridad.