Acerca da rotação de segredos

A rotação de segredos é o processo de atualização ou substituição periódica de informações confidenciais (segredos), como palavras-passe, chaves da API ou chaves de encriptação. A rotação de segredos ajuda a minimizar o risco de acesso não autorizado ou utilização indevida de segredos, especialmente se tiverem sido comprometidos ou divulgados.

A rotação periódica ajuda das seguintes formas:

  • Limita o impacto no caso de um código secreto divulgado.

  • Garante que os indivíduos que já não precisam de acesso a um segredo não podem usar valores de segredos antigos.

  • Minimiza o risco de interrupções do serviço se precisar de rodar segredos urgentemente.

O Secret Manager tem um conceito de segredos, versões de segredos e programações de rotação, que fornecem uma base para criar cargas de trabalho que suportam segredos rotados.

Esta página fornece recomendações para a rotação de segredos armazenados no Secret Manager. Vai aprender a fazer o seguinte:

Antes de começar, recomendamos que leia a vista geral da plataforma para compreender o panorama Google Cloud geral. Também recomendamos que leia a vista geral do produto Secret Manager.

Associe uma versão do segredo à sua aplicação

Um segredo no Secret Manager pode ter várias versões do segredo. As versões dos Secrets contêm a carga útil imutável (a string de bytes do Secret real) e são ordenadas e numeradas. Para rodar um segredo, adicione uma nova versão do segredo a um segredo existente.

Pode fazer referência à versão do Secret adicionada mais recentemente num Secret através do alias latest. O alias latest, embora seja conveniente para o desenvolvimento, pode ser problemático para algumas cargas de trabalho de produção, uma vez que um valor incorreto pode ser implementado imediatamente e resultar numa indisponibilidade ao nível do serviço. Os métodos alternativos para associar a uma versão secreta são descritos nos seguintes cenários.

Implementações graduais

As implementações graduais são um princípio orientador para os seguintes cenários. Ao escolher uma implementação secreta mais lenta, existe um risco menor de falhas, mas também um tempo de recuperação mais lento. Alguns segredos podem ser invalidados em sistemas externos (como APIs ou bases de dados que acompanham valores secretos válidos) que podem ou não estar sob o seu controlo, e a recuperação nestes casos requer uma implementação.

É possível que seja implementado um segredo inválido durante a rotação manual ou automática. Um fluxo de trabalho de rotação forte deve conseguir detetar automaticamente a falha (por exemplo, taxas de erro HTTP) e reverter para usar a versão secreta mais antiga (através de uma implementação de configuração anterior).

A implementação da nova versão do Secret depende da forma como os segredos estão associados à sua aplicação.

Abordagem 1: resolva o problema durante um processo de lançamento existente

Resolva e associe a versão do segredo ao lançamento da sua aplicação. Para a maioria das implementações, isto envolve resolver a versão secreta mais recente no nome do recurso da versão secreta completo e implementá-lo com a aplicação como um indicador ou num ficheiro de configuração. Recomendamos que resolva o nome da versão secreta no momento da rotação, armazene o nome do recurso num local duradouro (por exemplo, confirme no Git) e extraia o nome da versão para a configuração da implementação durante o envio para evitar implementações bloqueadas.

No arranque da aplicação, chame o Gestor Secreto com o nome da versão do segredo específico para aceder ao valor do segredo.

Esta abordagem tem as seguintes vantagens:

  • A sua aplicação usa a mesma versão secreta em todos os reinícios, o que aumenta a previsibilidade e reduz a complexidade operacional.

  • Os processos de gestão de alterações existentes para implementações e reversões podem ser reutilizados para a rotação de segredos e a implementação de versões de segredos.

  • O valor pode ser implementado gradualmente, reduzindo o impacto da implementação de valores incorretos.

Abordagem 2: resolva o problema no arranque da aplicação

Obtenha o payload secreto mais recente no início da aplicação e continue a usar o segredo durante a duração da aplicação.

A vantagem desta abordagem é que não requer a modificação do pipeline de CI/CD para resolver versões secretas, mas se for implementado um segredo incorreto, a aplicação não é iniciada quando as instâncias são reiniciadas ou o serviço é expandido, e pode resultar numa indisponibilidade do serviço.

Abordagem 3: resolva continuamente

Sondar continuamente a versão secreta mais recente na aplicação e usar o novo valor secreto imediatamente.

Esta abordagem acarreta o risco de uma interrupção imediata ao nível do serviço, uma vez que não existe uma adoção gradual do novo valor secreto.

