Sobre a criptografia CMEK de backup para o GKE

Por padrão, o Backup para GKE criptografa o conteúdo do cliente em repouso. O Backup para GKE executa a criptografia, e você não precisa fazer nada. Essa opção é chamada de criptografia padrão do Google.

Se você quiser controlar suas chaves de criptografia, use chaves de criptografia gerenciadas pelo cliente (CMEKs) no Cloud KMS com serviços integrados a CMEKs, incluindo o Backup para GKE. Ao usar chaves do Cloud KMS, é possível controlar o nível de proteção, o local, a programação de rotação, as permissões de uso e acesso e os limites criptográficos. Com o Cloud KMS, também é possível visualizar registros de auditoria e controlar ciclos de vida de chaves. Em vez de o Google ser proprietário e gerente de chaves de criptografia de chaves (KEKs) simétricas que protegem seus dados, você controla e gerencia essas chaves no Cloud KMS.

Depois de configurar os recursos com CMEKs, a experiência de acesso aos recursos do Backup para GKE é semelhante à criptografia padrão do Google. Para saber mais sobre suas opções de criptografia, consulte Chaves de criptografia gerenciadas pelo cliente (CMEK).

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á quatro contas de serviço diferentes que podem exigir acesso a chaves CMEK:

  • agent_robot: essa conta de serviço precisa 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 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 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 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

Se você estiver realizando uma operação de backup ou restauração entre projetos, três nomes de projetos precisam ser listados:

  • cluster_project: o projeto que contém o cluster que você quer armazenar em backup.

  • backup_project: o projeto em que você quer armazenar seus backups.

  • restore_project: o projeto que contém o cluster de destino da restauração.

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 Número do projeto Chave
cluster de backup de configuração agent_robot
  • cluster_project (durante o backup)
  • restore_project (durante a restauração)
 bplan_key
backup de volume criptografado por CMEK cmek_service_agent backup_project orig_disk_key
backup de volume criptografado pelo Google non_cmek_service_agent backup_project bplan_key
novo volume criptografado por CMEK criado durante a restauração compute_service_agent restore_project 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

  1. No console do Google Cloud , acesse a página IAM.

    Acessar o IAM

  2. Clique em Conceder acesso.

  3. No campo Novos membros, insira o endereço de e-mail da conta de serviço.

  4. Na lista Selecionar uma função, selecione Criptografador/Descriptografador de CryptoKey do Cloud KMS.

  5. Clique em Salvar.

gcloud

  1. 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

  1. 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

  1. No console do Google Cloud , acesse a página Gerenciamento de chaves.

    Acessar "Gerenciamento de chaves"

  2. Clique no nome do keyring;

  3. Clique no nome da chave.

  4. Clique na guia Permissões.

  5. Clique em Conceder acesso.

  6. No campo Novos membros, insira o endereço de e-mail da conta de serviço.

  7. Na lista Selecionar uma função, selecione Criptografador/Descriptografador de CryptoKey do Cloud KMS.

  8. Clique em Salvar.

gcloud

  1. 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

  1. 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.

Usar e gerenciar chaves externas

Você pode usar o Cloud External Key Manager (Cloud EKM) para criar e gerenciar chaves externas. As chaves externas são ponteiros para chaves que residem fora do Google Cloud. Essas chaves ficam com um parceiro de gerenciamento de chaves externas compatível. Para mais informações, consulte Gerenciador de chaves externo do Cloud.

Depois de criar uma chave externa com o Cloud EKM, é possível aplicá-la a um novo plano de backup fornecendo o ID dessa chave ao criar um novo plano de backup. Esse procedimento é o mesmo que aplicar uma chave do Cloud KMS a um novo plano de backup.

É possível usar as justificativas de acesso às chaves (KAJ) como parte do Cloud EKM. Com as justificativas de acesso às chaves, é possível ver o motivo de cada solicitação do Cloud EKM. Além disso, com base na justificativa fornecida, é possível aprovar ou negar automaticamente uma solicitação. Para mais informações, consulte Visão geral.