Melhores práticas para gerenciar segredos com HashiCorp Vault em CI/CD

Gerenciar segredos de forma segura é um aspecto crítico dos atuais pipelines CI/CD. Qualquer vazamento de chaves de API, credenciais de banco de dados ou tokens pode levar a violações de dados catastróficas, violações de conformidade e danos reputacionais. HashiCorp Vault fornece uma solução robusta, de nível empresarial para gerenciamento secreto, permitindo que as organizações protejam dados sensíveis durante todo o ciclo de vida de desenvolvimento e implantação. Ao adotar as melhores práticas para integração com Vault, as equipes podem minimizar a exposição, automatizar a rotação e impor controles de acesso rigorosos sem retardar a entrega.

Este guia descreve estratégias comprovadas para usar o HashiCorp Vault em ambientes CI/CD. Você aprenderá como aproveitar segredos dinâmicos, implementar políticas de fino enraizamento, criptografar dados em trânsito e em repouso, girar continuamente credenciais e monitorar todos os acessos secretos. Também cobrimos padrões de integração para as principais ferramentas CI/CD, como Jenkins, GitLab CI e GitHub Actions, juntamente com armadilhas comuns para evitar.

Aderir a essas práticas não só fortalecerá sua postura de segurança, como também simplificará os fluxos de trabalho operacionais, reduzirá a sobrecarga manual e ajudará a satisfazer requisitos regulatórios como SOC 2, PCI DSS e HIPAA.

Compreender o Cofre HashiCorp em IC/CD

HashiCorp Vault é uma ferramenta projetada para armazenar e controlar com segurança o acesso a tokens, senhas, certificados e outros segredos. Nos fluxos de trabalho CI/CD, Vault pode gerar dinamicamente segredos, gerenciar o ciclo de vida secreto e impor políticas de acesso. Ao contrário dos segredos estáticos codificados em arquivos de configuração ou variáveis de ambiente, Vault trata os segredos como recursos efêmeros criados sob demanda e automaticamente revogados após o uso.

O Vault integra-se com sistemas CI/CD através dos plug-ins de autenticação REST API, CLI e nativo. O padrão típico envolve:

  • Autenticação: O gasoduto CI/CD autentica-se em Vault utilizando um método seguro, como AppRole, Kubernetes auth, ou um token de curta duração injetado pela ferramenta CI.
  • Secret Retrieval: Durante uma fase de compilação ou implantação, o gasoduto solicita segredos de Vault — segredos estáticos de uma loja KV ou segredos dinâmicos de um banco de dados, nuvem ou motor PKI.
  • Usagem: Os segredos são temporariamente injetados em variáveis de ambiente, arquivos de configuração ou argumentos de comando, então usados para tarefas como conectar a um banco de dados, assinar artefatos ou implantar em um provedor de nuvem.
  • Limpeza: Após o uso, o gasoduto revoga credenciais temporárias ou variáveis de ambiente desativadas para reduzir a janela de exposição.

Esta abordagem elimina a necessidade de armazenar segredos em repositórios Git, arquivos de configuração CI/CD ou registros de artefatos, reduzindo drasticamente a superfície de ataque.

Princípios Principais de Gestão Secreta com Cofre

1. Use segredos dinâmicos

Segredos estáticos — como uma senha de banco de dados usada por anos — são uma responsabilidade de segurança. Se comprometidos, eles concedem acesso persistente até rodar manualmente. Os motores secretos dinâmicos do Vault criam credenciais em tempo real com valores curtos de tempo para viver (TTL). Por exemplo, o Vault pode gerar uma senha única e limitada por tempo para um usuário do PostgreSQL ou uma chave de acesso IAM para um papel AWS.

Segredos dinâmicos oferecem várias vantagens:

  • Tempo de vida mais curto: Segredos expiram automaticamente, muitas vezes em minutos ou horas.
  • Por sessão única: Cada execução de pipeline recebe credenciais distintas, tornando impossível reutilizar um segredo comprometido de uma compilação anterior.
  • Revogação automática: Vault pode revogar segredos dinâmicos imediatamente após o término do gasoduto, ou quando o TTL expira.

Para implementar segredos dinâmicos, configure um mecanismo secreto (por exemplo, banco de dados, AWS, Azure) com um papel definido e TTL padrão. Seu pipeline então solicita uma locação para esse papel e usa as credenciais devolvidas apenas durante a duração do trabalho.

