Encriptar segredos na camada de aplicação

Este tutorial mostra como encriptar segredos do Kubernetes na camada de aplicação através de uma chave que gere no Cloud Key Management Service (Cloud KMS). O processo de encriptação de segredos oferece uma camada adicional de segurança para cargas de trabalho confidenciais.

Esta página destina-se a especialistas em segurança que pretendam encriptar segredos. Para saber mais sobre as funções comuns e as tarefas de exemplo que referimos no conteúdo, consulte o artigo Funções e tarefas comuns do utilizador do GKE. Trusted Cloud by S3NS

Antes de ler esta página, certifique-se de que conhece os seguintes conceitos:

• Rotação de chaves
• Encriptação de envelope

Vista geral

Por predefinição, o Google Kubernetes Engine (GKE) encripta o conteúdo do cliente armazenado em repouso, incluindo segredos. O GKE processa e gere esta encriptação predefinida por si sem nenhuma ação adicional da sua parte. A encriptação de segredos na camada de aplicação oferece uma camada adicional de segurança para dados confidenciais, como segredos. Usa uma chave gerida com o Cloud KMS para encriptar dados em repouso na camada de aplicação.

O estado dos objetos da API Kubernetes no seu cluster, como os segredos, é armazenado numa base de dados. Esta base de dados de estado do cluster usa uma das seguintes tecnologias:

• etcd: as instâncias da base de dados etcd são executadas em todas as VMs do plano de controlo. A encriptação de segredos da camada de aplicação ajuda a proteger contra atacantes que obtêm acesso a uma cópia offline do etcd.
• Spanner: o GKE executa uma base de dados do Spanner na infraestrutura da Google. A base de dados está separada das VMs do plano de controlo do cluster e não pode ser transferida como uma cópia offline.

Para usar a encriptação de segredos da camada de aplicação, primeiro, tem de criar uma chave do Cloud KMS e conceder à conta de serviço do GKE acesso à chave. Pode usar uma chave que tenha qualquer um dos níveis de proteção suportados pelo Cloud KMS.

Certifique-se de que a chave está na mesma localização que o cluster para diminuir a latência e evitar casos em que os recursos dependem de serviços distribuídos por vários domínios de falhas. Depois de criar uma chave, pode ativar a funcionalidade num cluster novo ou existente especificando a chave que quer usar. Quando ativa a funcionalidade, o GKE encripta todos os segredos novos e existentes através da sua chave de encriptação.

Encriptação de envelope

O Kubernetes oferece encriptação em envelope de segredos com um fornecedor do KMS, o que significa que é usada uma chave local, normalmente denominada chave de encriptação de dados (DEK), para encriptar os segredos. A DEK em si está encriptada com outra chave denominada chave de encriptação de chaves (KEK). O Kubernetes não armazena a KEK.

A encriptação de envelopes tem as seguintes vantagens:

• Desempenho melhorado em comparação com a encriptação de chaves públicas: o GKE usa apenas a API Cloud KMS para encriptar novas DEKs com a KEK ou para desencriptar uma DEK quando a cache local está vazia.
• Melhor gestão de chaves em grande escala: uma única KEK pode encriptar várias DEKs. O número de chaves que tem de armazenar no serviço Cloud KMS é muito inferior ao número de chaves que encriptam os seus dados.
• Capacidade de usar uma raiz de confiança central: os segredos armazenados no Kubernetes podem basear-se numa raiz de confiança externa. Isto significa que pode usar uma raiz de confiança central, por exemplo, um módulo de segurança de hardware, para todos os seus segredos. Um adversário que aceda aos seus contentores offline não pode obter os seus segredos.

Com a encriptação de segredos da camada de aplicação no GKE, o GKE encripta os seus segredos através de DEKs locais e do fornecedor AES-CBC. O GKE encripta as DEKs com uma KEK que gere no Cloud KMS.

Para saber mais sobre a encriptação de envelope, consulte o artigo Encriptação de envelope.

O que acontece quando cria um vídeo secreto

Quando cria um novo Secret, acontece o seguinte:

