DevSecOps series No. 4: Protegiendo las variables de entorno en los sistemas de CI más conocidos
En un pipeline de CI/CD es de lo más normal guardar credenciales de servicios en variables de entorno: las claves de AWS, el usuario y la contraseña de la base de datos, ese tipo de cosas.
Los sistemas de automatización más usados tienen su propia manera de manejar esa información sensible. No hace falta inventarse nada.
En este post repaso cómo lo hacen los cuatro más comunes.
Jenkins
Jenkins llama secrets a estos datos y los guarda en una ruta concreta, $JENKINS_HOME/secrets/, cifrados con AES.
Para recuperar la versión en claro de una contraseña cifrada, Jenkins necesita una integración específica con el lenguaje de programación que estés usando.
Tienes más detalles en la documentación de Jenkins.
GitHub Actions
GitHub Actions usa una variable de entorno especial llamada secrets. Lo que marques como secreto no aparece en los logs y se guarda cifrado.
Para dar de alta un secreto tienes que añadir cada variable, una a una, en la página de ajustes del proyecto.
Después lo usas con la sintaxis de GitHub:
Tienes más detalles en la documentación de GitHub.
GitLab CI/CD
GitLab usa una variable de entorno especial que llama variable protegida. Lo que marques como protegido no aparece en los logs.
El valor de una variable protegida se cifra con aes-256-cbc y se guarda en la base de datos. Solo se puede leer y descifrar con un fichero de secretos válido.
Para dar de alta una variable protegida, igual que en GitHub: cada variable en la página de ajustes del proyecto.
Después la usas como una variable cualquiera:
Tienes más detalles en la documentación de GitLab.
Bitbucket Pipelines
Como GitLab, Bitbucket usa una variable de entorno especial que llama variable segura. Lo que marques como seguro no aparece en los logs y se guarda cifrado.
Para dar de alta una variable segura tienes que añadir cada variable en la página de ajustes del proyecto:
Después la usas como una variable cualquiera:
Tienes más detalles en la documentación de Bitbucket.
Conclusiones
Manejar datos sensibles de sistemas críticos es el pan de cada día en un CI/CD.
Lo que se nos suele olvidar es que esos datos son de producción. Y que hay que tratarlos como tales.
Todos los sistemas de automatización tienen su manera de gestionar la información sensible, y ninguna es difícil de usar. Lo único que hace falta es un poco de cuidado, y enseñárselo a los desarrolladores que todavía no la usan.
Más posts de la serie DevSecOps
Post anterior: DevSecOps series No. 3: Problemas de toda la vida en DevOps, las bombas zip
DevSecOps series No. 2: Comprobación automática de seguridad en Dockerfiles
DevSecOps series No. 1 — Rompiendo el CI/CD usando repositorios Git maliciosos
