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 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 (preparo/produção) em projetos separados, conforme descrito em Decidir uma hierarquia de recursos para sua zona de destino do Google Cloud. Isso pode ajudar a isolar 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 Run, as bibliotecas de cliente recebem credenciais pelo 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
Passar segredos para seu aplicativo pelo sistema de arquivos ou pelas variáveis de ambiente é comum, mas deve ser evitado quando possível devido aos 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 ou seguindo a documentação do REST ou do GRPC).
No entanto, para algumas integrações de produtos, como integrações sem servidor, é possível transmitir segredos pelo sistema de arquivos ou pelas variáveis de ambiente. Para mais informações, consulte 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 excluir segredos. 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 periodicamente suas chaves secretas 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.
Faça uma estimativa do uso máximo do segredo, considerando um "rebanho de trovões" de solicitações devido a implantações de aplicativos simultâneas ou escalonamento automático do serviço e verifique se o projeto tem cota suficiente para processar esse evento. Se for necessário mais cota, solicite um aumento.