2. Implementar o controle de acesso fino-grained

As políticas de vault são escritas em HCL (HashiCorp Configuration Language) e seguem um modelo de permissões baseado em caminhos. Cada política concede ou nega acesso a caminhos e capacidades secretos específicos (leia, cria, actualiza, apaga, lista, sudo). O princípio do menor privilégio deve guiar cada definição de políticas.

Considere estas orientações:

  • Políticas baseadas em roles: Criar políticas separadas para pipelines de desenvolvimento, encenação e produção. Um trabalho de CI que constrói um ramo de recursos nunca deve ter acesso aos segredos de produção.
  • Restrições de trajeto: Limite o acesso apenas aos caminhos secretos exatos necessários. Por exemplo, uma política de banco de dados pode permitir em mas negar tudo o mais.
  • Acesso ligado ao tempo: Combine políticas com TTLs token e limites de renovação.Mesmo que o token de um pipeline seja roubado, sua janela de validade é limitada.
  • Use identidades: Leverage Vault Identity Entidades e Grupos para anexar políticas a ferramentas, trabalhos ou contas de serviços específicos do CI/CD.

Exemplo de política mínima para um gasoduto CI:

path "database/creds/ci-app" {
 capabilities = ["read", "list"]
}

path "secret/data/ci/*" {
 capabilities = ["read", "list"]
}

path "auth/token/lookup-self" {
 capabilities = ["read"]
}

3. Criptografar segredos em repouso e em trânsito

O Vault criptografa automaticamente todos os dados armazenados em sua infraestrutura usando uma chave- mestre. Esta chave é criptografada e pode ser gerenciada com um serviço de gerenciamento de chaves externa (KMS) ou um módulo de segurança de hardware (HSM). No entanto, a criptografia em trânsito é igualmente importante. Toda a comunicação entre agentes CI/CD e Vault deve usar TLS 1.2 ou superior.

Melhores práticas:

  • Ativar TLS: Configurar servidor Vault com um certificado válido de uma CA confiável ou de um PKI interno.
  • Verifique certificados: Os clientes CI/CD devem verificar a cadeia de certificados do servidor Vault. Forneça o certificado CA como parte do armazenamento de confiança da ferramenta.
  • Use TLS mútuos quando possível: Para segurança extra, exija certificados de cliente de sistemas CI/CD.
  • Evite o texto simples sobre a rede: Nunca obtenha segredos sobre conexões HTTP ou não criptografadas. A maioria dos agentes CI/CD suporta variáveis de ambiente que podem injetar o endereço do Vault e token de forma segura.

4. Automatizar a rotação secreta

