Mejores prácticas para gestionar secretos con HashiCorp Vault en CI/CD

Gestionar secretos de forma segura es un aspecto crítico de los modernos oleoductos CI/CD. Cualquier filtración de claves de API, credenciales de bases de datos o fichas puede llevar a violaciones catastróficas de datos, violaciones de cumplimiento y daños de reputación. HashiCorp Vault proporciona una solución robusta y de calidad empresarial para la gestión secreta, permitiendo a las organizaciones proteger datos sensibles durante todo el desarrollo y el ciclo de vida de despliegue.

Esta guía describe estrategias probadas para usar HashiCorp Vault en entornos CI/CD. Aprenderás a aprovechar secretos dinámicos, implementar políticas finas, cifrar datos en tránsito y en reposo, rotar continuamente credenciales y monitorear todo acceso secreto. También cubrimos patrones de integración para las principales herramientas de CI/CD como Jenkins, GitLab CI y GitHub Actions, junto con trampas comunes para evitar.

Adherirse a estas prácticas no sólo fortalecerá su postura de seguridad sino también racionalizará los flujos de trabajo operativos, reducirá la sobrecarga manual y ayudará a satisfacer requisitos regulatorios como SOC 2, PCI DSS y HIPAA.

Comprensión de HashiCorp Vault en CI/CD

HashiCorp Vault es una herramienta diseñada para almacenar y controlar de forma segura el acceso a fichas, contraseñas, certificados y otros secretos. En los flujos de trabajo CI/CD, Vault puede generar secretos dinámicamente, gestionar ciclo de vida secreto y aplicar políticas de acceso. A diferencia de secretos estáticos codificados en archivos de configuración o variables ambientales, Vault trata secretos como recursos efímeros creados a pedido y automáticamente revocados.

Vault se integra con sistemas CI/CD a través de sus plugins de API, CLI y autenticación nativa. El patrón típico implica:

  • Autorización: El oleoducto CI/CD autentica a Vault utilizando un método seguro como AppRole, Kubernetes auth, o una token de corta duración inyectada por la herramienta CI.
  • Retrieval secreto: Durante una etapa de construcción o despliegue, el gasoducto solicita secretos de Vault, ya sea secretos estáticos de una tienda KV o secretos dinámicos de una base de datos, nube o motor PKI.
  • Usage: Los secretos se inyectan temporalmente en variables ambientales, archivos de configuración o argumentos de comando, y luego se utilizan para tareas como conectarse a una base de datos, firmar artefactos o desplegarse en un proveedor de nube.
  • Cleanup: Después de su uso, el gasoducto revoca credenciales temporales o variables de entorno sin par para reducir la ventana de exposición.

Este enfoque elimina la necesidad de almacenar secretos en los repositorios Git, archivos de configuración CI/CD o registros de artefactos, reduciendo drásticamente la superficie de ataque.

Principios básicos de gestión secreta con Vault

1. Use Secretos Dinámicos

Los secretos estaticos —como una contraseña de base de datos única utilizada durante años— son una responsabilidad de seguridad. Si se comprometen, conceden acceso persistente hasta que se rota manualmente. Los motores secretos dinámicos de Vault crean credenciales en la marcha con valores cortos de tiempo a vida (TTL). Por ejemplo, Vault puede generar una contraseña única y limitada para un usuario de PostgreSQL o una clave de acceso IAM para un rol de AWS.

Los secretos dinámicos ofrecen varias ventajas:

  • Short lifespan: Los secretos caducan automáticamente, a menudo en minutos o horas.
  • Exclusividad por sesión: Cada trama de tuberías obtiene credenciales distintas, lo que hace imposible reutilizar un secreto comprometido de una construcción anterior.
  • Revocación automática: Vault puede revocar secretos dinámicos inmediatamente después de que el oleoducto termine, o cuando el TTL expire.

Para implementar secretos dinámicos, configura un motor secreto (por ejemplo, base de datos, AWS, Azure) con un papel definido y TTL predeterminado. Su oleoducto solicita un contrato de arrendamiento para ese papel y utiliza las credenciales devueltas sólo durante la duración del trabajo.

2. Implementar el control de acceso de gran calidad

Las políticas de Vault están escritas en HCL (HashiCorp Configuration Language) y siguen un modelo de permisos basados en caminos. Cada política otorga o niega el acceso a caminos y capacidades secretos específicos (leer, crear, actualizar, eliminar, lista, sudo). El principio de menos privilegios debe guiar cada definición de política.

Considerar estas directrices:

  • Políticas basadas en la red: Crear políticas separadas para el desarrollo, el estadificación y los oleoductos de producción. Un trabajo de CI construir una rama de características nunca debe tener acceso a secretos de producción.
  • Restricciones de los padres: Limitar el acceso a los caminos secretos exactos necesarios. Por ejemplo, una política de bases de datos podría permitir en pero negar todo lo demás.
  • Acceso con plazos: Combina las políticas con TTLs token y los límites de renovación. Incluso si se roba una señal de oleoducto, su ventana de validez es limitada.
  • Use Identidades: Leverage Vault Identity Entities and Groups to attach policies to specific CI/CD tools, jobs, or service accounts.

Ejemplo de política mínima para un oleoducto de CI:

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

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

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

3. Cifrar secretos en el descanso y en el tránsito

Vault cifra automáticamente todos los datos almacenados en su backend utilizando una llave maestra. Esta clave es encriptada y puede ser gestionada con un servicio de gestión de clave externa (KMS) o un módulo de seguridad de hardware (HSM). Sin embargo, la cifrado en tránsito es igualmente importante. Toda la comunicación entre los agentes de CI/CD y Vault debe utilizar TLS 1.2 o superior.

Buenas prácticas:

  • Activar TLS: Configure Vault server with a valid certificate from a reliable CA or an internal PKI.
  • Verificar certificados: Los clientes de CI/CD deben verificar la cadena de certificados del servidor Vault. Proporcionar el certificado CA como parte de la tienda de confianza de la herramienta.
  • Utilizar TLS mutuo cuando sea posible: Para mayor seguridad, requiere certificados de cliente de sistemas CI/CD.
  • Evitar el texto plano sobre la red: Nunca se traduzcan secretos sobre HTTP o conexiones no cifradas. La mayoría de los agentes de CI/CD soportan variables ambientales que pueden inyectar la dirección Vault y de forma segura.

4. Automatizar la rotación secreta

La rotación regular reduce el daño de un secreto filtrado. Los secretos dinámicos de Vault se rotan automáticamente con cada solicitud de arrendamiento, pero los secretos estáticos en las tiendas de KV también necesitan rotación. HashiCorp recomienda usar los mecanismos de rotación ] y ]] []] junto con las políticas periódicas para hacer cumplir la rotación a nivel de aplicación.

Automatizar la rotación de secretos estáticos:

  • Almacene secretos estáticos en el motor KV v2 de Vault, que soporta las operaciones de versión y check-and-set.
  • Escribe un trabajo programado (cron, nómada, o tubería de CI) que genera nuevos valores y los escribe a Vault.
  • Actualizar cualquier sistema dependiente (databases, API gateways) con el nuevo secreto a través del ecosistema de plugin de Vault o scripts externos.
  • Use el punto final de Vault para rotar la tecla de encriptación de raíz a intervalos regulares.

5. Auditoría y acceso a los monitores

Los registros de auditoría pueden enviar registros de auditoría a archivos, syslog o servicios externos como Elasticsearch, Splunk o Datadog. Los registros de auditoría contienen el IP cliente, método de autenticación, ruta de solicitud, datos de respuesta (si está permitido) y cualquier error.

Prácticas clave de vigilancia:

  • Activar la registro de auditoría: Configure al menos un dispositivo de auditoría. Utilice un destino seguro y exclusivo para evitar la manipulación.
  • ]Contar alertas: Crear alertas para intentos fallidos de autenticación, acceso a caminos sensibles (por ejemplo, credenciales de la base de datos de producción), o revocaciones de arrendamiento.
  • Revisión periódica:] Auditoría periódica de las pautas de uso y acceso de las políticas.
  • Use el punto final de Vault : Para la transmisión en tiempo real de las entradas de registro, útil para depurar durante las carreras de CI/CD.

Integrando la Vault en las tuberías CI/CD

Métodos de autenticación para CI/CD

Elegir el método de autenticación adecuado es crucial para la seguridad y la facilidad de uso.

  • ]AppRole:] Recomendado para la autenticación de máquina a máquina. Un servicio CI/CD crea un rol Vault con un y . El gasoducto autentica presentando ambos, recibiendo un token de cliente de corta duración.
  • Kubernetes Auth: Ideal para tuberías que funcionan en Kubernetes. Vault valida el token de la cuenta de servicio Kubernetes a través del servidor de Kubernetes API y emite un token Vault basado en las políticas de la cuenta de servicio.
  • AWS/GCP/Azure Auth: Para los oleoductos que funcionan en proveedores de nube, Vault puede verificar el papel de metadatos de instancia o IAM para emitir fichas sin claves codificadas.
  • Basado en Token: Para configuraciones simples, una herramienta CI/CD como Jenkins puede inyectar una ficha Vault como una variable secreta. Este enfoque es menos seguro y sólo debe ser utilizado con fichas de muy poco tiempo.

Siempre prefieren la autenticación dinámica y atada sobre fichas estáticas. Configurar TTLs token para que coincida con la duración máxima de la ejecución del oleoducto (por ejemplo, 30 minutos) y establecer un número razonable de usos (si es aplicable).

Integración con herramientas específicas de CI/CD

Jenkins:] Usa el plugin HashiCorp Vault. Configura una dirección servidor Vault, método de autenticación (AppRole o token) y define tuberías que capturan secretos a través de pasos. El plugin admite la codificación base64, la inyección de archivos y la asignación variable del entorno.

GitLab CI:] GitLab CI soporta nativamente Vault a través del token . Configurar Vault para aceptar la autenticación JWT del emisor JWT de GitLab. En , utilice el bloque para solicitar un token Vault y luego recuperar secretos usando API.

GitHub Actions: Utiliza la acción GitHub. Soporta la autenticación OIDC (recomendada), token o AppRole. Añade un paso que mapea secretos a variables ambientales o los escribe a archivos. Para OIDC, configura Vault con un método JWT auth confiado a emisor [F bound]

CircleCI: Utilizar el orb Vault o las llamadas directas de API. La función contextual de CircleCI puede almacenar un token Vault, pero AppRole o OIDC es preferido.

Afluencia de trabajo de muestra con AppRole en Jenkins

Considere un oleoducto Jenkins que construye una imagen Docker y la implementa a un grupo Kubernetes. En lugar de almacenar el config Kubernetes y contraseña de registro en Jenkins, los embravece desde Vault en tiempo de ejecución.

  1. Preconfigurar Vault: Crear una política que permita el acceso de lectura a y . Crear un rol de AppRole con esa política, un TTL de 10 minutos, y un almacenado en Jenkins como una credencial.
  2. Paso de la línea de la tubería: Usa el plugin HashiCorp Vault con el ID de rol de AppRole (también una credencial) y el SecretID. El plugin autentica y obtiene una ficha de Vault.
  3. Secretos de captura:] Lea la contraseña del registro de Docker y Kubernetes token de Vault. El plugin los escribe a variables o archivos temporales del entorno.
  4. Usage:] Corre con las credenciales. Luego corre con el config. Después del paso, el oleoducto termina y el token Vault expira.
  5. Cleanup:] Opcionalmente revocar el SecretID de AppRole si no se desea la reutilización.

Consideraciones avanzadas

Motores Secretos y sus Casos de Uso

