Criptografar secrets na camada do aplicativo

Autopilot Standard

Este tutorial mostra como criptografar os Secrets do Kubernetes na camada do aplicativo usando uma chave que você gerencia no Cloud Key Management Service (Cloud KMS). O processo de criptografia de secrets oferece uma camada extra de segurança para cargas de trabalho sensíveis.

Esta página é destinada a especialistas em segurança que querem criptografar secrets. Para saber mais sobre papéis comuns e exemplos de tarefas que mencionamos no conteúdo do Google Cloud , consulte Tarefas e funções de usuário comuns do GKE.

Antes de ler esta página, confira se você conhece os seguintes conceitos:

• Rotação de chaves
• Criptografia de envelope

---

Para seguir as instruções detalhadas 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 sensíveis, como secrets. Use uma chave gerenciada com o Cloud KMS para criptografar dados em repouso na camada do aplicativo.

O estado dos objetos da API Kubernetes no cluster, como secrets, é armazenado em um banco de dados. Esse banco de dados de estado do cluster usa uma das seguintes tecnologias:

• etcd: as instâncias de banco de dados etcd são executadas em todas as VMs do plano de controle. A criptografia de secrets da camada de aplicativo ajuda a proteger contra invasores que conseguem acesso a uma cópia off-line do etcd.
• Spanner: o GKE executa um banco de dados do Spanner na infraestrutura do Google. O banco de dados é separado das VMs do plano de controle do cluster e não pode ser baixado como uma cópia off-line.

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 existentes usando a chave de criptografia.

Observação: quando você usa a 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 afetam as cotas do Cloud KMS somente 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:

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

Cuidado: ao fazer a rotação de chaves, sempre recripte os secrets criptografados anteriormente. Quando você destrói uma versão de chave no Cloud KMS que ainda é usada para criptografar secrets no GKE, o cluster entra em um estado degradado e acaba ficando inoperante.

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. Só destrua versões anteriores da KEK quando tiver certeza de que nenhum dado no cluster foi criptografado com a versão anterior. Antes de destruir uma KEK, verifique se a chave está em uso. Para mais detalhes, consulte Destruir e restaurar versões de chave.

É possível programar a destruição de uma versão de chave após um período configurável. Durante esse período, se você mudar de ideia, poderá restaurar a versão da chave para evitar a exclusão. No entanto, depois que o horário de destruição programado chega e a versão da chave é destruída, essa ação é irreversível. Todos os dados criptografados com essa versão da chave vão ficar permanentemente ilegíveis.

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.

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

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

É possível usar a CLI gcloud ou o console 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. Na lista 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, use o console Google Cloud ou a CLI gcloud.

Console

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

1. No console do Google Cloud , acesse a página Gerenciamento de chaves.

   Vá para Gerenciamento de chaves

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

Ative a criptografia de secrets na camada do aplicativo

É 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 Google Cloud .

Prática recomendada:

Depois de ativar a criptografia de secrets na camada de aplicativos, faça uma rotação de chaves. É possível configurar a rotação automática de chaves no Cloud KMS.

Ativar em um novo cluster

É possível criar um novo cluster com a criptografia de secrets da camada de aplicativos ativada usando o console doGoogle 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. No Google Cloud console, acesse a página Criar um cluster do Autopilot.

   Acessar "Criar um cluster do Autopilot"

2. Configure o cluster como quiser.

3. No painel de navegação, clique em Configurações avançadas e expanda a seção Segurança.

4. Marque a caixa de seleção Criptografar secrets na camada do aplicativo e escolha a chave que você criou em Criar uma chave do Cloud KMS.

5. 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. No console Google Cloud , acesse a página Criar um cluster do Kubernetes.

   Acessar "Criar um cluster do Kubernetes"

2. Configure o cluster como quiser.

3. No painel de navegação, em Cluster, clique em Segurança.

4. Marque a caixa de seleção Criptografar secrets na camada do aplicativo e escolha a chave que você criou em Criar uma chave do Cloud KMS.