A rotação regular reduz os danos de um segredo vazado. Os segredos dinâmicos do Vault são girados automaticamente com cada solicitação de locação, mas os segredos estáticos nas lojas KV também precisam de rotação. HashiCorp recomenda usar os mecanismos de rotação ] e ] de Vault[ juntamente com políticas periódicas para forçar a rotação no nível da aplicação.

Para automatizar a rotação de segredos estáticos:

  • Guarda segredos estáticos no motor KV v2 do Vault, que suporta operações de versionamento e verificação e ajuste.
  • Escreva uma tarefa agendada (cron, Nomad batelada periódica, ou pipeline CI) que gera novos valores e escreve-os para Vault.
  • Atualizar quaisquer sistemas dependentes (bases de dados, gateways API) com o novo segredo através do ecossistema de plugins ou scripts externos do Vault.
  • Use o ponto final de Vault para girar a chave de criptografia raiz em intervalos regulares.

5. Auditoria e Monitoramento de Acesso

O Vault regista todas as solicitações autenticadas nos seus dispositivos de auditoria. Você pode enviar registos de auditoria para ficheiros, syslog ou serviços externos como a Elasticsearch, o Splunk ou o Datadog. Os registos de auditoria contêm o IP do cliente, o método de autenticação, o caminho da solicitação, os dados de resposta (se permitidos) e quaisquer erros.

Práticas-chave de monitorização:

  • Habilitar registro de auditoria: Configurar pelo menos um dispositivo de auditoria. Use um destino seguro, somente para apêndices, para evitar adulteração.
  • Set up alertas: Criar alertas para tentativas de autenticação falhadas, acesso a caminhos sensíveis (por exemplo, credenciais de banco de dados de produção), ou cancelamentos de locação.
  • Reveja regularmente: Teste periodicamente os padrões de utilização e acesso das políticas de auditoria. Remova políticas ou caminhos não utilizados.
  • Use o ponto final de do Vault: Para transmissão em tempo real de entradas de log, útil para depuração durante as execuções CI/CD.

Integrando o Cofre em Pipelines CI/CD

Métodos de autenticação para o CI/CD

Escolher o método de autenticação certo é crucial para segurança e facilidade de uso. Os métodos comuns incluem:

  • AppRole: Recomendado para autenticação máquina-máquina. Um serviço CI/CD cria uma função Vault com uma e . O gasoduto autentica-se apresentando ambos, recebendo um token de cliente de curta duração.
  • Kubernetes Auth: Ideal para pipelines em execução em Kubernetes. Vault valida o token da conta de serviço Kubernetes através do servidor de API Kubernetes e emite um token Vault baseado nas políticas da conta de serviço.
  • AWS/GCP/Azure Auth: Para pipelines em execução em provedores de nuvem, Vault pode verificar os metadados de instância ou o papel IAM para emitir tokens sem chaves codificadas.
  • Baseado em Token: Para configurações simples, uma ferramenta CI/CD como Jenkins pode injetar um token Vault como uma variável secreta. Esta abordagem é menos segura e só deve ser usada com tokens de vida muito curta.

Sempre prefira autenticação dinâmica e ligada sobre tokens estáticos. Configure o token TTLs para corresponder à duração máxima de execução do oleoduto (por exemplo, 30 minutos) e defina um número razoável de usos (se aplicável).

Integração com ferramentas específicas do CI/CD

[[FLT: 0]]Jenkins: Use o Plugin HashiCorp Vault. Configure um endereço do servidor Vault, método de autenticação (AppRole ou token), e defina pipelines que obtêm segredos através de passos [[FLT: 7]]. O plugin suporta codificação base64, injeção de arquivos e atribuição de variáveis de ambiente.

GitLab CI:] O GitLab CI suporta nativamente Vault através do token . Configure Vault para aceitar a autenticação JWT do emissor JWT do GitLab. Em , use o bloco para solicitar um token Vault e então recupere os segredos usando o Vault CLI ou API.

[[FLT: 0]]Ações do GitHub: Use a ação GitHub. Ele suporta autenticação do OIDC (recomendada), token, ou AppRole. Adicione um passo que mapeia os segredos para variáveis de ambiente ou os escreve para arquivos. Para o OIDC, configure Vault com um método de autenticação JWT confiável para emitir ] e vinculado a repositórios ou branches específicos.

CircleCI: Use o orbe de Vault ou chamadas diretas da API. O recurso de contexto do CircleCI pode armazenar um token de Vault, mas AppRole ou OIDC é preferido.

Fluxo de trabalho de amostra com AppRole em Jenkins

Considere um pipeline Jenkins que constrói uma imagem do Docker e a implementa em um cluster Kubernetes. Em vez de armazenar a senha de configuração e registro do Kubernetes no Jenkins, ele os busca do Vault em tempo de execução.

  1. Pré-configurar Vault: Criar uma política que permita o acesso de leitura a e . Criar uma função AppRole com essa política, um TTL de 10 minutos e um armazenado em Jenkins como credencial.
  2. [[FLT: 0]] Passo da Pipeline: Use o Plugin do Vault do HashiCorp com o ID de função do AppRole (também uma credencial) e o SecretID. O plugin autentica e obtém um token do Vault.
  3. Segredo de Busca:] Leia a senha do registro do Docker e o token do Kubernetes do Vault. O plugin escreve-os para variáveis temporárias de ambiente ou arquivos.
  4. Uso: Executar com as credenciais. Em seguida, executar com a configuração. Após o passo, o pipeline termina e o token Vault expira.
  5. Limpeza: Opcionalmente, revogar o SecretID da AppRole se não for desejada uma reutilização.

Considerações Avançadas

Motores secretos e seus casos de uso

