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

.

Nesta página, mostramos 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 conhecer conceitos como etcd, a arquitetura de cluster do GKE e o 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 por você. Para mais detalhes, consulte Sobre a autoridade do plano de controle do GKE.

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

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

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 backup operacional interno do etcd usando chaves de criptografia gerenciadas pelo Trusted Cloud. Trusted Cloud by S3NS Para mais detalhes sobre essa criptografia padrão, consulte Criptografia padrão em repouso. Opcionalmente, use suas próprias chaves de criptografia gerenciadas pelo Cloud KMS para criptografar esses recursos. Para saber mais, consulte Disco de inicialização do plano de controle e criptografia 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, independente da finalidade de cada uma. Se você tiver um keyring que usou para uma finalidade diferente, como configurar suas próprias autoridades certificadoras, use esse keyring para este guia.
  • Crie as chaves no mesmo local Trusted Cloud do cluster para ter uma latência melhor.
  • Na maioria dos casos de uso, é possível usar o nível de proteção software da chave do Cloud KMS. Também é possível usar chaves de hardware com o Cloud HSM.
  • É preciso 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 um cluster é criado:

Só é possível ativar esses recursos ao criar um cluster do GKE. Não é possível atualizar clusters atuais para usar esses recursos. Para usar os dois recursos no mesmo cluster, siga todos os procedimentos de configuração de chave e CA nos dois guias e 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 seguintes tarefas:

  • Ativar a API Google Kubernetes Engine.
    • Ativar a API Google Kubernetes Engine
  • Se você quiser usar a CLI do Google Cloud para essa tarefa, instale e, em seguida, inicialize a CLI gcloud. Se você instalou a gcloud CLI anteriormente, instale a versão mais recente executando gcloud components update.
  • Verifique se o projeto de chave tem um keyring do Cloud KMS para seu cluster. Você pode usar qualquer keyring no local do cluster. Para criar um novo keyring, consulte Criar um keyring.

  • Enable the Cloud Key Management Service API.

    Enable the API

Identificar projetos

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

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

É possível usar o mesmo projeto para 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 por meio de papéis personalizados ou de outros papéis predefinidos.

Requisitos

Seu cluster precisa executar o GKE versão 1.31.1-gke.1846000 ou posterior.

Limitações

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

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

    Para clusters zonais no modo Standard, 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 do 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 nem interagir com os backups operacionais internos do etcd Trusted Cloud , que são apenas para recuperação de desastres.

  • Os keyrings multirregionais não são compatíveis. Você precisa usar um keyring regional.

  • As regiões e zonas em que você pode usar a autoridade do plano de controle do GKE dependem de você querer usar recursos específicos, da seguinte forma:

    • Para criptografar os discos de inicialização do plano de controle com uma chave de criptografia gerenciada pelo cliente, o cluster precisa estar em uma das seguintes regiões:
      • asia-east1
      • asia-northeast1
      • asia-southeast1
      • europe-west1
      • europe-west4
      • us-central1
      • us-east1
      • us-east4
      • us-east5
      • us-south1
      • us-west1
      • us-west3
      • us-west4
    • Para usar os nós confidenciais do GKE com a autoridade do plano de controle do GKE, o cluster precisa estar em uma região que ofereça suporte ao modo confidencial para o Hyperdisk equilibrado.

    Se você não usa esses recursos, pode usar a autoridade do plano de controle do GKE em qualquer localização Trusted Cloud .

Criar chaves

Nesta seção, você vai criar uma chave de criptografia para os discos de inicialização e do etcd no plano de controle e outra chave de criptografia separada para o backup operacional interno do etcd Trusted Cloud. É 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 do plano de controle e os discos etcd:

    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 do plano de controle e do etcd.
    • KEYRING_NAME: o nome do keyring que vai armazenar as chaves de criptografia do cluster.
    • LOCATION: o Trusted Cloud local do keyring. Precisa ser igual ao local do cluster. Para uma lista de regiões, filtre "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 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 criou para o agente de serviço do GKE no projeto do cluster. O agente de serviço do GKE exige essas funções para usar as chaves e criptografar os recursos correspondentes do plano de controle.

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

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

    Substitua CLUSTER_PROJECT_ID pelo ID do projeto do cluster do GKE.

    O resultado será assim:

    1234567890

  2. Conceda o papel Criptografador/Descriptografador de CryptoKey do Cloud KMS (roles/cloudkms.cryptoKeyEncrypterDecrypter) na chave de criptografia para discos de inicialização e etcd ao agente de serviço do GKE no projeto do 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.s3ns-system.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 Trusted 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 numérico do projeto do cluster, que você encontrou na etapa anterior.
    • KEY_PROJECT_ID: o ID do projeto do projeto de chave.

  3. Conceda o papel Criptografador/Descriptografador de 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 do 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.s3ns-system.iam.gserviceaccount.com" \
    --role=roles/cloudkms.cryptoKeyEncrypterDecrypterViaDelegation \
    --project=KEY_PROJECT_ID

  4. Conceda o papel Usuário da chave do Cloud KMS nas chaves de criptografia para discos de inicialização e discos etcd ao agente de serviço do GKE no projeto do 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.s3ns-system.iam.gserviceaccount.com" \
    --role=roles/container.cloudKmsKeyUser \
    --project=KEY_PROJECT_ID

  5. Conceda o papel de criptografador de CryptoKey do Cloud KMS (roles/cloudkms.cryptoKeyEncrypter) na chave de criptografia de backup interna do etcd ao agente de serviço do GKE no projeto do 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.s3ns-system.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.

    Conceder a função roles/cloudkms.cryptoKeyEncrypter impede que o GKE faça restaurações de banco de dados em seu nome e aumenta significativamente o tempo necessário para restaurar a funcionalidade quando um problema de banco de dados ocorre. Para permitir que o GKE faça restaurações para você, conceda o papel roles/cloudkms.cryptoKeyEncrypterDecrypter em vez disso.

Usar chaves de criptografia em um cluster

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

  1. Identifique o caminho da 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 do plano de controle e discos etcd.
    • KEYRING_NAME: o nome do keyring que contém a chave.
    • LOCATION: o Trusted Cloud local da chave.
    • KEY_PROJECT_ID: o ID do projeto 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 sua 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 Standard. Para criar clusters no modo Autopilot, use as mesmas flags com o comando gcloud container clusters create-auto.

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

    1. Siga todas as etapas de configuração de chaves e CA 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 CAs usando as instruções em Configurar CAs 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 do cluster.
      • PATH_TO_DISK_KEY: o caminho para a chave de criptografia de disco das etapas anteriores nesta página.
      • PATH_TO_ETCD_BACKUP_KEY: o caminho para a chave de criptografia de backup interno do etcd das etapas anteriores nesta página.
      • 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 AC 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 do 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.

Você também pode especificar todas essas flags ao criar um cluster no modo padrão.

Verificar o status da chave de criptografia

Nesta seção, mostramos como verificar a chave de criptografia usada durante a criação do cluster. É possível fazer 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 console Trusted Cloud , acesse a página Análise de registros.

    Acessar o Explorador de registros

  2. Para receber o registro de criação do cluster, especifique 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)"

A seguir