Sobre a criptografia CMEK de backup para o GKE

Autopilot Padrão

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.

Cuidado: se o escopo do backup incluir um volume criptografado por CMEK, o VolumeBackup associado a esse volume vai falhar. O campo stateMessage do recurso VolumeBackup conterá uma mensagem de erro que identifica a conta de serviço (cmek_service_agent) que precisa ter acesso a orig_disk_key. É possível ver os recursos VolumeBackup usando o comando gcloud beta container backup-restore volume-backups list, transmitindo --format=yaml para ver todos os campos.
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.