O cofre suporta muitos motores secretos. Para CI/CD, os mais relevantes são:

  • KV v2 (Key-Value): Guarda segredos estáticos como chaves, certificados ou configurações específicas do ambiente. Active a versão para reverter as alterações.
  • Database: Gerar usuários de banco de dados temporários com credenciais dinâmicas para MySQL, PostgreSQL, MongoDB, e outros.
  • Providers em nuvem (AWS, Azure, GCP): Gerar funções temporárias de IAM, princípios de serviço ou chaves de armazenamento de contas.
  • PKI: Emitir certificados TLS de curta duração para mTLS entre microserviços ou para registos de contentores.
  • Trânsito: Encriptar/descriptografar dados sem armazená-los — útil para criptografar artefatos antes de armazená-los em um repositório.

Melhores práticas de concepção de políticas

Políticas de design com uma convenção de nomenclatura clara e estrutura hierárquica. Por exemplo:

  • – para os segredos específicos da IC.
  • – para encenar segredos ambientais.
  • – para segredos de produção (com acesso muito restrito).

Evite usar caminhos wildcards muito amplamente. Em vez disso, conceda acesso a caminhos secretos específicos. Use as regras ]deny com moderação; a negação por omissão do Vault é suficiente. Combinações de e devem ser testadas antes de implantar para a produção. O comando Vault CLI é útil para validação.

Backup e Recuperação de Desastres

A infraestrutura de armazenamento do Vault (cônsul, jangada, arquivo, etc.) deve ser backup regularmente. Se usar o armazenamento integrado (Raft), habilite backups de instantâneo. Para pipelines CI/CD que dependem do Vault para todos os segredos, uma falha do Vault irá quebrar as implementações. Mitigar isso por:

  • Correndo Vault em uma configuração altamente disponível (HA) com pelo menos três nós.
  • Armazenar um conjunto de segredos em uma loja criptografada alternativa (por exemplo, AWS Secrets Manager) com um TTL curto — mas tratá-lo como um último recurso.
  • Teste procedimentos de recuperação de desastres regularmente, incluindo a restauração de um instantâneo.

Pistácios comuns a evitar

  • Codificação difícil de um Cofre Token em variáveis CI/CD: Mesmo que o token seja armazenado como uma variável secreta, ele pode ser vazado através de registros de compilação ou artefatos. Use autenticação dinâmica (AppRole, OIDC) para que o token seja gerado para cada execução e nunca persista.
  • Usando o Token Raiz em Pipelines: O token de raiz deve ser usado apenas para inicialização e emergências. Todos os pipelines devem usar tokens de escopo limitado com políticas apropriadas.
  • [[FLT: 0]] Não Definir TTLs Curtos: Um gasoduto de CI normalmente funciona por minutos, não por horas. Defina TTLs token para a duração esperada do trabalho mais um pequeno buffer. Tokens de longa duração aumentam o risco.
  • Ignorando os Registros de Auditoria: Sem monitoramento de auditoria, você perde indicadores de compromisso ou políticas mal configuradas. Configure alertas para qualquer acesso a segredos altamente sensíveis.
  • Storing Secrets in Pipeline Outputs: Nunca imprima segredos para console, arquivos de registro ou construir artefatos. Use injeção baseada em arquivos ou remova o segredo das variáveis de ambiente imediatamente após o uso.
  • Esquecendo-se de Rever as Leases:] Os segredos dinâmicos permanecem válidos até que o contrato de locação expire ou seja revogado. Explicávelmente, revogue as locações nas etapas pós-construção ou limpeza do seu oleoduto ().

Conclusão

Integrar o HashiCorp Vault em seus pipelines CI/CD elimina a fonte mais perigosa de vazamentos secretos: credenciais estáticas codificadas ou armazenadas no ambiente. Seguindo as melhores práticas aqui descritas — segredos dinâmicos, controle de acesso de grãos finos, criptografia, rotação automatizada e auditoria abrangente — você pode alcançar um fluxo de trabalho de gerenciamento secreto robusto e pronto para a produção.

Comece pequeno: adote a autenticação do AppRole para um pipeline, busque uma credencial dinâmica de banco de dados e monitore os registros de auditoria. Expanda gradualmente para cobrir todos os pipelines e tipos secretos. Com o Vault, segurança e velocidade, vá de mãos dadas, garantindo que suas saídas CI/CD sejam seguras e confiáveis.

Recursos adicionais: