Sobre a rotação de secrets

A rotação de secrets é o processo de atualizar ou substituir periodicamente informações sensíveis (secrets). como senhas, chaves de API ou de criptografia. A rotação de segredos ajuda a minimizar o risco de acesso não autorizado ou uso indevido de segredos, principalmente se eles foram comprometidos ou vazados.

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

  • Limita o impacto em caso de chave secreta vazada.

  • Garante que os indivíduos que não precisam mais de acesso a um secret não possam para usar valores de secret antigos.

  • Minimiza o risco de interrupções de serviço se você precisar alternar secrets com urgência.

Ele tem um conceito de secrets, versões de secret e programações de rotação, que oferecem uma para criar cargas de trabalho compatíveis com secrets rotacionados.

Esta página oferece recomendações para a rotação de secrets armazenados no Secret Manager. Você vai aprender a fazer o seguinte:

Antes de começar, recomendamos que você leia a visão geral da plataforma para entender o panorama geral do Google Cloud. Também recomendamos que você leia Visão geral do produto Secret Manager.

Vincular uma versão do secret ao seu aplicativo

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 de secrets válidos) que podem ou não e a recuperação nesses casos exige uma implementação.

É 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 do secret nas reinicializações, aumentando previsibilidade e reduzir a complexidade operacional.

  • Os processos de gestão de mudanças atuais para lançamentos e reversões podem ser reutilizados para rotação e implantação da versão do secret.

  • O valor pode ser lançado gradualmente, reduzindo o impacto da implantação de valores inválidos.

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 dos dados de CI/CD pipeline para resolver versões de secrets. No entanto, se um secret inválido for lançado, falha ao iniciar quando as instâncias são reiniciadas ou o serviço escalona verticalmente, podendo causar uma interrupção do serviço em cascata.

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.

Configurar uma programação de rotação no secret

configurar uma programação de rotação; para o 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, provedor de API).

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

  2. Atualize o Secret Manager com o novo secret.

    Crie uma nova versão do secret no Secret Manager. Isso também atualiza 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 para que as rotações com falha ou interrompidas possam ser executadas novamente. Além disso, configure simultaneidade máxima e número máximo de instâncias seu serviço do Cloud Run para minimizar a probabilidade de interferência de execuções de rotação simultâneas e se relacionam entre si.

Para criar uma função de rotação reentrante, talvez seja útil salvar 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 para rastrear 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). Quando 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.

Permissões de gerenciamento de identidade e acesso

O processo de rotação exige a permissão secretmanager.versions.add para adicionar uma nova versão do secret e pode exigir a permissão secretmanager.versions.access para ler a versão anterior.

O processo de rotação exige a permissão secretmanager.versions.add para adicionar uma nova versão do secret e pode exigir a permissão secretmanager.versions.access para ler a versão anterior.

A conta de serviço padrão do Cloud Run tem a função de editor, que inclui permissão para adicionar, mas não acessar versões do secret. Para seguir o princípio do menor privilégio, recomendamos não usar a conta de serviço padrão. Em vez disso, configurar uma conta de serviço separada; do serviço do Cloud Run com os papéis do Secret Manager concedidos conforme necessário (pode ser um ou vários deles):

  • roles/secretmanager.secretVersionAdder

  • roles/secretmanager.secretVersionManager

  • roles/secretmanager.secretAdmin

  • roles/secretmanager.secretAccessor

Implantar a nova versão do secret nas cargas de trabalho

Agora que uma nova versão válida do secret foi registrada no sistema externo e está armazenada no Secret Manager, implemente-a no aplicativo. Esse lançamento varia com base na sua abordagem de vinculaçã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 chave secreta, mas em geral:

  1. Verifique se a nova versão do secret foi totalmente lançada para todos aplicativos conteinerizados.

  2. Desative a versão antiga do secret no Secret Manager e verifique se aplicativos não falham (aguarde um tempo razoável para permitir que uma intervir se a desativação atrapalhar o 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 Secret Manager

A seguir