Vault soporta muchos motores secretos. Para CI/CD, los más relevantes son:

  • KV v2 (Key-Value): Almacene secretos estáticos como claves de API, certificados o ajustes específicos del medio ambiente.
  • Database: Genera usuarios temporales de bases de datos con credenciales dinámicas para MySQL, PostgreSQL, MongoDB y otros.
  • Proveedores de voz (AWS, Azure, GCP):] Generan roles temporales de IAM, directores de servicio o claves de cuenta de almacenamiento.
  • PKI:] Emitir certificados TLS de corta duración para mTLS entre microservicios o para registros de contenedores.
  • Transit:] Encrypt/decrypt data without storing it — useful for encrypting artifacts before storing them in a repository.

Políticas Diseño Mejores Prácticas

Políticas de diseño con una convención clara de nominación y estructura jerárquica. Por ejemplo:

  • – para secretos específicos de CI.
  • – para el estancamiento de secretos ambientales.
  • – para secretos de producción (con acceso muy restringido).

Evite usar caminos de comodín demasiado ampliamente. En lugar de ello, dé acceso a caminos secretos específicos. Use de la rencor] reglas espaciosamente; la negación predeterminada de Vault es suficiente. Combinaciones de y ] deben ser probados antes de desplegarse en producción.

Reacción y recuperación de desastres

El backend de almacenamiento de Vault (consul, raft, file, etc.) debe ser respaldado regularmente. Si el uso de almacenamiento integrado (Raft), permite copias de seguridad instantáneas. Para los oleoductos CI/CD que dependen de Vault para todos los secretos, un outage Vault romperá las implementaciones.

  • Correr Vault en una configuración altamente disponible (HA) con al menos tres nodos.
  • Robar un conjunto de secretos en una tienda encriptada alternativa (por ejemplo, AWS Secrets Manager) con un TTL corto, pero tratar eso como un último recurso.
  • Pruebas de los procedimientos de recuperación de desastres regularmente, incluyendo la restauración de una instantánea.

Pitfalls comunes para evitar

  • Hardcoding a Vault Token in CI/CD Variables: Incluso si el token se almacena como una variable secreta, se puede filtrar a través de registros de construcción o artefactos. Use autenticación dinámica (AppRole, OIDC) para que el token se genere para cada carrera y nunca persista.
  • Usando la ficha de raíz en tuberías:] La ficha raíz debe utilizarse sólo para la inicialización y emergencias. Todos los oleoductos deben usar fichas de un solo paso con políticas apropiadas.
  • No Ajuste TTL corto: Un gasoducto CI suele funcionar durante minutos, no horas. Establece TTLs a la duración esperada del trabajo más un pequeño búfer. Las fichas de larga duración aumentan el riesgo.
  • Ignorar los registros de auditoría: Sin supervisión de auditoría, se pierden los indicadores de compromiso o políticas mal configuradas.
  • Guardar secretos en productos de tubería: Nunca imprimir secretos para consolar, archivar archivos o construir artefactos. Usar la inyección basada en archivos o eliminar el secreto de variables ambientales inmediatamente después de su uso.
  • Forgetting to Revoke Leases: Los secretos dinámicos siguen siendo válidos hasta que el contrato de arrendamiento expira o se revoca. Explicadamente revoca los arrendamientos en los pasos posteriores a la compra o limpieza de su oleoducto ().

Conclusión

Integrar HashiCorp Vault en sus tuberías CI/CD elimina la fuente más peligrosa de fugas secretas: credenciales estáticas de código duro o almacenadas en el medio ambiente. Siguiendo las mejores prácticas aquí descritas: secretos dinámicos, control de acceso fino, cifrado, rotación automatizada y auditoría completa, se puede lograr un flujo de trabajo de gestión secreta sólido y listo para la producción.

Comience pequeña: adoptar la autenticación de AppRole para un oleoducto, buscar una base de datos dinámica credencial y supervisar los registros de auditoría. Ampliar gradualmente para cubrir todos los oleoductos y tipos secretos. Con Vault, la seguridad y la velocidad van de la mano, asegurando que sus salidas CI/CD sean seguras y fiables.

Recursos adicionales: