Criptografar secrets na camada do aplicativo

Autopilot Padrão

---

Saiba como criptografar os Secrets do Kubernetes na camada do aplicativo usando uma chave que você gerencia no Cloud Key Management Service (Cloud KMS). Como esse recurso depende da funcionalidade do Cloud KMS, é recomendado que você primeiro conheça a rotação de chaves e a criptografia de envelope.

---

Para seguir as instruções passo a passo desta tarefa diretamente no console do Google Cloud, clique em Orientação:

Orientações

---

Visão geral

Por padrão, o Google Kubernetes Engine (GKE) criptografa o conteúdo do cliente armazenado em repouso, incluindo os secrets. O GKE executa e gerencia essa criptografia sem que você precise executar outra ação.

A criptografia de Secrets da camada de aplicativos fornece uma camada extra de segurança para dados confidenciais, como Secrets armazenados no etcd. Essa funcionalidade permite usar uma chave gerenciada com o Cloud KMS para criptografar dados na camada do aplicativo. Isso protege contra invasores que consigam acesso a uma cópia off-line do etcd.

Para usar a criptografia de secrets da camada do aplicativo, é preciso primeiro criar uma chave do Cloud KMS e conceder a ela acesso à conta do serviço GKE. É possível usar uma chave que tenha um dos níveis de proteção compatíveis com o Cloud KMS.

Verifique se a chave está no mesmo local que o cluster para diminuir a latência e evitar casos em que os recursos dependem de serviços espalhados por vários domínios de falha. Depois de criar uma chave, é possível ativar o recurso em um cluster novo ou atual especificando a chave que você quer usar. Quando você ativa o recurso, o GKE criptografa todos os Secrets novos e existentes usando a chave de criptografia.

Observação: Ao usar CMEK no GKE, seus projetos podem consumir cotas de solicitações criptográficas do Cloud KMS. Por exemplo, o GKE pode consumir essas cotas ao usar uma chave de criptografia de chaves do Cloud KMS para criptografar ou descriptografar uma chave de criptografia de dados no GKE. As operações de criptografia e descriptografia que usam chaves CMEK só afetam as cotas do Cloud KMS se você usar chaves de hardware (Cloud HSM) ou externas (Cloud EKM). Para mais informações, consulte Cotas do Cloud KMS.

Criptografia de envelope

O Kubernetes oferece criptografia de envelope de secrets com um provedor KMS. Ou seja, uma chave local chamada de chave de criptografia de dados (DEK, na sigla em inglês), é usada para criptografar os secrets. A DEK é criptografada com outra chave chamada chave de criptografia de chaves (KEK). O Kubernetes não armazena a KEK.

A criptografia de envelope proporciona os seguintes benefícios:

• A KEK pode ser girada sem exigir uma nova criptografia de todos os secrets. Isso torna mais fácil seguir a prática recomendada de rotação de chaves regular, sem um impacto significativo no desempenho.

• Os secrets armazenados no Kubernetes podem contar com uma raiz de confiança externa. Isso significa que é possível usar uma raiz de confiança central, como um módulo de segurança de hardware para todos secrets, e que um invasor que acessar seus contêineres off-line não terá acesso aos seus Secrets.

Com a criptografia de secrets da camada de aplicativo no GKE, seus secrets são criptografados localmente, usando o provedor AES-CBC com DEKs locais, e as DEKs são criptografadas com uma chave de criptografia de chaves que você gerencia no Cloud KMS.

Para saber mais sobre criptografia de envelope, consulte este link.

O que acontece quando você cria um secret?

Eis o que acontece quando um novo secret é criado:

1. O servidor da API Kubernetes gera uma DEK exclusiva para o secret usando um gerador de números aleatórios.

2. O servidor da API Kubernetes usa a DEK localmente para criptografar o secret.

3. O plug-in KMS envia a DEK para o Cloud KMS para criptografia. O plug-in KMS usa a conta de serviço GKE do seu projeto para se autenticar no Cloud KMS.

4. O Cloud KMS criptografa a DEK usando a KEK e a envia de volta ao plug-in KMS.

5. O servidor da API Kubernetes salva o secret criptografado e a DEK criptografada. O texto simples DEK não é salvo no disco.

6. O servidor da API do Kubernetes cria uma entrada de cache que mapeia a DEK criptografada para o DEK de texto simples. Isso permite que o servidor da API descriptografe o secret sem usar o Cloud KMS.

Veja o que acontece quando um cliente solicita um secret do servidor da API Kubernetes:

1. O servidor da API Kubernetes recupera o secret criptografado e a DEK criptografada.

2. O servidor da API Kubernetes verifica o cache para uma entrada de mapeamento atual e descriptografa o secret sem usar o Cloud KMS.

3. Se uma entrada de cache não for encontrada, o plug-in KMS enviará a DEK ao Cloud KMS para descriptografia usando a KEK. A DEK descriptografada é usada para descriptografar o secret.

4. O servidor da API Kubernetes retorna o secret descriptografado ao cliente.

O que acontece quando você destrói uma chave?

Aviso: a destruição de uma chave não é uma ação reversível. Os dados criptografados com a versão destruída não poderão ser recuperados.

Quando você destrói uma KEK no Cloud KMS usada para criptografar um secret no GKE, ela fica indisponível, a menos que você atualize o cluster para usar uma nova KEK primeiro.

Se você planeja destruir uma versão anterior da KEK após uma rotação de chaves, use a nova versão para criptografar novamente o secret.

A menos que se use uma Projeção de volume de token da conta de serviço, as contas de serviço usadas pelas cargas de trabalho no GKE também usam secrets. Além disso, se uma chave for destruída, ela ficará indisponível. Caso não seja possível acessar, as cargas de trabalho falharão.

Observação: cargas de trabalho do sistema no GKE usam secrets para autenticação da conta de serviço. Se uma KEK for destruída e esses secrets ficarem indisponíveis, o cluster não será iniciado.

com as seguintes exceções:

• Os pods com acesso atual aos secrets como volumes ativados ou variáveis de ambiente mantêm o acesso.

• O servidor da API Kubernetes ainda pode usar entradas de mapeamento DEK armazenadas em cache para descriptografar um secret depois que você destruir a KEK. Isso permite que os pods reiniciados ou reprogramados acessem o secret, a menos que:

  • O plano de controle do cluster é reiniciado.
  • O pod do servidor da API Kubernetes é reiniciado.
  • A entrada de mapeamento de DEK para o secret não está no cache do servidor da API Kubernetes.

Antes de destruir uma KEK, verifique se ela está sendo usada pelo cluster. Também é possível criar uma política de alertas para a destruição da chave no Cloud KMS.

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

  • Projeto de cluster: em que você cria um cluster que habilita a criptografia de secrets da camada de aplicativos.

  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 seu projeto de chave, 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 (e muitas outras) são concedidas ao papel de gerenciamento de identidade e acesso predefinido roles/cloudkms.admin. Saiba mais sobre a concessão de permissões para gerenciar chaves na documentação do Cloud KMS.

• Verifique se você ativou a API Google Kubernetes Engine no seu projeto de cluster.

  Ativar a API Google Kubernetes Engine

• Confirme se você instalou a Google Cloud CLI.

• Atualize gcloud para a versão mais recente:

  gcloud components update

Criar uma chave do Cloud KMS

Para criar uma chave do Cloud KMS, é preciso primeiro criar um keyring. Chaves e keyrings são recursos regionais. Ao criar um keyring, especifique um local que corresponda àquele do seu 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.

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

Use a CLI gcloud ou o Console do Google Cloud.

Console

No projeto de chave, crie um keyring:

1. Acesse a página Gerenciamento de chaves no console do Google Cloud.

   Vá para Gerenciamento de chaves

2. Clique em Criar keyring.

3. No campo Nome do keyring, digite o nome do seu keyring.

4. No menu suspenso Local, selecione o local do seu cluster do Kubernetes.

5. Clique em Criar.

Em seguida, crie uma chave:

1. Acesse a página Gerenciamento de chaves no console do Google Cloud.

   Vá para Gerenciamento de chaves

2. Clique no nome do keyring em que a chave será criada.

3. Clique em Criar chave.

4. No campo Nome da chave, insira o nome da sua chave.

5. Aceite os valores padrão de Período de rotação e A partir de. Se quiser usar valores diferentes, defina um período de rotação de chaves e o horário de início.

6. Opcional: no campo Rótulos, clique em Adicionar rótulo se quiser adicionar rótulos à chave.

7. Clique em Criar.

gcloud

No projeto de chave, crie um keyring:

gcloud kms keyrings create RING_NAME \
    --location=LOCATION \
    --project=KEY_PROJECT_ID

Substitua:

• RING_NAME: o nome do novo keyring.
• LOCATION: o local onde você quer criar o keyring.
• KEY_PROJECT_ID: o ID de projeto da chave;

