Nesta página, descrevemos como o suporte a chaves de criptografia gerenciadas pelo cliente (CMEK) funciona no Backup para GKE.
Informações gerais
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.
Conceder acesso no nível do projeto
É possível conceder acesso a chaves no nível do projeto, o que concede acesso a todas as chaves nesse projeto.
Use as instruções a seguir para conceder acesso no nível do projeto.
Console
No console do Google Cloud, abra a página IAM.
Clique em Conceder acesso.
No campo Novos membros, insira o endereço de e-mail da conta de serviço.
Na lista Selecionar uma função, selecione Criptografador/Descriptografador de CryptoKey do Cloud KMS.
Clique em Salvar.
gcloud
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
Substitua:
PROJECT_ID
: o ID do projeto ao qual você quer conceder acesso.PROJECT_NUMBER
: o número do projeto ao qual você quer conceder acesso.
Terraform
Conceder acesso no nível do projeto.
resource "google_project_iam_member" "example_iam_member" { project = "PROJECT_ID" role = "roles/cloudkms.cryptoKeyEncrypterDecrypter" member = "serviceAccount:service-PROJECT_NUMBER@gcp-sa-gkebackup.iam.gserviceaccount.com" }
Substitua:
PROJECT_ID
: o ID do projeto ao qual você quer conceder acesso.PROJECT_NUMBER
: o número do projeto ao qual você quer conceder acesso.
Conceder acesso no nível da chave
Use as instruções a seguir para conceder acesso no nível da chave individual.
Console
No console do Google Cloud, acesse a página Gerenciamento de chaves.
Clique no nome do keyring;
Clique no nome da chave.
Clique na guia Permissões.
Clique em Conceder acesso.
No campo Novos membros, insira o endereço de e-mail da conta de serviço.
Na lista Selecionar uma função, selecione Criptografador/Descriptografador de CryptoKey do Cloud KMS.
Clique em Salvar.
gcloud
Conceder acesso no nível da chave individual.
gcloud kms keys add-iam-policy-binding KEY_NAME \ --keyring KEY_RING \ --location LOCATION \ --member "serviceAccount:service-PROJECT_NUMBER@gcp-sa-gkebackup.iam.gserviceaccount.com" \ --role roles/cloudkms.cryptoKeyEncrypterDecrypter
Substitua:
KEY_NAME
: o nome da chave;KEY_RING
: o nome do keyring que contém a chave.LOCATION
: o local do Cloud KMS do keyring.PROJECT_NUMBER
: o número do projeto ao qual você quer conceder acesso.
Terraform
Conceder acesso no nível da chave individual.
resource "google_kms_crypto_key_iam_member" "crypto_key_iam_member" { crypto_key_id = "projects/PROJECT_ID/locations/LOCATION/keyRings/KEY_RING/cryptoKeys/KEY_NAME" role = "roles/cloudkms.cryptoKeyEncrypterDecrypter" member = "serviceAccount:service-PROJECT_NUMBER@gcp-sa-gkebackup.iam.gserviceaccount.com" }
Substitua:
PROJECT_ID
: o ID do projeto ao qual você quer conceder acesso.LOCATION
: o local do Cloud KMS do keyring.KEY_RING
: o nome do keyring que contém a chave.KEY_NAME
: o nome da chave;PROJECT_NUMBER
: o número do projeto ao qual você quer conceder acesso.
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.