Criptografar discos de inicialização do etcd e do plano de controle

Este documento mostra como criptografar dados armazenados no plano de controle do Google Kubernetes Engine (GKE) usando chaves gerenciadas no Cloud Key Management Service (Cloud KMS). Você já precisa estar familiarizado com conceitos como etcd, a arquitetura de cluster do GKE, e Cloud KMS.

Esta página descreve uma parte de um conjunto de recursos opcionais do plano de controle no GKE que permite realizar tarefas como verificar a postura de segurança do plano de controle ou configurar a criptografia e a assinatura de credenciais no plano de controle usando chaves gerenciadas. Para mais detalhes, consulte Sobre a autoridade do plano de controle do GKE.

Por padrão, Google Cloud aplica várias medidas de segurança ao plano de controle gerenciado. Esta página descreve recursos opcionais que oferecem mais visibilidade ou controle sobre o plano de controle do GKE.

Sobre o disco de inicialização do plano de controle e a criptografia do etcd

Por padrão, o GKE criptografa o disco de inicialização de um nó do plano de controle, o disco que armazena dados no etcd e o Google Cloud backup operacional interno do etcd usando chaves de criptografia que Google Cloud gerencia. Para mais detalhes sobre essa criptografia padrão, consulte Criptografia padrão em repouso. Você pode opcionalmente usar suas próprias chaves de criptografia gerenciadas usando o Cloud KMS para criptografar esses recursos. Para saber mais, consulte Disco de inicialização do plano de controle e criptografia do etcd.

Você cria chaves no Cloud KMS que o GKE usa para criptografar os recursos do plano de controle. Considere o seguinte ao criar esses recursos:

  • É possível usar um keyring para todas as chaves em um cluster, independentemente da finalidade de cada chave. Se você tiver um keyring que usou para uma finalidade diferente, como configurar suas próprias autoridades de certificação, poderá usar esse keyring para este guia.
  • Crie as chaves no mesmo Google Cloud local do seu cluster para melhorar a latência.
  • Para a maioria dos casos de uso, é possível usar o nível de proteção de chave do Cloud KMS software. Também é possível usar chaves de hardware com o Cloud HSM.
  • É necessário especificar a flag --purpose com o valor encryption, porque essas chaves são usadas para criptografia simétrica.
  • Não modifique a duração padrão para destruição de chaves.

Uso com outros recursos de autoridade do plano de controle do GKE

A autoridade do plano de controle do GKE oferece os seguintes recursos relacionados a chaves autogerenciadas que precisam ser ativadas ao mesmo tempo em que você cria um cluster:

Só é possível ativar esses recursos ao criar um novo cluster do GKE. Não é possível atualizar clusters atuais para usar esses recursos. Para usar ambos esses recursos no mesmo cluster, siga todos os procedimentos de configuração de chave e AC em ambos os guias e, em seguida, execute o comando de criação de cluster que ativa os dois conjuntos de recursos, conforme descrito na seção Criar um cluster.

Antes de começar

Antes de começar, verifique se você realizou as tarefas a seguir:

  • Ative a API Google Kubernetes Engine.
    • Ativar a API Google Kubernetes Engine
  • Se você quiser usar a Google Cloud CLI para essa tarefa, instale e, em seguida, inicialize a CLI gcloud. Se você instalou a CLI gcloud anteriormente, instale a versão mais recente executando o comando gcloud components update. Talvez as versões anteriores da CLI gcloud não sejam compatíveis com a execução dos comandos neste documento.
  • Verifique se o projeto de chave tem um keyring do Cloud KMS para o cluster. É possível usar qualquer keyring atual no local do cluster. Para criar um keyring, consulte Criar um keyring.

  • Ative a API Cloud Key Management Service.

    Funções necessárias para ativar APIs

    Para ativar as APIs, é necessário ter o papel do IAM de administrador de uso do serviço (roles/serviceusage.serviceUsageAdmin), que contém a permissão serviceusage.services.enable. Saiba como conceder papéis.

    Ativar a API

