Este guia apresenta algumas práticas recomendadas ao usar o Secret Manager. O guia não é uma lista completa de recomendações. Recomendamos que você consulte a visão geral da plataforma para entender o cenário geral do Google Cloud e a visão geral do Secret Manager antes de ler este guia.
Controle de acesso
O acesso à API Secret Manager é protegido pelo IAM. Siga o princípio do menor privilégio ao conceder permissões a secrets.
- Limite a propriedade da organização a uma conta de superadministrador segura.
- Segmente aplicativos e ambientes (preparação/produção) em projetos separados, conforme descrito em Decidir uma hierarquia de recursos para a zona de destino do Google Cloud. Isso ajuda a isolar os ambientes com a vinculação do IAM no nível do projeto e garante que as cotas sejam aplicadas de maneira independente.
- Escolha um papel selecionado com as permissões mínimas necessárias ou crie um papel personalizado, se necessário.
- Quando os secrets de muitos serviços estiverem em um único projeto, use vinculações de IAM de nível secreto ou condições do IAM para limitar o acesso ao subconjunto necessário de }secretos.
- O recomendador do IAM pode ajudar ainda mais a identificar sobre vinculações privilegiadas do IAM.
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.
- Ao desenvolver localmente, use
gcloud auth application-default login. Isso cria um arquivo com credenciais que são selecionadas automaticamente pelas bibliotecas de cliente. - No Compute Engine e em outras plataformas de computação do Google Cloud, como o Cloud Functions, as bibliotecas de cliente recebem credenciais por meio do servidor de metadados da instância.
- No GKE, a identidade da carga de trabalho também fornece credenciais por meio de um serviço de metadados.
- Em outras plataformas, como a Amazon Web Services ou o Microsoft Azure, configure a federação de identidade da carga de trabalho, que usa mecanismos de identidade atuais para autenticar nas APIs do Google Cloud.
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
Transmitir secrets para o aplicativo por meio do sistema de arquivos ou de variáveis de ambiente é comum, mas precisa ser evitado quando possível pelos seguintes motivos:
- 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?
Recomendamos usar a API Secret Manager diretamente, usando uma das bibliotecas de cliente fornecidas ou seguindo a documentação REST ou GRPC.
No entanto, para algumas integrações de produtos, como integrações sem servidor, é possível transmitir secrets por meio do sistema de arquivos ou das variáveis de ambiente. Para mais informações, acesse Usar o Secret Manager com outros produtos.
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 parece igual a "destruir", mas que é reversível. Ou seja, é possível desativar e aguardar uma semana para ter certeza de que não há dependências remanescentes antes de excluir os dados permanentemente.
Não defina a expiration 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.
Faça a rotação dos secrets periodicamente para fazer o seguinte:
- 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 de secrets, considerando uma "trovoada" de solicitações devido a implantações simultâneas de aplicativos ou escalonamento automático do serviço, e garanta que seu projeto tenha cota suficiente para lidar com esse evento. Se for necessário mais cota, solicite um aumento.