Usar chaves de criptografia gerenciadas pelo cliente (CMEK)

Autopilot Standard

---

Veja nesta página como usar as chaves de criptografia gerenciadas pelo cliente (CMEKs, na sigla em inglês) no Google Kubernetes Engine (GKE). Se você precisa controlar o gerenciamento das suas chaves, use o Cloud Key Management Service e as CMEKs para proteger os discos permanentes e os discos de inicialização personalizados no cluster do GKE.

Visão geral

Por padrão, o Google Cloud criptografa conteúdo de cliente em repouso, e o GKE administra a criptografia para você automaticamente.

Se você quiser controlar e gerenciar a rotação de chaves de criptografia, use as CMEKs. Elas criptografam as chaves de criptografia dos seus dados. Para mais informações, consulte Gerenciamento de chaves.

Também é possível criptografar chaves secretas no cluster usando chaves que você gerencia. Para mais detalhes, consulte Criptografia de secrets da camada de aplicativos.

No GKE, as CMEKs podem proteger dados de dois tipos de disco de armazenamento: discos anexados e de inicialização de nós.

Discos de inicialização de nós

Os discos de inicialização de nós fazem parte dos pools de nós do cluster. É possível criar um disco de inicialização de nós criptografado por CMEKs ao criar clusters e pools de nós.

Discos anexados

Os discos anexados são PersistentVolumes usados por pods para armazenamento durável. Os discos permanentes anexados e criptografados por CMEKs estão disponíveis no GKE como um PersistentVolume provisionado dinamicamente.

Para saber mais sobre os discos de armazenamento, consulte Opções de armazenamento. Os discos do plano de controle, usados em planos de controle do GKE, não podem ser protegidos com CMEKs.

Antes de começar

1. Para fazer os exercícios neste tópico, você precisa de dois projetos do Google Cloud:

   • Projeto principal: é onde você cria uma chave de criptografia.

   • Projeto do cluster: é onde você cria um cluster que ativa as CMEKs.

   Observação: é possível usar o mesmo projeto como projeto de chave e de cluster. Mas é recomendado usar projetos separados.

2. Verifique se você ativou a API do Cloud KMS no seu projeto de chave.

   Ativar a API Cloud KMS

3. No projeto principal, o usuário que cria o keyring e a chave precisa das seguintes permissões do IAM:

   • cloudkms.keyRings.getIamPolicy
   • cloudkms.keyRings.setIamPolicy

   Essas permissões são concedidas ao papel predefinido roles/cloudkms.admin do gerenciamento de identidade e acesso. Saiba mais sobre a concessão de permissões para gerenciar chaves na documentação do Cloud KMS.

4. No projeto do cluster, verifique se você ativou a API Cloud KMS.

   Ativar a API Cloud KMS

5. Verifique se você instalou a gcloud CLI.

6. Atualize gcloud para a versão mais recente:

   gcloud components update
   

Criar uma chave do Cloud KMS

Antes de proteger o disco de inicialização do nó ou o disco anexado com uma CMEK, você precisa do keyring e da chave do Cloud KMS.

O keyring e a chave têm os seguintes requisitos:

• Sua chave precisa usar criptografia simétrica.

• Você precisa conceder permissões à conta de serviço do GKE para usar a chave.

• O keyring precisa ter um local que corresponda ao local do cluster do GKE:

  • Um cluster zonal precisa usar um keyring de um local de superconjunto. Por exemplo, um cluster na zona us-central1-a só pode usar uma chave na região us-central1.

  • Um cluster regional precisa usar um keyring do mesmo local. Por exemplo, um cluster na região asia-northeast1 precisa ser protegido por um keyring da região asia-northeast1.

  • A região global do Cloud KMS não é compatível com o GKE.

Para instruções sobre como criar um keyring e uma chave, consulte Como criar chaves simétricas.

Conceder permissão para usar a chave

É preciso atribuir o papel de criptografia/descriptografia de CryptoKey do Cloud KMS à conta de serviço do Compute Engine usada pelos nós do seu cluster. Essa ação é necessária para que os discos permanentes do GKE acessem e usem a chave de criptografia.

O nome da conta de serviço do Compute Engine tem o seguinte formato:

[e-mail]

Substitua PROJECT_NUMBER pelo número do projeto do cluster.

Observação: para discos de inicialização de nós e discos anexados protegidos por CMEKs, essa conta de serviço do Compute Engine requer permissões para criptografar usando sua chave do Cloud KMS. Isso acontecerá mesmo se você estiver utilizando uma conta de serviço personalizada nos seus nós.

Para conceder acesso à conta de serviço, use o comando gcloud ou o console do Google Cloud.

gcloud

Conceda à conta de serviço do Compute Engine o papel de criptografia/descriptografia de CryptoKey do Cloud KMS:

gcloud kms keys add-iam-policy-binding KEY_NAME \
    --location LOCATION \
    --keyring RING_NAME \
    --member serviceAccount:SERVICE_ACCOUNT \
    --role roles/cloudkms.cryptoKeyEncrypterDecrypter \
    --project KEY_PROJECT_ID

Substitua:

• KEY_NAME: o nome da chave;
• LOCATION: a região em que você criou o keyring
• RING_NAME: o nome do keyring;
• SERVICE_ACCOUNT: o nome da conta de serviço do Compute Engine.
• KEY_PROJECT_ID: o ID de projeto da chave;

Console

Conceda à conta de serviço do Compute Engine o papel de criptografia/descriptografia de CryptoKey do Cloud KMS:

1. Abra o navegador de chaves do Cloud Key Management Service no console do Google Cloud.
   Abrir o navegador de Chaves do Cloud KMS

2. Clique no nome do keyring que contém a chave que você quer.

3. Marque a caixa de seleção da chave.

   A guia Permissões no painel da janela à direita fica disponível.

4. Na caixa de diálogo Adicionar membros, especifique o endereço de e-mail da conta de serviço do Compute Engine a que você está concedendo acesso.

5. Na lista suspensa Selecionar um papel, escolha Criptografador/Descriptografador do Cloud KMS CryptoKey.

6. Clique em Salvar.

Usar discos de inicialização de nó protegidos por CMEK

Nesta seção, você cria um novo cluster ou pool de nós com um disco de inicialização protegido por CMEKs.

Não é possível ativar a criptografia gerenciada pelo cliente para discos de inicialização de nós em um cluster existente, já que não é permitido alterar o tipo de disco de inicialização de um pool de nós ou um cluster existente. No entanto, você consegue criar um novo pool de nós para o cluster com a criptografia gerenciada pelo cliente ativada e excluir o pool de nós antigo.

Também não é possível desativar a criptografia gerenciada pelo cliente para discos de inicialização de nós em um cluster ou pool de nós existente. No entanto, você consegue criar um novo pool de nós para o cluster com a criptografia gerenciada pelo cliente desativada e excluir o pool de nós antigo.

Criar um cluster com um disco de inicialização de nós protegido por CMEKs

É possível criar um cluster com um disco de inicialização de nós protegido por CMEKs usando o gcloud CLI ou o console do Google Cloud.

Para clusters padrão, somente um disco permanente padrão (pd-standard) ou um disco permanente SSD (pd-ssd) pode ser criptografado com uma chave CMEK.

gcloud

Para criar um cluster com disco de inicialização criptografado por uma chave CMEK, especifique um valor para o parâmetro --boot-disk-kms-key no seu comando de criação de cluster.

Criar um cluster padrão

Para criar um cluster padrão com disco de inicialização criptografado por uma chave CMEK, use o seguinte comando:

gcloud container clusters create CLUSTER_NAME \
    --cluster-version=latest \
    --region COMPUTE_REGION \
    --boot-disk-kms-key projects/KEY_PROJECT_ID/locations/LOCATION/keyRings/RING_NAME/cryptoKeys/KEY_NAME \
    --project CLUSTER_PROJECT_ID \
    --disk-type DISK_TYPE

Criar um cluster do Autopilot

Para criar um cluster de Autopilot com disco de inicialização criptografado por uma chave CMEK, use o seguinte comando:

gcloud container clusters create-auto CLUSTER_NAME \
    --cluster-version=latest \
    --region COMPUTE_REGION \
    --boot-disk-kms-key projects/KEY_PROJECT_ID/locations/LOCATION/keyRings/RING_NAME/cryptoKeys/KEY_NAME \
    --project CLUSTER_PROJECT_ID

Substitua:

• CLUSTER_NAME: o nome do novo cluster.
• COMPUTE_REGION: a região de computação do plano de controle do cluster.
• KEY_PROJECT_ID: o ID de projeto da chave;
• LOCATION: a localização do keyring;
• RING_NAME: o nome do keyring;
• KEY_NAME: o nome da chave;
• CLUSTER_PROJECT_ID é o ID do projeto de cluster.
• DISK_TYPE: pd-standard (padrão) ou pd-ssd.

Console

Criar um cluster padrão

Para criar um cluster padrão com disco de inicialização criptografado por uma chave CMEK, siga estas etapas:

1. Acesse a página Google Kubernetes Engine no Console do Google Cloud.

   Acessar o Google Kubernetes Engine

2. Clique em Criar.

3. Na seção Padrão, clique em Configurar.

4. Configure o cluster como quiser.

5. No painel de navegação, em Pools de nós, clique em Nós.

6. Na lista suspensa Tipo de disco de inicialização, selecione Disco permanente padrão ou Disco permanente SSD.

7. Marque a caixa de seleção Ativar a criptografia gerenciada pelo cliente para o disco de inicialização e escolha a chave de criptografia do Cloud KMS que você criou anteriormente.

8. Clique em Criar.

Criar um cluster do Autopilot

Para criar um cluster do Autopilot com disco de inicialização criptografado por uma chave CMEK, siga estas etapas:

1. Acesse a página Google Kubernetes Engine no console do Google Cloud.

   Acessar o Google Kubernetes Engine

2. Clique em Criar.

3. Na seção Autopilot, clique em Configurar.

4. Configure o cluster como quiser.

5. Expanda a seção Opções avançadas e localize as opções de Segurança.

6. Marque a caixa de seleção Ativar a criptografia gerenciada pelo cliente para o disco de inicialização e escolha a chave de criptografia do Cloud KMS que você criou anteriormente.

7. Clique em Criar.

Criar um novo pool de nós com discos de inicialização de nó protegidos por CMEKs

Observação: esta seção se aplica apenas a clusters padrão. Nós e pools de nós em clusters do Autopilot são totalmente gerenciados pelo Google.

Para criar um novo pool de nós com CMEKs ativadas em um cluster existente padrão, use a gcloud CLI ou o console do Google Cloud.

gcloud

Para criar um pool de nós com criptografia gerenciada pelo cliente para discos de inicialização de nós, especifique um valor para o parâmetro --boot-disk-kms-key no seu comando de criação.

gcloud container node-pools create NODE_POOL_NAME \
    --region COMPUTE_REGION \
    --disk-type DISK_TYPE \
    --boot-disk-kms-key projects/KEY_PROJECT_ID/locations/LOCATION/keyRings/RING_NAME/cryptoKeys/KEY_NAME \
    --project CLUSTER_PROJECT_ID \
    --cluster CLUSTER_NAME

Substitua:

• NODE_POOL_NAME: o nome escolhido para o pool de nós.
• COMPUTE_REGION: a região de computação do plano de controle do cluster.
• DISK_TYPE: pd-standard (padrão) ou pd-ssd.
• KEY_PROJECT_ID: o ID de projeto da chave;
• LOCATION: a localização do keyring;
• RING_NAME: o nome do keyring;
• KEY_NAME: o nome da chave;
• CLUSTER_PROJECT_ID: o ID de projeto do cluster.
• CLUSTER_NAME: o nome do cluster padrão, criado na etapa anterior.

Console

1. Acesse a página Google Kubernetes Engine no console do Google Cloud.

   Acessar o Google Kubernetes Engine

2. Na lista de clusters, clique no nome do cluster que você quer modificar.

3. Clique em Adicionar pool de nós.

4. No painel de navegação, clique em Nós.

5. Na seção Configuração da máquina, verifique se o Tipo de disco de inicialização é Disco permanente padrão ou Disco permanente SSD.

6. Marque a caixa de seleção Ativar a criptografia gerenciada pelo cliente para o disco de inicialização e escolha a chave de criptografia do Cloud KMS criada.

7. Clique em Criar.

Use instâncias do Filestore protegidas por CMEK ou discos permanentes

Nas informações a seguir, abordamos como criptografar instâncias recém-criadas do Filestore ou discos permanentes. É possível ativar CMEK em um cluster novo ou atual, usando uma chave nova ou atual do Cloud KMS.

Essas instruções precisam ser concluídas uma vez por cluster do GKE:

• Crie um cluster do GKE, se você ainda não tiver um.
• Implante o driver CSI do Filestore ou o driver CSI de disco permanente do Compute Engine no cluster (links em inglês).
• Crie uma versão do keyring e da chave do Cloud KMS, se você ainda não tiver uma.
• Conceda permissões de acesso de chave à conta de serviço do Filestore.
• Crie uma StorageClass que permita que os discos provisionados pelo Kubernetes sejam automaticamente criptografados com essa chave do Cloud KMS. Para detalhes sobre como fazer isso, consulte a seção a seguir.

Observação: para a criptografia CMEK de instâncias do Filestore, seu cluster precisa executar o GKE 1.21 ou superior. A criptografia CMEK de instâncias do Filestore é compatível apenas comCamadas de Enterprise e SSD de alta escala (visualização) de dados.

Cuidado: Não é possível remover a criptografia CMEK em instâncias do Filestore.

Criar uma StorageClass que faça referência à chave do Cloud KMS

1. Copie o conteúdo abaixo para um arquivo YAML chamado cmek-sc.yaml. Essa configuração permite o provisionamento dinâmico de volumes criptografados.

   Instâncias do Filestore

   apiVersion: storage.k8s.io/v1
   kind: StorageClass
   metadata:
     name: csi-filestore-cmek
   provisioner: filestore.csi.storage.gke.io
   allowVolumeExpansion: true
   parameters:
     tier: enterprise
     instance-encryption-kms-key: projects/KEY_PROJECT_ID/locations/LOCATION/keyRings/RING_NAME/cryptoKeys/KEY_NAME
   

   • O campo instance-encryption-kms-key precisa ser o identificador de recurso totalmente qualificado da chave que será usada para criptografar instâncias novas do Filestore.
   • Os valores em instance-encryption-kms-key diferenciam maiúsculas de minúsculas (por exemplo: keyRings e cryptoKeys). O provisionamento de um novo volume com valores incorretos resulta em um erro invalidResourceUsage.
   • Não é possível adicionar o parâmetro instance-encryption-kms-key a um objeto StorageClass existente. No entanto, você pode excluir o objeto StorageClass e recriá-lo com o mesmo nome, mas com um conjunto diferente de parâmetros.

   Discos permanentes

   apiVersion: storage.k8s.io/v1
   kind: StorageClass
   metadata:
     name: csi-gce-pd-cmek
   provisioner: pd.csi.storage.gke.io
   volumeBindingMode: "WaitForFirstConsumer"
   allowVolumeExpansion: true
   parameters:
     type: pd-standard
     disk-encryption-kms-key: projects/KEY_PROJECT_ID/locations/LOCATION/keyRings/RING_NAME/cryptoKeys/KEY_NAME
   

   • O campo disk-encryption-kms-key precisa ser o identificador de recurso totalmente qualificado da chave que será usada para criptografar discos novos.
   • Os valores em disk-encryption-kms-key diferenciam maiúsculas de minúsculas (por exemplo: keyRings e cryptoKeys). O provisionamento de um novo volume com valores incorretos resulta em um erro invalidResourceUsage.
   • Não é possível adicionar o parâmetro disk-encryption-kms-key a um objeto StorageClass existente. No entanto, você pode excluir o objeto StorageClass e recriá-lo com o mesmo nome, mas com um conjunto diferente de parâmetros. Confira se o provisionador da classe existente é pd.csi.storage.gke.io.

   Defina o StorageClass como padrão (em inglês).

2. Implante o StorageClass no cluster do GKE usando kubectl:

   kubectl apply -f cmek-sc.yaml
   

3. Verifique se o StorageClass usou o driver CSI do disco permanente do Filestore ou Compute Engine e se inclui o ID da chave:

   Instâncias do Filestore

   kubectl describe storageclass csi-filestore-cmek
   

   Na saída do comando, verifique o seguinte:

   • se o provisionador está definido filestore.csi.storage.gke.io.
   • O ID da chave segue a instance-encryption-kms-key.

   Name:                  csi-filestore-cmek
   IsDefaultClass:        No
   Annotations:           None
   Provisioner:           filestore.csi.storage.gke.io
   Parameters:            instance-encryption-kms-key=projects/KEY_PROJECT_ID/locations/LOCATION/keyRings/RING_NAME/cryptoKeys/KEY_NAME,type=pd-standard
   AllowVolumeExpansion:  true
   MountOptions:          none
   ReclaimPolicy:         Delete
   VolumeBindingMode:     WaitForFirstConsumer
   Events:                none
   

   Discos permanentes

   kubectl describe storageclass csi-gce-pd-cmek
   

   Na saída do comando, verifique o seguinte:

   • O provisionador está definido como pd.csi.storage.gke.io.
   • O ID da chave segue a disk-encryption-kms-key.

   Name:                  csi-gce-pd-cmek
   IsDefaultClass:        No
   Annotations:           None
   Provisioner:           pd.csi.storage.gke.io
   Parameters:            disk-encryption-kms-key=projects/KEY_PROJECT_ID/locations/LOCATION/keyRings/RING_NAME/cryptoKeys/KEY_NAME,type=pd-standard
   AllowVolumeExpansion:  unset
   MountOptions:          none
   ReclaimPolicy:         Delete
   VolumeBindingMode:     WaitForFirstConsumer
   Events:                none
   

Criar um volume de armazenamento criptografado no GKE

Nesta seção, você provisiona dinamicamente volumes de armazenamento do Kubernetes criptografados com o novo StorageClass e a chave do Cloud KMS.

1. Copie o conteúdo a seguir para um novo arquivo chamado pvc.yaml e verifique se o valor de storageClassName corresponde ao nome do objeto StorageClass:

   Instâncias do Filestore

   kind: PersistentVolumeClaim
   apiVersion: v1
   metadata:
     name: podpvc
   spec:
     accessModes:
       - ReadWriteMany
     storageClassName: csi-filestore-cmek
     resources:
       requests:
         storage: 1Ti
   

   Discos permanentes

   kind: PersistentVolumeClaim
   apiVersion: v1
   metadata:
     name: podpvc
   spec:
     accessModes:
       - ReadWriteOnce
     storageClassName: csi-gce-pd-cmek
     resources:
       requests:
         storage: 6Gi
   

   Observação: se você marcou o novo StorageClass como padrão, então é possível omitir o campo storageClassName.

2. Aplique o PersistentVolumeClaim (PVC) no cluster do GKE:

   kubectl apply -f pvc.yaml
   

3. Se StorageClass tiver o campo volumeBindingMode definido como WaitForFirstConsumer, será preciso criar um pod para usar o PVC antes de poder verificá-lo. Copie o conteúdo a seguir para um novo arquivo chamado pod.yaml e verifique se o valor de claimName corresponde ao nome do objeto PersistentVolumeClaim:

   apiVersion: v1
   kind: Pod
   metadata:
     name: web-server
   spec:
     containers:
      - name: web-server
        image: nginx
        volumeMounts:
          - mountPath: /var/lib/www/html
            name: mypvc
     volumes:
      - name: mypvc
        persistentVolumeClaim:
          claimName: podpvc
          readOnly: false
   

4. Aplique o pod no cluster do GKE:

   kubectl apply -f pod.yaml
   

5. Receba o status de PersistentVolumeClaim do cluster e verifique se o PVC foi criado e vinculado a um PersistentVolume provisionado recentemente.

   Instâncias do Filestore

   kubectl get pvc
   

   A saída será assim:

   NAME      STATUS    VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS     AGE
   podpvc    Bound     pvc-e36abf50-84f3-11e8-8538-42010a800002   1Ti        RWO            csi-filestore-cmek  9s
   

   Observação: o provisionamento de PVCs usando o nível empresarial pode levar de 20 a 30 minutos para ser concluído.

   Discos permanentes

   kubectl get pvc
   

   A saída será assim:

   NAME      STATUS    VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS     AGE
   podpvc    Bound     pvc-e36abf50-84f3-11e8-8538-42010a800002   6Gi       RWO            csi-gce-pd-cmek  9s
   

Agora é possível usar o disco permanente protegido por CMEK com o cluster do GKE.

Remover proteção CMEK

Para remover a proteção CMEK de um disco permanente, siga as instruções na documentação do Compute Engine.

A criptografia CMEK não pode ser removida das instâncias do Filestore.

Políticas da organização do GKE e da CMEK

Visualização

Esse recurso está sujeito aos "Termos de ofertas pré-GA" na seção "Termos de Serviço gerais" dos Termos específicos de serviço. Os recursos pré-GA estão disponíveis "no estado em que se encontram" e podem ter suporte limitado. Para mais informações, consulte as descrições da fase de lançamento.

O GKE é compatível com políticas da organização CMEK (visualização) que podem exigir proteção CMEK e limitar quais chaves do Cloud KMS podem ser usadas para proteção CMEK.

Quando container.googleapis.com estiver na lista de serviços Deny da restrição constraints/gcp.restrictNonCmekServices, o GKE se recusará a criar os seguintes recursos se você não ativar a proteção CMEK:

• Novos clusters e pools de nós
• Novas instâncias do Filestore e discos permanentes

Quando a restrição constraints/gcp.restrictNonCmekCryptoKeyProjects é configurada em uma política da organização, o GKE cria apenas recursos protegidos por CMEK que usam uma chave de criptografia de um projeto, pasta ou organização permitida.

A seguir

• Leia as Perguntas frequentes do Cloud Key Management Service.
• Saiba mais sobre como proteger recursos com as chaves do Cloud KMS.