Crie uma chave

gcloud kms keys create KEY_NAME \
    --location=LOCATION \
    --keyring=RING_NAME \
    --purpose=encryption \
    --project=KEY_PROJECT_ID

Substitua:

• KEY_NAME: o nome da nova chave.
• LOCATION: o local do Cloud KMS em que você criou o keyring.
• RING_NAME: o nome do keyring;
• KEY_PROJECT_ID: o ID de projeto da chave;

Conceder permissão para usar a chave

A conta de serviço do GKE no seu projeto de cluster tem o seguinte nome:

[e-mail]

Substitua CLUSTER_PROJECT_NUMBER pelo número do projeto do cluster. Para encontrar o número do projeto usando a CLI gcloud, execute o seguinte comando:

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

Para conceder acesso à conta de serviço, você pode usar o Console do Google Cloud ou a CLI gcloud.

Console

Conceda à sua conta de serviço GKE o papel criptografador/descriptografador do Cloud KMS CryptoKey:

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 GKE à qual você está concedendo acesso.

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

6. Clique em Salvar.

gcloud

Conceda à sua conta de serviço GKE o papel criptografador/descriptografador do Cloud KMS CryptoKey:

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

Substitua:

• KEY_NAME: o nome da chave;
• LOCATION: o local do Cloud KMS em que você criou o keyring.
• RING_NAME: o nome do keyring;
• SERVICE_ACCOUNT_NAME: o nome da conta de serviço do GKE.
• KEY_PROJECT_ID: o ID de projeto da chave;

Verifique se a chave tem cota suficiente se for uma chave do Cloud HSM

Se você usar uma chave do Cloud HSM, o projeto do Google Cloud que contém a chave será limitado pela cota de chaves. Verifique se você tem uma cota suficiente para usar as chaves do Cloud HSM com criptografia de secrets da camada de aplicativos. Se a cota estiver esgotada, os nós poderão perder a conectividade com o plano de controle do cluster.

Ativar a criptografia de secrets da camada de aplicativos

É possível ativar a criptografia de secrets da camada de aplicativos em clusters novos ou atuais do GKE Standard e do Autopilot do GKE usando a CLI gcloud ou o Console do Google Cloud.

Após ativar a criptografia de secrets da camada de aplicativos, recomendamos executar uma rotação de chaves. É possível configurar a rotação automática de chaves no Cloud KMS. Para mais instruções, consulte Como configurar a rotação automática.

Em um novo cluster

É possível criar um novo cluster com a criptografia de secrets da camada de aplicativos ativada usando o Console do Google Cloud ou a CLI gcloud.

Console: Autopilot

Para criar um cluster do Autopilot com a criptografia de secrets da camada de aplicativo ativada, 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. No painel de navegação, clique em Opções avançadas e expanda a seção Segurança.

6. Marque a caixa de seleção Ativar a criptografia de secrets da camada de aplicativos e escolha a chave que você criou em Criar uma chave do Cloud KMS.

7. Clique em Criar.

Console: padrão

Para criar um cluster padrão com a criptografia de secret da camada de aplicativo ativada, 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 Cluster, clique em Segurança.

6. Marque a caixa de seleção Ativar a criptografia de secrets da camada de aplicativos e escolha a chave que você criou em Criar uma chave do Cloud KMS.

7. Clique em Criar.

gcloud

Para criar um cluster compatível com a criptografia de secret de camada do aplicativo, especifique um valor para o parâmetro --database-encryption-key no comando de criação.

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

Substitua:

• CLUSTER_NAME: o nome escolhido para o novo cluster.
• COMPUTE_REGION: a região do Compute Engine em que você quer criar o cluster.
• KEY_PROJECT_ID: o ID de projeto da chave;
• LOCATION: o local do Cloud KMS em que você criou o keyring.
• RING_NAME: o nome do keyring;
• KEY_NAME: o nome da chave;
• CLUSTER_PROJECT_ID: o ID do projeto do seu cluster

É possível ativar a criptografia de secrets na camada do aplicativo em um novo cluster padrão usando o comando gcloud container clusters create com as mesmas sinalizações.

Em um cluster atual

Use a CLI gcloud ou o Console do Google Cloud para atualizar um cluster e usar a criptografia de secrets da camada de aplicativos. O GKE criptografa todos os Secrets novos e atuais usando a chave de criptografia especificada.

Importante: a atualização de um cluster para usar a criptografia de secrets da camada de aplicativos reinicia o plano de controle do cluster. Para clusters zonais, o plano de controle fica indisponível.

Console

Para atualizar um cluster para que ele seja compatível com a criptografia de secrets da camada de aplicativo, faça o seguinte:

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

   Acessar o Google Kubernetes Engine

2. Clique no nome do cluster que você quer modificar.

3. Em Segurança, no campo Criptografia de secrets da camada de aplicativos, clique em Editar criptografia de secrets da camada de aplicativos.

4. Marque a caixa de seleção Ativar a criptografia de secrets da camada de aplicativos e escolha a chave criada em Criar uma chave do Cloud KMS.

5. Clique em Save Changes.

gcloud

Para ativar as criptografias de secrets da camada de aplicativo em um cluster, execute o seguinte comando:

gcloud container clusters update CLUSTER_NAME \
    --region=COMPUTE_REGION \
    --database-encryption-key=projects/KEY_PROJECT_ID/locations/LOCATION/keyRings/RING_NAME/cryptoKeys/KEY_NAME \
    --project=CLUSTER_PROJECT_ID

Substitua:

• CLUSTER_NAME: o nome do cluster.
• COMPUTE_REGION: a região do Compute Engine do cluster.
• KEY_PROJECT_ID: o ID de projeto da chave;
• LOCATION: o local do Cloud KMS em que você criou o keyring.
• RING_NAME: o nome do keyring;
• KEY_NAME: o nome da chave;
• CLUSTER_PROJECT_ID: o ID do projeto do seu cluster

Atualizar uma chave do Cloud KMS

Use a CLI gcloud ou o Console do Google Cloud para atualizar um cluster e usar uma nova chave do Cloud KMS.

Important e: a atualização de um cluster para usar uma nova chave do Cloud KMS reinicia o plano de controle do cluster. Para clusters zonais, o plano de controle fica indisponível.

Console

Para atualizar um cluster para usar uma nova chave do Cloud KMS:

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

   Acessar o Google Kubernetes Engine

2. Clique no nome do cluster que você quer modificar.

3. Em Segurança, no campo Criptografia de secrets da camada de aplicativos, clique em Editar criptografia de secrets da camada de aplicativos.

4. Selecione a nova chave de criptografia que você quer usar.

5. Clique em Save Changes.

gcloud

Atualize o cluster atual para usar uma nova chave do Cloud KMS:

gcloud container clusters update CLUSTER_NAME \
    --region=COMPUTE_REGION \
    --database-encryption-key=projects/KEY_PROJECT_ID/locations/LOCATION/keyRings/RING_NAME/cryptoKeys/KEY_NAME \
    --project=CLUSTER_PROJECT_ID

Substitua:

• CLUSTER_NAME: o nome do cluster.
• COMPUTE_REGION: a região do Compute Engine do cluster.
• KEY_PROJECT_ID: o ID de projeto da chave;
• LOCATION: o local do Cloud KMS em que você criou o keyring.
• RING_NAME: o nome do keyring;
• KEY_NAME: o nome da chave;
• CLUSTER_PROJECT_ID: o ID do projeto do seu cluster

Desativar a criptografia de secrets da camada do aplicativo

Para desativar a criptografia de secrets da camada de aplicativos, use a CLI gcloud ou o Console do Google Cloud.

Console

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

   Acessar o Google Kubernetes Engine

2. Clique no nome do cluster que você quer modificar.

3. Em Segurança, no campo Criptografia de secrets da camada de aplicativos, clique em Editar criptografia de secrets da camada de aplicativos.

4. Desmarque a caixa de seleção Ativar a criptografia do secret da camada do aplicativo.

5. Clique em Save Changes.

gcloud

Para desativar a criptografia de secrets da camada do aplicativo, execute o seguinte comando:

gcloud container clusters update CLUSTER_NAME \
    --region=COMPUTE_REGION \
    --disable-database-encryption \
    --project=CLUSTER_PROJECT_ID

Substitua:

• CLUSTER_NAME: o nome do cluster.
• COMPUTE_REGION: a região do Compute Engine do cluster.
• CLUSTER_PROJECT_ID: o ID do projeto do seu cluster

Verificar se a criptografia de secrets da camada de aplicativo está ativada

É possível verificar se um cluster está usando a criptografia de Secrets da camada de aplicativos usando o Console do Google Cloud ou a CLI gcloud.

Console

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

   Acessar o Google Kubernetes Engine

2. Clique no nome do cluster que você quer modificar.

3. Em Segurança, verifique se o campo Criptografia de secrets da camada de aplicativos exibe Enabled e lista a chave correta.

gcloud

Verifique se um cluster está usando a criptografia de secrets da camada de aplicativos:

gcloud container clusters describe CLUSTER_NAME \
    --region=COMPUTE_REGION \
    --format='value(databaseEncryption)' \
    --project=CLUSTER_PROJECT_ID

Substitua:

• CLUSTER_NAME: o nome do cluster.
• COMPUTE_REGION: a região do Compute Engine do cluster.
• CLUSTER_PROJECT_ID: o ID do projeto do seu cluster

Se o cluster usar a criptografia de secrets da camada de aplicativos, a resposta será semelhante a esta:

keyName=projects/KEY_PROJECT_ID/locations/LOCATION/keyRings/RING_NAME/cryptoKeys/KEY_NAME;state=ENCRYPTED

Alternar chaves

Recomendamos que você alterne suas chaves regularmente, incluindo depois de ativar a criptografia de secrets da camada de aplicativos. Para instruções sobre como configurar a rotação automática de chaves ou alternar as chaves manualmente, consulte Como alternar chaves.

Quando você realiza uma rotação de chaves, os secrets permanecem criptografadas com a versão anterior da chave de criptografia de chaves (KEK). Para garantir que uma versão da KEK mais recente una um secret, refaça a criptografia dele após a rotação de chaves.

Por exemplo, você cria e armazena um secret, Secret1. Ele é criptografado com DEK1, que por si só é unido com KEKv1.

Após a rotação da KEK, você recriptografa Secret1 para que seja encapsulado por DEK2, que, por sua vez, é encapsulado com KEKv2, a KEK rotacionada.

Observação: a rotação da versão de chave é uma operação de consistência posterior e pode haver um atraso até que a nova versão entre em vigor. Recomendamos que você aguarde pelo menos três horas antes de recriptografar seus secrets após uma rotação. Consulte Consistência de versões de chave para mais informações.

Recriptografar secrets

Depois de executar uma rotação de chaves, criptografe novamente os secrets para incluí-los na nova versão da KEK. Embora não seja possível configurar a recriptografia automática usando a CLI gcloud, é possível, por exemplo, usar um CronJob para executar o comando de recriptografia em intervalos regulares.

Para recriptografar manualmente os secrets após uma rotação de chaves, aguarde pelo menos três horas até que a nova versão fique consistente. Em seguida, toque em cada secret para forçar a nova criptografia usando um comando como o seguinte:

kubectl get secrets --all-namespaces -o json | kubectl annotate --overwrite -f - encryption-key-rotation-time="TIME"

Substitua TIME por uma string que indica quando a rotação acontece (por exemplo, 20200909-090909).

Observação: a versão antiga da chave ainda existirá e gerará custos. Se a versão antiga não estiver mais em uso, convém destruí-la. A destruição da versão da chave é permanente. Portanto, recriptografe os secrets antes de fazer isso.

Limitações

• O GKE aceita até 30.000 secrets por cluster para criptografia de secrets da camada de aplicativos. Se você armazenar mais de 30.000 secrets, seu cluster poderá ficar instável no momento do upgrade, causando uma possível interrupção das cargas de trabalho.
• Verifique se o tamanho médio dos metadados de um secret em cada namespace é menor que 5 KiB. Se o tamanho médio dos metadados for superior a 5 KiB, o cluster poderá entrar em um estado inadequado, em que alguns secrets são criptografados enquanto outros são descriptografados após a ativação ou a desativação do recurso.

• É preciso selecionar uma chave na mesma região do cluster. Por exemplo, um cluster zonal em us-central1-a só pode usar uma chave na região us-central1. Para clusters regionais, as chaves precisam estar no mesmo local para diminuir a latência e evitar casos em que os recursos dependem de serviços espalhados por vários domínios de falha.

  Observação: a chave não precisa estar no mesmo projeto que o cluster. Para mais informações sobre os locais compatíveis com o Cloud KMS, consulte Locais do Cloud.

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

Solução de problemas

Chave do Cloud KMS desativada

A conta de serviço padrão do GKE não pode usar uma chave desativada do Cloud KMS na criptografia de secrets do aplicativo.

Para reativar uma chave desativada, consulte Ativar uma versão de chave desativada.

A seguir

• Saiba mais sobre as chaves secretas no Kubernetes.
• Saiba mais sobre o uso do Cloud KMS no gerenciamento de secrets.
• Saiba como proteger seu cluster.