Identificar projetos

Recomendamos que você use projetos separados da seguinte maneira: Google Cloud

  • Projeto de chave: contém todas as chaves.
  • Projeto de cluster: contém seus clusters do GKE.

Você pode usar o mesmo projeto para suas chaves e clusters do GKE, mas recomendamos que você use projetos separados para que as equipes que gerenciam suas chaves e operações criptográficas sejam separadas das equipes que gerenciam seus clusters.

Papéis e permissões necessárias

Para receber as permissões necessárias para executar suas próprias chaves de criptografia, peça ao administrador para conceder a você os seguintes papéis do IAM:

Para mais informações sobre a concessão de papéis, consulte Gerenciar o acesso a projetos, pastas e organizações.

Também é possível conseguir as permissões necessárias com papéis personalizados ou outros papéis predefinidos.

Requisitos

A criptografia de disco do plano de controle com suas próprias chaves tem os seguintes requisitos:

  • O cluster precisa executar a versão 1.31.1-gke.1846000 ou mais recente do GKE.

  • É necessário criar o cluster em uma das seguintes regiões:

    • asia-east1
    • asia-northeast1
    • asia-southeast1
    • europe-west1
    • europe-west4
    • us-central1
    • us-central2
    • us-east1
    • us-east4
    • us-east5
    • us-south1
    • us-west1
    • us-west3
    • us-west4

Limitações

  • Só é possível configurar chaves de criptografia de disco de inicialização e etcd durante a criação do cluster.

  • Para clusters regionais do modo padrão e para clusters do Autopilot, a região em que você cria um cluster precisa ter capacidade para o modo confidencial para o Hyperdisk Balanced em pelo menos três zonas nessa região.

    Para clusters zonais do modo padrão, a zona do cluster precisa ter capacidade do Hyperdisk Balanced. Para receber ajuda com a capacidade, entre em contato com o Cloud Customer Care.

  • O GKE só é compatível com chaves do Cloud KMS. Não é possível usar outro provedor KMS Kubernetes ou outro provedor de criptografia.

  • As chaves do Cloud External Key Manager (Cloud EKM) não são compatíveis.

  • Não é possível acessar ou interagir com os Google Cloud internos backups operacionais do etcd, que são apenas para recuperação de desastres.

  • Keyrings multirregionais não são compatíveis. É necessário usar um keyring regional.

Criar chaves

Nesta seção, você cria uma chave de criptografia para os discos de inicialização e os discos etcd no plano de controle e uma chave de criptografia separada para o Google Cloud backup operacional interno do etcd. É possível usar um keyring para armazenar todas essas chaves e outras chaves do cluster.

  1. Crie a chave de criptografia para os discos de inicialização e os discos etcd do plano de controle:

    gcloud kms keys create KCP_DISK_KEY_NAME \
    --keyring=KEYRING_NAME \
    --location=LOCATION \
    --purpose="encryption" \
    --protection-level=PROTECTION_LEVEL \
    --project=KEY_PROJECT_ID

    Substitua:

    • KCP_DISK_KEY_NAME: o nome da chave de criptografia para os discos de inicialização e os discos etcd do plano de controle.
    • KEYRING_NAME: o nome do keyring para armazenar as chaves de criptografia do cluster.
    • LOCATION: o Google Cloud local para o keyring. Precisa ser igual ao local do cluster. Para uma lista de regiões, filtre por "Região" na tabela de locais do Cloud KMS.
    • PROTECTION_LEVEL: o nível de proteção da chave, como software ou hsm.
    • KEY_PROJECT_ID: o ID do projeto de chave.

  2. Crie a chave de criptografia de backup interno do etcd:

    gcloud kms keys create ETCD_BACKUP_KEY_NAME \
    --keyring=KEYRING_NAME \
    --location=LOCATION \
    --purpose="encryption" \
    --protection-level=PROTECTION_LEVEL \
    --project=KEY_PROJECT_ID

    Substitua ETCD_BACKUP_KEY_NAME por um nome para a chave de criptografia de backup interno do etcd.

