Práticas recomendadas para o Gerenciador de secrets

Este guia apresenta algumas práticas recomendadas ao usar o Secret Manager. O guia não é uma lista completa de recomendações. Recomendamos consultar a Visão geral da plataforma para entender o panorama geral do Google Cloud e a visão geral conceitual do Gerenciador de secrets antes de ler este guia.

Access Control

O acesso à API Secret Manager é protegido pelo IAM. Siga o princípio do menor privilégio ao conceder permissões a secrets.

As credenciais são necessárias para a autenticação na API Secret Manager. Todas as bibliotecas de cliente usam uma estratégia semelhante para procurar credenciais chamadas de Application Default Credentials.

Todos esses métodos são preferenciais para exportar uma credencial da conta de serviço, porque não exigem armazenamento e acesso seguros a um secret extra fora da API Secret Manager.

Práticas de programação

Passar secrets para seu aplicativo por meio das variáveis de sistema de arquivos ou ambiente é comum, mas deve ser evitado quando possível:

  • Quando um secret é acessível no sistema de arquivos, as vulnerabilidades do aplicativo, como ataques de transferência de diretórios, podem se tornar de maior gravidade, já que o invasor pode ler o material secreto.
  • Quando um secret é consumido por meio de variáveis de ambiente, configurações incorretas, como ativar endpoints de depuração ou incluir dependências que registram detalhes do ambiente de processo, podem vazar secrets.
  • Ao sincronizar o material secreto com outro armazenamento de dados (como secrets do Kubernetes), considere os controles de acesso desse armazenamento de dados, por exemplo:
    • O armazenamento de dados expande o acesso do secret?
    • É possível fazer auditoria do acesso ao secret?
    • O armazenamento de dados atende aos requisitos de criptografia e regionalização de dados em repouso?

Por esses motivos, quando possível, recomendamos usar a API Secret Manager diretamente (usando um dosBibliotecas de cliente ou seguindo a REST ou GRPC..

Administração

Escolha a política de replicação automática ao criar secrets, a menos que a carga de trabalho tenha requisitos de local específicos (aplicável usando a restrição constraints/gcp.resourceLocations).

Faça referência aos secrets pelo número da versão em vez de usar o alias mais recente. Implante atualizações para números de versão usando os processos de lançamento atuais. Normalmente, isso significa configurar seu aplicativo com uma versão do secret específica que é lida na inicialização. Embora o uso do alias mais recente possa ser conveniente, se houver um problema com a nova versão do secret, sua carga de trabalho poderá não ser usada da versão do secret. Ao fixar a um número de versão, a configuração pode ser validada e revertida usando os processos de lançamento existentes.

Desative as versões do secret antes de destruí-las ou excluí-las. Isso ajuda a evitar interrupções, colocando o secret em um estado que tem a mesma aparência que destruir, mas é reversível. Ou seja, é possível desativar e aguardar uma semana para garantir que não haja dependências restantes antes de excluir dados permanentemente.

Não defina a validade em chaves secretas de produção, a menos que você tenha certeza de que elas devem ser excluídas permanentemente. O recurso de expiração é mais adequado para a limpeza automatizada de ambientes temporários. Considere as condições do IAM baseadas em tempo como uma alternativa aos secrets expirados.

Alterne suas chaves secretas periodicamente para...

  • 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 possam continuar usando um secret acessado anteriormente.
  • Use o fluxo de rotação continuamente para reduzir a probabilidade de uma interrupção.

Monitore secrets em toda a organização usando o Inventário de recursos do Cloud para...

  • Ajude a identificar secrets em toda a organização.
  • Identifique a não conformidade com os requisitos da organização, como rotação, configuração de criptografia e local.

Ative os registros de acesso a dados para receber e analisar informações de solicitações AccessSecretVersion. Ative esse recurso no nível da pasta ou da organização para aplicar a geração de registros sem precisar configurá-lo em cada secret ou projeto.

Além dos controles do IAM, é possível limitar o acesso à API Secret Manager com controles baseados em rede configurando um perímetro do VPC Service Controls para sua organização.

A política da organização constraints/iam.allowedPolicyMemberDomains pode ser usada para limitar as identidades que podem ser adicionadas às políticas do IAM para secrets.

Estime o pico de uso do secret (considerando um "herdeiro de trovão") de solicitações devido a implantações de aplicativos ou escalonamento automático do serviço simultâneos e verifique se o projeto tem cota suficiente para lidar com tal evento. Se for necessário mais cota, solicite um aumento.