Rode o seu segredo

Se o seu segredo puder ser atualizado dinamicamente (por exemplo, se o sistema externo que valida o segredo fornecer uma API Admin), recomendamos que configure uma tarefa de rotação que seja executada periodicamente. Os passos gerais estão descritos na secção seguinte, com o Cloud Run como um ambiente de computação de exemplo.

Configure um horário de rotação no seu segredo

Configure um horário de rotação para o seu segredo. Os tópicos do Pub/Sub têm de ser configurados no segredo para receber notificações quando for altura de rodar o segredo. Consulte o guia Notificações de eventos para configurar tópicos nos seus segredos.

Inicie o Cloud Run para criar uma nova versão do secret

Crie e configure um serviço do Cloud Run para receber notificações de rotação e executar passos de rotação:

  1. Obtenha ou crie um novo segredo no sistema externo (por exemplo, base de dados, fornecedor de API).

    Certifique-se de que não invalida os segredos existentes para que as cargas de trabalho existentes não sejam afetadas.

  2. Atualize o Secret Manager com a nova chave secreta.

    Crie uma nova versão do segredo no Secret Manager. Esta ação também atualiza o alias latest para apontar para o segredo criado recentemente.

Voltas a tentar e simultaneidade

Uma vez que o processo de rotação pode ser terminado em qualquer altura, o seu serviço do Cloud Run tem de conseguir reiniciar o processo a partir do ponto em que foi interrompido (tem de ser reentrante).

Recomendamos que configure as novas tentativas para que as rotações com falhas ou interrompidas possam ser executadas novamente. Além disso, configure a concorrência máxima e o número máximo de instâncias no seu serviço do Cloud Run para minimizar a probabilidade de as execuções de rotação simultâneas interferirem umas com as outras.

Para criar uma função de rotação reentrante, pode ser útil guardar o estado para permitir que o processo de rotação seja retomado. Existem duas funcionalidades do Secret Manager que ajudam neste processo:

  • Use etiquetas em segredos para guardar o estado durante a rotação. Adicione uma etiqueta ao segredo para acompanhar o número da última versão adicionada com êxito durante o fluxo de trabalho de rotação (por exemplo, ROTATING_TO_NEW_VERSION_NUMBER=3). Assim que a rotação estiver concluída, remova a etiqueta de acompanhamento da rotação.

  • Use etags para verificar se outros processos não estão a modificar o segredo em simultâneo durante o fluxo de trabalho de rotação. Saiba mais sobre os etags de versões de Secrets e Secrets.

Autorizações da gestão de identidade e de acesso

O processo de rotação requer a autorização secretmanager.versions.add para adicionar uma nova versão secreta e pode requerer a autorização secretmanager.versions.access para ler a versão secreta anterior.

O processo de rotação requer a autorização secretmanager.versions.add para adicionar uma nova versão secreta e pode requerer a autorização secretmanager.versions.access para ler a versão secreta anterior.

A conta de serviço do Cloud Run predefinida tem a função de editor, que inclui autorização para adicionar, mas não para aceder a versões secretas. Para seguir o princípio do menor privilégio, recomendamos que não use a conta de serviço predefinida. Em alternativa, configure uma conta de serviço separada para o seu serviço do Cloud Run com as funções do Secret Manager concedidas conforme necessário (pode ser uma ou várias das seguintes):

  • roles/secretmanager.secretVersionAdder

  • roles/secretmanager.secretVersionManager

  • roles/secretmanager.secretAdmin

  • roles/secretmanager.secretAccessor

Implemente a nova versão do segredo nos cargas de trabalho

Agora que uma nova versão secreta válida foi registada no sistema externo e está armazenada no Secret Manager, implemente-a na sua aplicação. Esta implementação varia consoante a sua abordagem à associação secreta e, geralmente, não requer intervenção manual.

Limpe versões do Secret antigas

Assim que todas as aplicações forem alternadas para a versão secreta antiga, é possível limpá-la em segurança. O processo de limpeza depende do tipo de segredo, mas, geralmente:

  1. Certifique-se de que a nova versão do segredo foi totalmente implementada em todas as aplicações.

  2. Desative a versão secreta antiga no Secret Manager e verifique se as aplicações não são interrompidas (aguarde um período razoável para permitir que um humano intervenha se a desativação interromper um consumidor).

  3. Remova ou anule o registo da versão secreta antiga do sistema externo.

  4. Destrua a versão antiga do segredo no Secret Manager

O que se segue?