Sobre programações de rotação

Neste tópico, apresentamos o conceito de rotação de secrets. Antes de começar, recomendamos que você consulte a Visão geral da plataforma para entender o cenário geral do Google Cloud. Recomendamos também que você leia a visão geral do produto Secret Manager.

Introdução

A rotação periódica ajuda a:

• Limite o impacto em caso de chave secreta vazada.
• Garanta que as pessoas que não precisam mais de acesso a um secret não consigam usar valores antigos.
• Exercite o fluxo de rotação continuamente para reduzir a probabilidade de uma interrupção em caso de rotação de emergência.

O Gerenciador de secrets tem um conceito de Secrets, Versões do secret eProgramações de rotação, que fornecem uma base para a criação de cargas de trabalho compatíveis com chaves secretas rotacionadas.

Este tópico fornece recomendações para alternar secrets armazenados no Secret Manager. As próximas seções exploram os benefícios e as vantagens de:

• Métodos para vincular uma versão do secret ao seu aplicativo.
• Abordagens rotativas de secrets.

Vinculação a uma versão do secret

Um secret no Secret Manager pode ter várias versões do secret. As versões do secret contêm o payload imutável (a string de byte do secret real) e são ordenados e numerados. Para fazer isso, adicione uma nova versão de secret a um secret existente.

A versão da chave secreta adicionada mais recentemente pode ser referenciada usando o alias latest. O alias latest, embora conveniente para desenvolvimento, pode ser problemático para algumas cargas de trabalho de produção, já que um valor inválido pode ser implantado imediatamente e resultar em uma interrupção em todo o serviço. Os métodos alternativos para vincular a uma versão do secret são descritos nos cenários a seguir.

Lançamentos graduais

Os lançamentos graduais são um princípio orientador para os cenários a seguir. Ao escolher um lançamento de secret mais lento, há um risco menor de interrupção, mas também um tempo de recuperação mais lento. Alguns secrets podem ser invalidados em sistemas externos, como APIs ou bancos de dados que rastreiam valores válidos de secrets, que podem ou não estar sob seu controle e sua recuperação nesses casos requer um lançamento.

É possível que uma senha secreta seja implantada durante a rotação manual ou automática. Um fluxo de trabalho de rotação forte precisa detectar automaticamente a interrupção (taxas de erro HTTP, por exemplo) e reverter para usar a versão do secret mais antigo (por meio de uma implantação de configuração anterior).

O lançamento da nova versão do secret depende de como eles estão vinculados ao aplicativo.

Abordagem 1: resolver durante um processo de versão existente

Resolva e vincule sua versão do secret à versão do aplicativo. Para a maioria das implantações, isso envolve resolver a versão secreta mais recente no nome completo do recurso da versão secreta e implantá-la com o aplicativo como uma sinalização ou em um arquivo de configuração. Recomendamos resolver o nome da versão do secret no momento da rotação, armazenar o nome do recurso em algum lugar durável (por exemplo, confirmar no Git) e puxar o nome da versão para a configuração de implantação durante o envio para evitar o bloqueio implantações.

Na inicialização do aplicativo, chame o Secret Manager com o nome da versão específica do secret para acessar o valor do secret.

Essa abordagem tem os seguintes benefícios:

• O aplicativo usa a mesma versão de secret nas reinicializações, aumentando a previsibilidade e reduzindo a complexidade operacional.
• Os processos de gestão da mudança existentes para lançamentos e reversões podem ser reutilizados para rotação de secrets e implantação de versões de secrets.
• O valor pode ser lançado gradualmente, reduzindo o impacto da implantação de valores inválidos.

Observação: resolver a versão mais recente na implantação poderá bloquear as implantações, se houver uma versão secreta inválida na última. Resolver problemas na implantação pode ser menos isolado ou reproduzível, já que o sucesso do lançamento depende do estado da versão do secret no Gerenciador de secrets. Se a versão do secret anterior estiver funcionando, crie uma nova versão do secret com o mesmo valor e aguarde o lançamento. Essencialmente, isso é um "avanço" e requer a permissão secretmanager.versions.access no secret para copiar o valor da versão antiga para a nova.

Abordagem 2: resolver na inicialização do aplicativo

Busque o payload da chave secreta mais recente na inicialização do aplicativo e continue usando-o durante a execução.

A vantagem dessa abordagem é que ela não exige a modificação do pipeline de CI/CD para resolver versões do secret, mas se um secret inválido for implantado, o aplicativo não será iniciado conforme as instâncias forem reiniciadas ou o serviço for escalonado e pode causar cascata de interrupção do serviço.

