Gestor de secretos de GitLab

Mayor precisión de los agentes, menor costo de tokens
Aprende a reforzar tu fábrica de software y a permitir que los agentes de IA se ganen autonomía sin sacrificar la seguridad.
Mantente al día con nuestras últimas funcionalidades y mejoras.
Acaba con la dispersión de secretos con el gestor de secretos de GitLab, basado en OpenBao. Los secretos de pipelines y de tiempo de ejecución se leen desde un único almacén, regido por los permisos y el registro de auditoría que ya protegen tu código.
Administra los secretos donde ya trabajan los equipos de desarrollo
Con el gestor de secretos de GitLab, los secretos se encuentran en los mismos grupos y proyectos que el código que los usa, por lo que solicitar uno forma parte del flujo de trabajo habitual, sin plugins, agentes ni otra herramienta que aprender.
El acceso sigue tu jerarquía existente de grupos y proyectos, y los permisos granulares ofrecen un control adicional, así que no hay un segundo modelo de acceso que mantener sincronizado. Define una credencial una sola vez a nivel de proyecto o compártela en todo el grupo. Quien deja un proyecto pierde el acceso automáticamente.
El equipo de desarrollo declara el secreto que necesita un job con la palabra clave secrets: en el archivo de configuración del pipeline. GitLab ya conoce el proyecto, la rama y el entorno del job, así que no hay que configurar ninguna identidad entre la CI y un almacén de secretos independiente.
Cuando se rompe una referencia a un secreto, la corrección se entrega en la misma solicitud de fusión que el código, sin un segundo repositorio ni otra aprobación. Con credenciales seguras a una línea de distancia, menos secretos acaban en variables de CI, archivos de configuración locales o el repositorio.
Limita el radio de impacto de las credenciales expuestas
Cuando una dependencia comprometida se ejecuta dentro de un job, con el gestor de secretos de GitLab la limpieza consiste en rotar y auditar los secretos a los que ese job podía acceder, no en congelar todos los pipelines.
A diferencia de las variables de CI, que llegan a todos los jobs del pipeline, un secreto solo llega a los jobs que lo declaran y que están dentro de su alcance: rama, entorno y estado de protección.
El gestor de secretos escribe el valor en un archivo temporal y expone solo su ruta, lo que limita la exposición en subprocesos, volcados de memoria y telemetría. El valor se enmascara en los registros del job y se descarta cuando el job finaliza, así que nada persiste en el runner.
Los eventos de creación, lectura, actualización y eliminación quedan en el mismo registro de auditoría que el resto de GitLab. Las lecturas desde pipelines incluyen los ID del pipeline y del job, para que los equipos de respuesta y los auditores puedan rastrear una credencial desde el acceso hasta la implementación sin tener que correlacionar manualmente registros de distintos sistemas.
Un solo almacén para pipelines, clústeres e infraestructura
Los pipelines leen los secretos directamente. Las cargas de trabajo de Kubernetes, las ejecuciones de Terraform y OpenTofu, las herramientas de CLI compatibles con Vault y otras automatizaciones se conectan mediante puntos de integración estándar, con los mismos permisos y el mismo registro de auditoría que los pipelines.
External Secrets Operator mantiene los Kubernetes Secrets sincronizados con GitLab, de modo que los valores rotados se propagan sin volver a implementar. Terraform y OpenTofu leen los secretos como fuente de datos durante la ejecución, lo que mantiene las credenciales fuera de los archivos y de las variables CI/CD.
Como está basado en OpenBao, el gestor de secretos expone una API compatible con Vault, así que los equipos que ya tienen scripts para la CLI de OpenBao o de Vault conservan sus comandos. Cualquier otra automatización obtiene los secretos mediante la API del gestor de secretos, en lugar de codificar credenciales de forma rígida o mantener archivos de variables independientes.
Las credenciales acompañan a las cargas de trabajo multinube, híbridas e in situ sin federación de identidades por plataforma. Mover una carga de trabajo a otra nube no implica crear un segundo almacén, y los secretos que, de otro modo, estarían dispersos en almacenes por cuenta y por región se encuentran en un solo lugar.
GitLab va más allá de administrar credenciales. La protección push de detección de secretos impide que las credenciales lleguen al repositorio, la detección del lado del cliente identifica secretos en el texto de tickets y solicitudes de fusión, y la detección de secretos en pipelines encuentra los que ya están en el código. Agent Platform de GitLab Duo clasifica las incidencias y señala los posibles falsos positivos.
El gestor de secretos de GitLab es un complemento de pago para Premium y Ultimate que se factura mediante GitLab CREDITS: 1 crédito por secreto almacenado al mes y 1 crédito por cada 2 500 operaciones de lectura de secretos. Si prefieres una tarifa fija, puedes optar por un acuerdo de licencia empresarial (ELA).
// HAZ TUYO LO QUE VIENE
¿Ya eres cliente de Premium o Ultimate? Puedes probar el gestor de secretos de GitLab sin costo durante 30 días o hasta consumir 500 créditos de evaluación, lo que ocurra primero.
GitLab creó este marco de madurez a partir de su experiencia con clientes líderes del sector. Responde unas preguntas sobre cómo gestiona tu equipo la seguridad y el cumplimiento para obtener tu puntuación de madurez y recomendaciones para la siguiente etapa.
El cuestionario lleva 5 minutos o menos
Siguen funcionando y no se migra nada automáticamente. Las variables CI/CD siguen siendo una buena opción para la configuración no sensible. Para encontrar candidatas a la migración, usa la herramienta de auditoría de secretos para variables CI/CD para identificar qué variables contienen credenciales y, luego, traslada esos valores al gestor de secretos según tu propio calendario.
Sí, sin cambios. Las integraciones existentes con HashiCorp Vault,