Criptografar secrets na camada do aplicativo

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. Use uma chave gerenciada com o Cloud KMS para criptografar dados em repouso na camada do aplicativo. Isso protege você 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 de serviço do 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 atuais usando a chave de criptografia.

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:

• Melhoria no desempenho em comparação com a criptografia de chave pública: o GKE só usa a API Cloud KMS para criptografar novas DEKs com a KEK ou para descriptografar uma DEK quando o cache local está vazio.
• Melhor gerenciamento de chaves em escala: uma única KEK pode criptografar várias DEKs. O número de chaves que você precisa armazenar no serviço do Cloud KMS é muito menor do que o número de chaves que criptografam seus dados.
• Capacidade de usar uma raiz de confiança central: 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, por exemplo, um módulo de segurança de hardware, para todos os secrets. Um invasor que acessar seus contêineres off-line não conseguirá acessar seus secrets.

Com a criptografia de secrets na camada do aplicativo no GKE, o GKE criptografa seus secrets usando DEKs locais e o provedor AES-CBC. O GKE criptografa as DEKs com uma KEK 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. A DEK de texto simples não é salva em disco e só fica armazenada na memória do servidor da API.

6. O servidor da API Kubernetes cria uma entrada de cache que mapeia a DEK criptografada para a DEK de texto simples na memória. Com isso, o servidor da API pode descriptografar o secret sem usar o Cloud KMS.

Confira 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?

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. É possível manter a versão anterior da KEK para evitar a recriptografia dos secrets, mas você continuará recebendo cobranças por todas as KEKs ativas no Cloud KMS. Confira mais detalhes em Preços do Cloud KMS.

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

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 pods reiniciados ou reprogramados acessem o secret, a menos que uma das seguintes situações ocorra:

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

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

Use a CLI gcloud ou o Console do Google Cloud.

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

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

Conceder permissão para usar a chave

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

service-CLUSTER_PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com

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.

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

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.

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

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.

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

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.

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

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.

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

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.

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

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.

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

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.

• 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

Para informações sobre como resolver problemas de criptografia de Secrets na camada do aplicativo, incluindo problemas com atualizações de criptografia de Secrets com falha, consulte este link.

A chave do Cloud KMS está desativada

A conta de serviço padrão do GKE não pode usar uma chave desativada do Cloud KMS na criptografia de Secrets na camada 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.