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 oBackupPlan
. 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óprioBackupPlan
. 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 oBackupPlan
.new_disk_key
: esta é a chave CMEK que você quer usar para criptografar volumes restaurados do backup. Isso é referenciado peloStorageClass
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 aobplan_key
. Essa conta de serviço terá o formato:PROJECT_ID.svc.id.goog[gkebackup/agent]
, em quePROJECT_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 aobplan_key
. Essa conta de serviço terá o formato:service-PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com
, em quePROJECT_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 abplan_key
. Essa conta de serviço vai ter o formato:service-PROJECT_NUMBER@gcp-sa-gkebackup.iam.gserviceaccount.com
, em quePROJECT_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 aorig_disk_key
. Essa conta de serviço vai ter o formato:service-TENANT_PROJECT_NUMBER@compute-system.iam.gserviceaccount.com
, em queTENANT_PROJECT_NUMBER
é o número do projeto de locatário atribuído ao seuBackupPlan
.compute_service_agent
: essa conta de serviço é usada ao criar novos volumes criptografados de um cluster e precisa receber acesso aonew_disk_key
. Essa conta de serviço terá o formato:service-PROJECT_NUMBER@compute-system.iam.gserviceaccount.com
, em quePROJECT_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 papelroles/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.