Conceder papéis do IAM ao agente de serviço do GKE

Nesta seção, você concede papéis do IAM nas chaves que você criou ao agente de serviço do GKE no projeto de cluster. O agente de serviço do GKE exige esses papéis para usar essas chaves para criptografar os recursos correspondentes do plano de controle.

  1. Encontre o número do projeto de cluster:

    gcloud projects describe CLUSTER_PROJECT_ID \
    --format='value(projectNumber)'

    Substitua CLUSTER_PROJECT_ID pelo ID do projeto de cluster do GKE.

    O resultado será assim:

    1234567890

  2. Conceda o Criptografador/Descriptografador do CryptoKey do Cloud KMS (roles/cloudkms.cryptoKeyEncrypterDecrypter) papel na chave de criptografia para discos de inicialização e discos etcd ao agente de serviço do GKE no projeto de cluster:

    gcloud kms keys add-iam-policy-binding KCP_DISK_KEY_NAME \
    --location=LOCATION \
    --keyring=KEYRING_NAME \
    --member="serviceAccount:service-CLUSTER_PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com" \
    --role=roles/cloudkms.cryptoKeyEncrypterDecrypter \
    --project=KEY_PROJECT_ID

    Substitua:

    • KCP_DISK_KEY_NAME: o nome da chave de criptografia de disco.
    • LOCATION: o Google Cloud local da chave.
    • KEYRING_NAME: o nome do keyring que contém a chave de criptografia.
    • CLUSTER_PROJECT_NUMBER: o número do projeto de cluster, que você encontrou na etapa anterior.
    • KEY_PROJECT_ID: o ID do projeto de chave.

  3. Conceda o papel Criptografador/Descriptografador do CryptoKey do Cloud KMS por delegação (roles/cloudkms.cryptoKeyEncrypterDecrypterViaDelegation) na chave de criptografia para discos de inicialização e discos etcd ao agente de serviço do GKE no projeto de cluster:

    gcloud kms keys add-iam-policy-binding KCP_DISK_KEY_NAME \
    --location=LOCATION \
    --keyring=KEYRING_NAME \
    --member="serviceAccount:service-CLUSTER_PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com" \
    --role=roles/cloudkms.cryptoKeyEncrypterDecrypterViaDelegation \
    --project=KEY_PROJECT_ID

  4. Conceda o papel Usuário de chaves do Cloud KMS nas chaves de criptografia para discos de inicialização e discos etcd ao agente de serviço do GKE no projeto de cluster para a rotação de chaves:

    gcloud kms keys add-iam-policy-binding KCP_DISK_KEY_NAME \
    --location=LOCATION \
    --keyring=KEYRING_NAME \
    --member="serviceAccount:service-CLUSTER_PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com" \
    --role=roles/container.cloudKmsKeyUser \
    --project=KEY_PROJECT_ID

  5. Conceda o papel Criptografador do CryptoKey do Cloud KMS (roles/cloudkms.cryptoKeyEncrypter) na chave de criptografia de backup interno do etcd ao agente de serviço do GKE no projeto de cluster:

    gcloud kms keys add-iam-policy-binding ETCD_BACKUP_KEY_NAME \
    --location=LOCATION \
    --keyring=KEYRING_NAME \
    --member="serviceAccount:service-CLUSTER_PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com" \
    --role=roles/cloudkms.cryptoKeyEncrypter \
    --project=KEY_PROJECT_ID

    Substitua ETCD_BACKUP_KEY_NAME pelo nome da chave de criptografia de backup operacional do etcd.

    A concessão do papel roles/cloudkms.cryptoKeyEncrypter impede que o GKE realize restaurações de banco de dados em seu nome e aumenta significativamente o tempo para restaurar a funcionalidade quando ocorre um problema de banco de dados. Para permitir que o GKE realize restaurações para você, conceda o papel roles/cloudkms.cryptoKeyEncrypterDecrypter.