Abordagem 3: resolver continuamente

Pesquise a versão do secret mais recente continuamente no aplicativo e use o novo valor do secret imediatamente.

Essa abordagem corre o risco de sofrer interrupções imediatas em todo o serviço, já que não há adoção gradual do novo valor do secret.

Mudar a senha

Se a chave secreta puder ser atualizada dinamicamente (por exemplo, se o sistema externo que valida a chave secreta fornece uma API Admin), recomendamos a configuração periódica de um job de rotação. Os passos gerais estão descritos na seção a seguir com o Cloud Run como um ambiente de computação de amostra.

Configure uma programação de rotação no seu Secret

Configure uma programação de rotação para seu secret. Os tópicos do Pub/Sub precisam ser configurados no secret para receber notificações quando for o momento de rotacionar o secret. Consulte o guia Notificações de eventos para configurar tópicos sobre seus secrets.

Iniciar um 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 etapas de rotação:

1. Consiga ou crie um novo secret no sistema externo (por exemplo, banco de dados ou provedor de API).

   Verifique se isso não invalida os secrets atuais para que as cargas de trabalho existentes não sejam afetadas.

2. Atualize o Secret Manager com o novo secret.

   Crie um novo SecretVersion no Secret Manager. Isso também atualizará o alias latest para apontar para o secret recém-criado.

Novas tentativas e simultaneidade

Como o processo de rotação pode ser encerrado a qualquer momento, o serviço do Cloud Run precisa ser capaz de reiniciar o processo de onde parou (precisa ser reentrante).

Recomendamos configurar novas tentativas no Pub/Sub para que as rotações com falha ou interrompidas possam ser executadas novamente. Além disso, configure a simultaneidade máxima e as instâncias máximas no serviço do Cloud Run para minimizar a probabilidade de execuções de rotação simultâneas interferirem umas com as outras.

Para criar uma função de rotação reentrante, pode ser útil salvar o estado para permitir que o processo de rotação seja retomado. Há dois recursos do Gerenciador de secrets que ajudam nisso:

• Use rótulos nos secrets para salvar o estado durante a rotação. Adicione um rótulo ao secret ao rastrear o número da última versão adicionada com sucesso durante o fluxo de trabalho de rotação (por exemplo, ROTATING_TO_NEW_VERSION_NUMBER=3). Depois que a rotação for concluída, remova o rótulo de acompanhamento de rotação.
• Use ETags para verificar se outros processos não estão modificando o secret simultaneamente durante o fluxo de trabalho de rotação. Saiba mais sobre ETags de versão secreta e secreta.

Observação: as ETags para secrets e versões de secrets são independentes entre si. Em outras palavras, adicionar uma nova versão não modifica a ETag do secret pai.

Permissões de gerenciamento de identidade e acesso

O processo de rotação exigirá a permissão secretmanager.versions.add para adicionar uma nova versão do secret e poderá exigir que secretmanager.versions.access leia a versão anterior.

A conta de serviço padrão do Cloud Run tem o papel Editor, que inclui permissão para adicionar, mas não acessar versões do secret. Para seguir o princípio de privilégio mínimo, recomendamosNOT usando a conta de serviço padrão. Em vez disso, configure uma conta de serviço separada para o serviço do Cloud Run com os papéis do Secret Manager concedidos, podendo ser um ou vários. de:

• roles/secretmanager.secretVersionAdder
• roles/secretmanager.secretVersionManager
• roles/secretmanager.secretAdmin
• roles/secretmanager.secretAccessor

Implantar o novo SecretVersion nas cargas de trabalho

Agora que um novo SecretVersion válido foi registrado no sistema externo e está armazenado no Secret Manager, implemente-o no aplicativo. Esse lançamento varia com base na sua abordagem de vinculação de secret (consulte a seção Vinculação a uma versão de secret) e geralmente não requer intervenção manual.

Limpar versões antigas de secret

Depois que todos os aplicativos são substituídos pela versão do secret antigo, é possível apagá-lo com segurança. O processo de limpeza depende do tipo de secret, mas geralmente:

1. Verifique se a nova versão do secret foi lançada para todos os aplicativos.
2. Desative a versão antiga do secret no Gerenciador de secrets e verifique se os aplicativos não são interrompidos (aguarde um tempo razoável para permitir que uma pessoa intervenha se a desativação interromper um consumidor).
3. Remova ou cancele a inscrição da versão de secret antiga no sistema externo.
4. Destrua a versão antiga do secret no Gerenciador de secrets.

A seguir

• Saiba como configurar programações de rotação para secrets.