Usar chaves de criptografia gerenciadas pelo cliente (CMEK)

Autopilot Padrão

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

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.
Verifique se você ativou a API do Cloud KMS no seu projeto de chave.

Ativar a API Cloud KMS
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.
No projeto do cluster, verifique se você ativou a API Cloud KMS.

Ativar a API Cloud KMS
Verifique se você instalou a gcloud CLI.
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:

service-PROJECT_NUMBER@compute-system.iam.gserviceaccount.com

Substitua PROJECT_NUMBER pelo número do projeto do cluster.

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:

Abra o navegador de chaves do Cloud Key Management Service no console do Google Cloud.
Abrir o navegador de Chaves do Cloud KMS
Clique no nome do keyring que contém a chave que você quer.
Marque a caixa de seleção da chave.

A guia Permissões no painel da janela à direita fica disponível.
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.
Na lista suspensa Selecionar um papel, escolha Criptografador/Descriptografador do Cloud KMS CryptoKey.
Clique em Save.

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:

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

Acessar o Google Kubernetes Engine
Clique em Criar.
Na seção Padrão, clique em Configurar.
Configure o cluster como quiser.
No painel de navegação, em Pools de nós, clique em Nós.
Na lista suspensa Tipo de disco de inicialização, selecione Disco permanente padrão ou Disco permanente SSD.
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.
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:

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

Acessar o Google Kubernetes Engine
Clique em Criar.
Na seção Autopilot, clique em Configurar.
Configure o cluster como quiser.
Expanda a seção Opções avançadas e localize as opções de Segurança.
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.
Clique em Criar.

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

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

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

Acessar o Google Kubernetes Engine
Na lista de clusters, clique no nome do cluster que você quer modificar.
Clique em Adicionar pool de nós.
No painel de navegação, clique em Nós.
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.
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.
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.
Conceder permissão 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.

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

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).
Implante o StorageClass no cluster do GKE usando kubectl:
```
kubectl apply -f cmek-sc.yaml
```

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.

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

Aplique o PersistentVolumeClaim (PVC) no cluster do GKE:
```
kubectl apply -f pvc.yaml
```
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
```
Aplique o pod no cluster do GKE:
```
kubectl apply -f pod.yaml
```

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

}

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

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.