Usar chaves de criptografia em um cluster

Esta seção mostra como identificar os caminhos para as chaves de criptografia.

  1. Identifique o caminho para a chave de criptografia de disco:

    gcloud kms keys describe KCP_DISK_KEY_NAME \
    --keyring=KEYRING_NAME \
    --location=LOCATION \
    --project=KEY_PROJECT_ID \
    --format="value(name)"

    Substitua:

    • KCP_DISK_KEY_NAME: o nome da chave de criptografia para discos de inicialização e discos etcd do plano de controle.
    • KEYRING_NAME: o nome do keyring que contém a chave.
    • LOCATION: o Google Cloud local da chave.
    • KEY_PROJECT_ID: o ID do projeto de chave.

    O resultado será assim:

    projects/KEY_PROJECT_ID/locations/LOCATION/keyRings/KEYRING_NAME/cryptoKeys/disk-encryption-key

  2. Identifique o caminho para a chave de criptografia de backup interno do etcd:

    gcloud kms keys describe ETCD_BACKUP_KEY_NAME \
    --keyring=KEYRING_NAME \
    --location=LOCATION \
    --project=KEY_PROJECT_ID \
    --format="value(name)"

    Substitua ETCD_BACKUP_KEY_NAME pelo nome da chave de criptografia de backup operacional do etcd.

    O resultado será assim:

    projects/KEY_PROJECT_ID/locations/LOCATION/keyRings/KEYRING_NAME/cryptoKeys/etcd-backup-encryption-key

Criar um cluster

Nesta seção, você cria um cluster com diferentes opções especificadas, dependendo dos recursos de autoridade do plano de controle do GKE que você quer configurar. Só é possível configurar esses recursos em um cluster durante a criação dele. Os comandos a seguir criam clusters do modo padrão. Para criar clusters do modo Autopilot, use as mesmas flags com o gcloud container clusters create-auto comando.

  • Para criar um cluster que configura a criptografia de disco e executa suas próprias ACs e chaves de assinatura de conta de serviço, faça o seguinte:

    1. Siga todas as etapas de configuração de chave e AC em Executar suas próprias autoridades de certificação e chaves.
    2. Encontre os caminhos para cada uma das chaves de conta de serviço e ACs usando as instruções em Configurar ACs e chaves em um novo cluster.

    3. Crie um cluster:

      gcloud container clusters create CLUSTER_NAME \
    --location=LOCATION \
    --project=CLUSTER_PROJECT_ID \
    --control-plane-disk-encryption-key=PATH_TO_DISK_KEY \
    --gkeops-etcd-backup-encryption-key=PATH_TO_ETCD_BACKUP_KEY \
    --service-account-signing-keys=PATH_TO_SIGNING_KEY_VERSION \
    --service-account-verification-keys=PATH_TO_VERIFICATION_KEY_VERSION \
    --cluster-ca=PATH_TO_CLUSTER_CA \
    --etcd-peer-ca=PATH_TO_ETCD_PEER_CA \
    --etcd-api-ca=PATH_TO_ETCD_API_CA \
    --aggregation-ca=PATH_TO_AGGREGATION_CA

      Substitua:

      • CLUSTER_NAME: o nome do novo cluster.
      • LOCATION: o local do novo cluster.
      • CLUSTER_PROJECT_ID: o ID do projeto do projeto de cluster.
      • PATH_TO_DISK_KEY: o caminho para a chave de criptografia de disco das etapas anteriores neste documento.
      • PATH_TO_ETCD_BACKUP_KEY: o caminho para a chave de criptografia de backup interno do etcd das etapas anteriores neste documento.
      • PATH_TO_SIGNING_KEY_VERSION: o caminho para a versão da chave de assinatura da conta de serviço do Kubernetes no Cloud KMS.
      • PATH_TO_VERIFICATION_KEY_VERSION: o caminho para a versão da chave de verificação da conta de serviço do Kubernetes no Cloud KMS.
      • PATH_TO_CLUSTER_CA: o caminho para o pool de ACs do cluster.
      • PATH_TO_ETCD_PEER_CA: o caminho para o pool de ACs de pares do etcd.
      • PATH_TO_ETCD_API_CA: o caminho para o pool de ACs da API etcd.
      • PATH_TO_AGGREGATION_CA: o caminho para o pool de ACs de agregação.

  • Para criar um cluster que só configura a criptografia de disco usando as chaves criadas neste guia, execute o seguinte comando:

    gcloud container clusters create CLUSTER_NAME \
    --location=LOCATION \
    --project=CLUSTER_PROJECT_ID \
    --control-plane-disk-encryption-key=PATH_TO_DISK_KEY \
    --gkeops-etcd-backup-encryption-key=PATH_TO_ETCD_BACKUP_KEY

    Substitua:

    • CLUSTER_NAME: o nome do novo cluster.
    • LOCATION: o local do novo cluster.
    • CLUSTER_PROJECT_ID: o ID do projeto do projeto de cluster.
    • PATH_TO_DISK_KEY: o caminho para a chave de criptografia de disco das etapas anteriores.
    • PATH_TO_ETCD_BACKUP_KEY: o caminho para a chave de criptografia de backup interno do etcd das etapas anteriores.

