A criptografia de secrets na camada de aplicativos adiciona uma camada configurável de proteção para dados sensíveis no Google Kubernetes Engine (GKE), como credenciais e chaves. Problemas com essa configuração podem impedir que essa camada extra de segurança funcione corretamente.
Use este documento para solucionar problemas de criptografia de secrets na camada de aplicativos inspecionando os campos de depuração disponíveis no objeto de cluster da API GKE. Esses campos ajudam a diagnosticar a causa raiz de erros comuns, como falhas de atualização ou problemas com a chave do Cloud KMS.
Essas informações são importantes para administradores e operadores de plataforma e engenheiros de segurança responsáveis por proteger informações sensíveis armazenadas em clusters do GKE. Para mais informações sobre os papéis comuns e as tarefas de exemplo referenciadas no Google Cloud conteúdo, consulte Funções e tarefas de usuário comuns do GKE.
Falha na atualização
Quando você atualiza a configuração da criptografia de secrets na camada do aplicativo, o GKE precisa regravar todos os Secret objetos no cluster do Kubernetes. O GKE faz isso para garantir que todos os Secrets sejam criptografados pela nova chave do Cloud KMS ou sejam gravados sem criptografia, se você configurar isso.
Essa operação de atualização pode falhar devido a qualquer uma das seguintes condições:
- O plano de controle do Kubernetes fica temporariamente indisponível enquanto a atualização está em andamento.
- Um
AdmissionWebhookdefinido pelo usuário impede que o GKE atualize objetos Secret. - A chave atualizada ou anterior do Cloud KMS é desativada antes da conclusão da operação de atualização.
Até que a operação de atualização seja concluída, não interaja com as chaves atualizadas ou anteriores do Cloud KMS.
Campos de depuração
Novos clusters do GKE que executam a versão 1.29 e posteriores contêm campos adicionais que ajudam a monitorar atualizações para Cluster.DatabaseEncryption e a se recuperar de falhas.
As etapas a seguir se aplicam apenas aos clusters em que o campo DatabaseEncryption.CurrentState não está vazio. Se o campo CurrentState estiver vazio, o recurso ainda não estará ativado nessa versão do cluster.
Os limites a seguir se aplicam a esses campos:
- São somente saída, o que significa que não é possível defini-los durante as solicitações de criação ou atualização do cluster.
Campo CurrentState
É possível inspecionar o status atual de uma operação de atualização de DatabaseEncryption examinando o campo CurrentState em Cluster.DatabaseEncryption.
Valor de CurrentState |
Descrição |
|---|---|
|
|
A operação de atualização mais recente foi concluída. Nenhuma outra ação é necessária. É possível descartar as chaves usadas anteriormente. |
|
|
A atualização está em andamento. |
|
|
Ocorreu um erro com a atualização mais recente. Não desative nem destrua as chaves do Cloud KMS usadas anteriormente, porque elas ainda podem estar em uso pelo GKE.
Consulte o campo |
Campo LastOperationErrors
Quando uma operação de atualização falha, o erro subjacente do plano de controle do GKE é exibido na saída de gcloud container clusters update.
As mensagens de erro das duas operações de atualização com falha mais recentes também estão disponíveis em Cluster.DatabaseEncryption.LastOperationErrors.
Campo DecryptionKeys
A chave do Cloud KMS usada para novas operações de criptografia é mostrada em DatabaseEncryption.KeyName. Normalmente, essa é a única chave usada pelo cluster.
No entanto, DatabaseEncryption.DecryptionKeys contém outras chaves que também são usadas pelo cluster quando uma atualização está em andamento ou após uma falha.
Recuperar-se de uma falha na atualização
Para se recuperar de uma falha na atualização, faça isto:
- Analise a mensagem de erro e resolva os problemas indicados.
- Repita a solicitação de atualização executando o comando que falhou, como
gcloud container clusters update ... --database-encryption-key. Recomendamos que você repita com a mesma solicitação de atualização emitida originalmente ou atualize o cluster para o estado anterior. O GKE talvez não consiga fazer a transição para um estado diferente de chave ou criptografia se não puder ler um ou mais Secrets.
As seções a seguir listam os motivos comuns para os erros.
Erro de chave do Cloud KMS
Se a mensagem de erro contiver uma referência a uma ou mais chaves do Cloud KMS, examine a configuração da respectiva chave para garantir que as versões relevantes dela sejam utilizáveis.
Se o erro indicar que uma chave do Cloud KMS foi desativada ou destruída, reative a chave ou a versão dela.
Erro: não é possível usar a chave do Cloud KMS configurada para criptografia no nível do aplicativo
A mensagem de erro a seguir ocorre se a conta de serviço padrão do GKE não puder acessar a chave do Cloud KMS:
Cluster problem detected (Kubernetes Engine Service Agent account unable to use CloudKMS key configured for Application Level encryption).
Para resolver esse problema, reative a chave desativada.
Não foi possível atualizar o Secret
O seguinte erro poderá ocorrer se a API Kubernetes recusar a solicitação de atualização devido a um webhook de admissão:
error admission webhook WEBHOOK_NAME denied the request
Para resolver esse erro, remova ou modifique o webhook para que o GKE possa atualizar os Secrets em todos os namespaces durante atualizações de chave.
Erro: o namespace é gerenciado
O erro a seguir ocorre quando você tenta criptografar novamente os Secrets que estão em um namespace gerenciado pelo GKE, como kube-system, em um cluster do Autopilot. A mensagem de erro é semelhante a esta:
Error from server (Forbidden): secrets "alertmanager" is
forbidden: User cannot patch resource "secrets" in API group "" in the namespace "gke-gmp-system":
GKE Warden authz [denied by managed-namespaces-limitation]: the namespace "gke-gmp-system"
is managed and the request's verb "patch" is denied'
Os clusters do Autopilot do GKE não permitem modificar recursos do Kubernetes, incluindo Secrets, em namespaces gerenciados.
Para resolver esse erro, faça o seguinte:
- Se você usar comandos
kubectlpara criptografar novamente os Secrets, use a flag--namespacepara definir o escopo do comando para namespaces que você gerencia. - Se você usar um CronJob para criptografar novamente os Secrets, implante-o apenas nos namespaces que você gerencia.
Plano de controle sem resposta após desativar a criptografia
Desativar a criptografia de secrets na camada de aplicativos muito rapidamente após ativá-la pode interromper o job de criptografia inicial, o que pode fazer com que o plano de controle kube-apiserver do cluster deixe de responder.
Confira abaixo os sintomas desse problema:
- As operações de cluster, como
list node,list podseget apiserver readiness, falham com o código de erro 13 e a mensagemInternal Server Error. - Os controladores do Kube não funcionam, e os pods excluídos de StatefulSets ou ReplicaSets não são recriados.
- As chamadas de webhook falham porque a conexão é recusada.
Para atenuar esse problema, faça o seguinte:
- Reative a criptografia de secrets na camada de aplicativos usando a mesma chave do Cloud KMS que você usou anteriormente para ativar a criptografia.
Para evitar esse problema, verifique se:
- Depois de ativar a criptografia de secrets na camada de aplicativos, verifique se o cluster ficou estável por algumas horas antes de desativar a criptografia.
A seguir
Se você não encontrar uma solução para o problema na documentação, consulte Receber suporte para mais ajuda, incluindo conselhos sobre os seguintes tópicos:
- Abrir um caso de suporte entrando em contato com o Cloud Customer Care.
- Receber suporte da comunidade fazendo
perguntas no StackOverflow
e usando a
google-kubernetes-enginetag para pesquisar problemas semelhantes. Você também pode participar do#kubernetes-enginecanal do Slack para mais suporte da comunidade. - Abrir problemas ou solicitações de recursos usando o Issue Tracker público.