5. 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 \
    --location=CONTROL_PLANE_LOCATION \
    --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.
• CONTROL_PLANE_LOCATION: a região do Compute Engine do plano de controle 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

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

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

A atualização de um cluster para usar a criptografia de secrets da camada de aplicativo reinicia o plano de controle do cluster. Durante esse processo, o GKE recriptografa todos os secrets atuais com a nova chave. Portanto, espere uma operação de longa duração. 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 do Google Kubernetes Engine no Google Cloud console.

   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 \
    --location=CONTROL_PLANE_LOCATION \
    --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.
• CONTROL_PLANE_LOCATION: o local do Compute Engine do plano de controle do cluster. Forneça uma região para clusters regionais ou uma zona para clusters zonais.
• 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 Google Cloud para atualizar um cluster e usar uma nova chave do Cloud KMS.

A atualização de um cluster para usar uma nova chave do Cloud KMS reinicia o plano de controle do cluster. Durante esse processo, o GKE recriptografa todos os secrets atuais com a nova chave. Portanto, espere uma operação de longa duração. Para clusters zonais, o plano de controle fica indisponível durante a atualização.

Console

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

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

   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 \
    --location=CONTROL_PLANE_LOCATION \
    --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.
• CONTROL_PLANE_LOCATION: o local do Compute Engine do plano de controle do cluster. Forneça uma região para clusters regionais ou uma zona para clusters zonais.
• 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 na camada do aplicativo

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

Console

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

   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 \
    --location=CONTROL_PLANE_LOCATION \
    --disable-database-encryption \
    --project=CLUSTER_PROJECT_ID

Substitua:

• CLUSTER_NAME: o nome do cluster.
• CONTROL_PLANE_LOCATION: o local do Compute Engine do plano de controle do cluster. Forneça uma região para clusters regionais ou uma zona para clusters zonais.
• CLUSTER_PROJECT_ID: o ID do projeto do seu cluster

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

Você pode verificar se um cluster está usando a criptografia de Secrets da camada de aplicativos usando o consoleGoogle Cloud ou a CLI gcloud.

Console

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

   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 \
    --location=CONTROL_PLANE_LOCATION \
    --format='value(databaseEncryption)' \
    --project=CLUSTER_PROJECT_ID

Substitua:

• CLUSTER_NAME: o nome do cluster.
• CONTROL_PLANE_LOCATION: o local do Compute Engine do plano de controle do cluster. Forneça uma região para clusters regionais ou uma zona para clusters zonais.
• 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

Prática recomendada:

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.

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. 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. É possível recriptografar seus secrets de uma das seguintes maneiras:

• Manualmente, executando um comando kubectl em um terminal.
• Automaticamente, usando 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 fique consistente. Em seguida, acione a recriptografia executando um comando como este:

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

Substitua:

• NAMESPACE: o namespace em que os Secrets serão atualizados. Em clusters padrão, é possível usar a flag --all-namespaces para atualizar todos os Secrets no cluster com o mesmo comando. Nos clusters do Autopilot, só é possível atualizar os namespaces que você possui.
• TIME: uma string que indica quando a rotação acontece (por exemplo, 20200909-090909).

Aviso: se você usa clusters do Autopilot, não desative nem destrua a versão anterior da chave. Os secrets em namespaces gerenciados, como kube-system, continuam usando a versão anterior da chave. Desativar a chave pode causar interrupções.

Depois de fazer a rotação das chaves, a versão anterior continua existindo e pode gerar custos. A destruição da versão da chave é permanente. Portanto, verifique se a versão anterior não está mais em uso antes de destruí-la. Para mais informações, consulte Conferir o uso da chave.

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.

  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 Google Cloud locations.

• 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 versão da chave do Cloud KMS foi destruída

Quando o status do cluster contém a mensagem: KEY_VERSION_URI is not enabled, current state is: DESTROYED, isso significa que a versão da chave usada para criptografia de secrets da camada de aplicativo foi destruída.

Substitua KEY_VERSION_URI pelo URI da versão da chave.

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.