1. O servidor da API Kubernetes gera uma DEK exclusiva para o segredo através de um gerador de números aleatórios.

2. O servidor da API Kubernetes usa a DEK localmente para encriptar o segredo.

3. O plug-in KMS envia a DEK para o Cloud KMS para encriptação. O plug-in do KMS usa a conta de serviço do GKE do seu projeto para fazer a autenticação no Cloud KMS.

4. O Cloud KMS encripta a DEK através da KEK e envia-a de volta para o plug-in do KMS.

5. O servidor da API Kubernetes guarda o secret encriptado e a DEK encriptada. A DEK de texto simples não é guardada num disco e é armazenada apenas na memória do servidor da API.

6. O servidor da API Kubernetes cria uma entrada de cache que mapeia a DEK encriptada para a DEK de texto simples na memória. Isto permite que o servidor da API desencripte o segredo sem usar o Cloud KMS.

Quando um cliente pede um segredo ao servidor da API Kubernetes, acontece o seguinte:

1. O servidor da API Kubernetes obtém o secret encriptado e a DEK encriptada.

2. O servidor da API Kubernetes verifica a existência de uma entrada de mapeamento na cache e desencripta o segredo sem usar o Cloud KMS.

3. Se não for encontrada uma entrada na cache, o plug-in do KMS envia a DEK para o Cloud KMS para desencriptação através da KEK. Em seguida, a DEK desencriptada é usada para desencriptar o segredo.

4. O servidor da API Kubernetes devolve o secret desencriptado ao cliente.

O que acontece quando destrói uma chave

Se planeia destruir uma versão antiga da KEK após uma rotação de chaves, use a nova versão da KEK para voltar a encriptar o segredo primeiro. Opcionalmente, pode reter a versão anterior da KEK para evitar a reencriptação de segredos, mas continua a receber faturação por todas as KEKs ativas no Cloud KMS. Para ver detalhes de preços, consulte os preços do Cloud KMS.

A menos que use uma projeção de volume de tokens de contas de serviço, as contas de serviço usadas pelos seus cargas de trabalho no GKE também usam segredos e, se uma chave for destruída, estes ficam indisponíveis. A incapacidade de aceder a estes recursos significa que as cargas de trabalho vão falhar.

Aplicam-se as seguintes exceções:

• Os pods com acesso existente a segredos como volumes montados ou variáveis de ambiente mantêm o acesso.

• O servidor da API Kubernetes pode continuar a usar entradas de mapeamento DEK em cache para desencriptar um segredo depois de destruir a KEK. Isto permite que os pods reiniciados ou reagendados acedam ao segredo, a menos que ocorra uma das seguintes situações:

  • O painel de controlo do cluster é reiniciado.
  • O pod do servidor da API Kubernetes é reiniciado.
  • A entrada de mapeamento da DEK para o segredo não está na cache do servidor da API Kubernetes.

Antes de destruir uma KEK, verifique se está a ser usada pelo seu cluster. Também pode criar uma política de alerta para a destruição de chaves no Cloud KMS. Destrua apenas as versões anteriores da KEK quando tiver a certeza de que nenhum dado no seu cluster está encriptado com a versão anterior. Antes de destruir uma KEK, verifique se a chave está em utilização. Para obter detalhes, consulte o artigo Destrua e restaure versões de chaves.

Pode agendar a destruição de uma versão principal após um período configurável. Durante este período, se mudar de ideias, pode restaurar a versão da chave para impedir a eliminação. No entanto, após a hora de destruição agendada, e a versão da chave ser destruída, esta ação é irreversível. Todos os dados encriptados com esta versão da chave vão ficar permanentemente indecriptáveis.

Antes de começar

• Para fazer os exercícios neste tópico, precisa de dois Trusted Cloud projetos:

  • Projeto principal: é aqui que cria uma KEK.

  • Projeto de cluster: é aqui que cria um cluster que permite a encriptação de segredos da camada de aplicação.

  Pode usar o mesmo projeto para o projeto principal e o projeto de cluster. No entanto, a prática recomendada é usar projetos separados.

• No projeto da chave, certifique-se de que ativou a API Cloud KMS.

  Ative a API Cloud KMS

• No seu projeto de chaves, o utilizador que cria o conjunto de chaves e a chave precisa das seguintes autorizações de IAM:

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

  Estas autorizações (e muitas mais) são concedidas à função de gestão de identidade e de acesso predefinida.roles/cloudkms.admin Pode saber mais acerca de conceder autorizações para gerir chaves na documentação do Cloud KMS.

• No projeto do cluster, certifique-se de que ativou a API Google Kubernetes Engine.

  Ative a API Google Kubernetes Engine

• Certifique-se de que instalou a CLI do Google Cloud.

• Atualize o gcloud para a versão mais recente:

  gcloud components update

Crie uma chave do Cloud KMS

Para criar uma chave do Cloud KMS, primeiro tem de criar um conjunto de chaves. As chaves e os porta-chaves são recursos regionais. Quando cria um conjunto de chaves, especifique uma localização que corresponda à localização do seu cluster do GKE:

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

• Um cluster regional deve usar um conjunto de chaves da mesma localização. Por exemplo, um cluster na região asia-northeast1 deve ser protegido com um conjunto de chaves da região asia-northeast1.

A região do Cloud KMS global não é suportada para utilização com o GKE.

Pode usar a CLI gcloud ou a Trusted Cloud consola.

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

Conceda autorização para usar a chave

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

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

Substitua CLUSTER_PROJECT_NUMBER pelo número do projeto do cluster. Para encontrar o número do projeto através da CLI gcloud, execute o seguinte comando:

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

Para conceder acesso à conta de serviço, pode usar a Trusted Cloud consola 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

Certifique-se de que a chave tem quota suficiente se for uma chave do Cloud HSM

Se usar uma chave do Cloud HSM, o Trusted Cloud by S3NS projeto que contém a chave está limitado pela sua quota de chaves. Certifique-se de que tem quota suficiente para usar as suas chaves do HSM na nuvem com a encriptação de segredos da camada de aplicação. Se a sua quota estiver esgotada, os seus nós podem perder a conetividade com o plano de controlo do cluster.

Ative a encriptação de segredos da camada de aplicação

Pode ativar a encriptação de segredos da camada de aplicação em clusters GKE Standard e GKE Autopilot novos ou existentes através da CLI gcloud ou da Trusted Cloud consola.

Ative num novo cluster

Pode criar um novo cluster com a encriptação de segredos da camada de aplicação ativada através da Trusted Cloud consola ou da CLI gcloud.

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

Ative num cluster existente

Pode usar a CLI gcloud ou a Trusted Cloud consola para atualizar um cluster existente de modo a usar a encriptação de segredos da camada de aplicação. O GKE encripta todos os seus segredos existentes e novos com a chave de encriptação especificada.

A atualização de um cluster existente para usar a encriptação de segredos da camada de aplicação reinicia o plano de controlo do cluster. Para clusters zonais, o plano de controlo fica indisponível.

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

Atualize uma chave do Cloud KMS

Pode usar a CLI gcloud ou a Trusted Cloud consola para atualizar um cluster existente de modo a usar uma nova chave do Cloud KMS.

A atualização de um cluster existente para usar uma nova chave do Cloud KMS reinicia o plano de controlo do cluster. Para clusters zonais, o plano de controlo fica indisponível.

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

Desative a encriptação de segredos da camada de aplicação

Para desativar a encriptação de segredos da camada de aplicação, pode usar a CLI gcloud ou a Trusted Cloud consola.

gcloud container clusters update CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --disable-database-encryption \
    --project=CLUSTER_PROJECT_ID

Verifique se a encriptação de segredos da camada de aplicação está ativada

Pode verificar se um cluster está a usar a encriptação de segredos da camada de aplicação através daTrusted Cloud consola ou da CLI gcloud.

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

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

Alterne as suas chaves

Quando faz uma alteração de chaves, os seus segredos existentes permanecem encriptados com a versão anterior da chave de encriptação de chaves (KEK). Para garantir que uma versão mais recente da KEK envolve um segredo, volte a encriptar o segredo após a rotação de chaves.