Também é possível especificar todas essas flags ao criar um novo cluster do modo padrão.

Verificar o status da chave de criptografia

Esta seção mostra como verificar a chave de criptografia usada durante a criação do cluster. É possível realizar essa verificação usando o Cloud Logging ou a Google Cloud CLI.

Usar o Logging para verificar chaves

Para verificar as chaves usando o Logging, faça o seguinte:

  1. No Google Cloud console do, acesse a página Análise de registros:

    Acessar o Explorador de registros

  2. Receba o registro de criação do cluster especificando a seguinte consulta:

    resource.type="gke_cluster"
resource.labels.cluster_name="CLUSTER_NAME"
resource.labels.location="CLUSTER_LOCATION"
protoPayload.serviceName="container.googleapis.com"
protoPayload.methodName=~"google.container.v(1|1alpha1|1beta1).ClusterManager.CreateCluster"
protoPayload.request.cluster.userManagedKeysConfig:*

  3. Clique em Executar consulta.

Na saída, verifique se os parâmetros de criação do cluster incluíram um caminho de chave que corresponde à chave configurada no Cloud KMS, como no exemplo a seguir:

# lines omitted for clarity
userManagedKeysConfig: {
  controlPlaneDiskEncryptionKey: "projects/KEY_PROJECT_ID/locations/LOCATION/keyRings/KEY_RING_NAME/cryptoKeys/KCP_DISK_KEY_NAME"
  gkeopsEtcdBackupEncryptionKey: "projects/KEY_PROJECT_ID/locations/LOCATION/keyRings/KEY_RING_NAME/cryptoKeys/ETCD_BACKUP_KEY_NAME"
}

Usar a CLI gcloud para verificar chaves

Para usar a CLI gcloud para verificar a chave de criptografia, faça o seguinte:

  1. Para a chave de criptografia de disco, execute o seguinte comando:

    gcloud container clusters describe CLUSTER_NAME \
    --location=LOCATION \
    --format="value(userManagedKeysConfig.controlPlaneDiskEncryptionKey)"

  2. Para a chave de criptografia de backup interno do etcd, execute o seguinte comando:

    gcloud container clusters describe CLUSTER_NAME \
    --location=LOCATION \
    --format="value(userManagedKeysConfig.gkeopsEtcdBackupEncryptionKey)"

Rotacionar chaves de criptografia de disco do etcd e do plano de controle

As chaves de criptografia criadas não expiram. Para melhorar sua postura de segurança, rotacione essas chaves regularmente e criptografe novamente seus recursos com novas versões de chave. Para mais informações, consulte Rotacionar chaves de criptografia de disco de inicialização do etcd e do plano de controle.

A seguir