Sobre a criptografia CMEK de backup para o GKE

Nesta página, descrevemos como o suporte a chaves de criptografia gerenciadas pelo cliente (CMEK) funciona no Backup para GKE.

Visão geral

Há dois tipos de artefatos de dados do usuário produzidos e armazenados pelo Backup para GKE:

  • Backup de configuração: um conjunto de descrições de recursos do Kubernetes extraídas do servidor da API do cluster que está passando pelo backup, capturando o estado do cluster.
  • Backups de volume: um conjunto de backups de volume que correspondem aos recursos PersistentVolumeClaim encontrados no backup de configuração.

Por padrão, todos os artefatos de backup produzidos pelo Backup para GKE são criptografados em repouso usando uma chave fornecida pelo Google.

No entanto, você tem a opção de criptografar esses artefatos usando uma chave de criptografia gerenciada pelo cliente (CMEK) gerenciada pelo Cloud Key Management Service.

Ativar criptografia CMEK

A ativação da criptografia CMEK envolve duas etapas:

  • Designação de uma chave para criptografar backups produzidos para um BackupPlan.

  • Conceder acesso às contas de serviço apropriadas às chaves apropriadas.

Para qualquer cenário de backup específico, é possível que três chaves CMEK estejam envolvidas:

  • bplan_key: é a chave que você referencia ao criar ou atualizar o BackupPlan. Quando possível, essa chave será usada ao criptografar todos os artefatos de backup. Essa chave precisa estar na mesma região que o próprio BackupPlan. Consulte Sobre locais de recursos.

  • orig_disk_key: se você tiver criptografado os volumes de discos permanentes usando uma chave CMEK, os backups de volume que o Backup para GKE produzir para esses volumes serão criptografados com essa chave, mesmo se outra chave for registrada com o BackupPlan.

  • new_disk_key: esta é a chave CMEK que você quer usar para criptografar volumes restaurados do backup. Isso é referenciado pelo StorageClass no cluster de destino da restauração.

Há cinco contas de serviço diferentes que podem exigir acesso a chaves CMEK:

  • agent_wi: se você estiver executando a versão de pré-lançamento do agente (clusters do GKE executando a versão 1.23 ou anterior), essa conta de serviço precisará receber acesso ao bplan_key. Essa conta de serviço terá o formato: PROJECT_ID.svc.id.goog[gkebackup/agent], em que PROJECT_ID é o ID do projeto do Google Cloud.

  • agent_robot: se os clusters do GKE estiverem executando a versão 1.24 ou superior, essa conta de serviço precisará receber acesso ao bplan_key. Essa conta de serviço terá o formato: service-PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com, em que PROJECT_NUMBER é o número do seu projeto do Google Cloud.

  • non_cmek_service_agent: ao fazer backup de volumes não criptografados por CMEK, essa conta de serviço precisa ter acesso a bplan_key. Essa conta de serviço vai ter o formato: service-PROJECT_NUMBER@gcp-sa-gkebackup.iam.gserviceaccount.com, em que PROJECT_NUMBER é o número do seu projeto do Google Cloud.

  • cmek_service_agent: ao fazer backup de volumes criptografados pelo CMEK, essa conta de serviço precisa receber acesso a orig_disk_key. Essa conta de serviço vai ter o formato: service-TENANT_PROJECT_NUMBER@compute-system.iam.gserviceaccount.com, em que TENANT_PROJECT_NUMBER é o número do projeto de locatário atribuído ao seu BackupPlan.

  • compute_service_agent: essa conta de serviço é usada ao criar novos volumes criptografados de um cluster e precisa receber acesso ao new_disk_key. Essa conta de serviço terá o formato: service-PROJECT_NUMBER@compute-system.iam.gserviceaccount.com, em que PROJECT_NUMBER é o número do seu projeto do Google Cloud.

Se diskEncryptionKey.kmsKeyServiceAccount estiver definido para os discos, execute as seguintes etapas antes de criar um backup:

  • Desative a política da organização iam.disableCrossProjectServiceAccountUsage para ativar a representação de conta de serviço em todos os projetos:

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

  • Conceda a cmek_service_agent o papel roles/iam.serviceAccountTokenCreator para criar credenciais de curta duração:

      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

Veja na tabela a seguir quais contas de serviço precisam receber acesso a quais chaves em vários cenários:

Artefato Conta de serviço Chave
backup de configuração, 1.23-cluster agent_wi bplan_key
backup de configuração, cluster 1.24+ agent_robot bplan_key
backup de volume criptografado por CMEK cmek_service_agent orig_disk_key
backup de volume criptografado pelo Google non_cmek_service_agent bplan_key
novo volume criptografado por CMEK criado durante a restauração compute_service_agent new_disk_key

É possível conceder acesso a chaves para envolvidos no projeto, que concede acesso a todas as chaves abaixo desse projeto, ou à chave individual.

Exemplo: conceder acesso no nível do projeto

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

Exemplo: conceder acesso no nível da chave

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

Considerações e limitações de uso

  • Se você quiser fazer backup de um volume criptografado por CMEK, precisará conceder acesso à chave desse disco, mesmo que não ative a criptografia de CMEK em seu BackupPlan.

  • As chaves CMEK precisam estar na mesma região que BackupPlan para garantir que uma falha temporária regional não remova o acesso à chave enquanto os backups ainda estão acessíveis. No entanto, essa restrição não pode ser aplicada a chaves compartilhadas com volumes criptografados. Quando volumes criptografados estão envolvidos, é possível que uma restauração falhe mesmo quando um backup estiver disponível, porque a chave de criptografia do disco pode não ser armazenada na mesma região do backup.