Por exemplo, cria e armazena um segredo, Secret1. Está encriptado com DEK1, que, por sua vez, está envolvido em KEKv1.

Após a rotação da KEK, volta a encriptar Secret1 para que seja envolvida por DEK2, que, por sua vez, é envolvida com KEKv2, a KEK rotada.

A rotação da versão da chave é uma operação eventualmente consistente e pode haver um atraso antes de a nova versão da chave entrar em vigor. Consulte o artigo Consistência das versões principais para mais informações.

Volte a encriptar os seus segredos

Após realizar uma rotação de chaves, deve voltar a encriptar os seus segredos para os encapsular com a nova versão da KEK. Pode voltar a encriptar os seus segredos de uma das seguintes formas:

• Manualmente, executando um comando kubectl num terminal.
• Automaticamente, através da utilização de uma carga de trabalho recorrente, como um CronJob, para executar um comando kubectl em intervalos regulares.

Após uma rotação de chaves, aguarde pelo menos três horas para que a nova versão se torne consistente. Em seguida, acione a reencriptação executando um comando como o seguinte:

kubectl get secrets --namespace=NAMESPACE -o json \
    | kubectl annotate --overwrite -f - encryption-key-rotation-time="TIME"

Substitua o seguinte:

• NAMESPACE: o espaço de nomes para atualizar os segredos. Nos clusters padrão, pode usar opcionalmente a flag --all-namespaces para atualizar todos os segredos no cluster com o mesmo comando. Nos clusters do Autopilot, só pode atualizar os espaços de nomes que são seus.
• TIME: uma string que indica quando ocorre a rotação (por exemplo, 20200909-090909).

Depois de alterar as chaves, a versão anterior da chave continua a existir e pode incorrer em custos. A destruição da versão da chave é permanente, por isso, certifique-se de que a versão da chave anterior já não está a ser usada antes de a destruir. Para mais informações, consulte o artigo Veja a utilização de chaves.

Limitações

• O GKE suporta até 30 000 segredos por cluster para a encriptação de segredos da camada de aplicação. Se armazenar mais de 30 000 segredos, o cluster pode ficar instável no momento da atualização, o que pode causar uma potencial indisponibilidade das suas cargas de trabalho.
• Certifique-se de que o tamanho médio dos metadados de um segredo em todos os namespaces é inferior a 5 KiB. Se o tamanho médio dos metadados for superior a 5 KiB, o cluster pode entrar num estado incorreto em que alguns segredos são encriptados, enquanto outros são desencriptados após ativar ou desativar a funcionalidade.

• Tem de selecionar uma chave na mesma região que o 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 têm de estar na mesma localização para diminuir a latência e evitar casos em que os recursos dependem de serviços distribuídos por vários domínios de falhas.

  A chave não tem de estar no mesmo projeto que o cluster. Para mais informações sobre as localizações suportadas para o Cloud KMS, consulte as Trusted Cloud by S3NS localizações.

• O GKE só suporta chaves do Cloud KMS. Não pode usar outro fornecedor do KMS do Kubernetes nem outro fornecedor de encriptação.

Resolução de problemas

Para informações sobre a resolução de problemas de encriptação de segredos da camada de aplicação, incluindo a resolução de problemas com atualizações de encriptação de segredos com falhas, consulte o artigo Resolva problemas de encriptação de segredos da camada de aplicação.

A chave do Cloud KMS está desativada

A conta de serviço predefinida do GKE não pode usar uma chave do Cloud KMS desativada para a encriptação de segredos da camada de aplicação.

Para reativar uma tecla desativada, consulte a secção Ative uma versão de tecla desativada.

A versão da chave do Cloud KMS é destruída

Quando o estado do cluster contém a mensagem: KEY_VERSION_URI is not enabled, current state is: DESTROYED, significa que a versão da chave usada para a encriptação de segredos da camada de aplicação foi destruída.

Substitua KEY_VERSION_URI pelo URI da versão da chave.

O que se segue?

• Saiba mais sobre os segredos no Kubernetes.
• Saiba mais sobre a gestão de segredos através do Cloud KMS.
• Saiba como proteger o seu cluster.