Cómo administrar secretos en pipelines y aplicaciones

Porque el código se versiona en un control de versiones y se comparte —con el equipo, a veces en repositorios públicos, y con cualquiera que obtenga una copia—, de modo que cualquier contraseña, clave o token escrito en él queda expuesto a todas esas personas. Y hay un agravante decisivo: aunque borres el secreto en un commit posterior, sigue quedando registrado en el historial del repositorio, accesible de forma permanente para quien revise las versiones anteriores. Por eso la excusa de «lo saco después» no funciona: en el momento en que un secreto se sube, se considera comprometido. A esto se suma que existen sistemas automáticos que rastrean continuamente los repositorios públicos en busca de credenciales subidas por error y las explotan en cuestión de minutos. Separar los secretos del código no es entonces una formalidad ni una molestia burocrática, sino una de las medidas de seguridad más básicas y de mayor impacto que existen, y su ausencia está detrás de una enorme cantidad de brechas.

Las variables de entorno son valores que un programa lee del sistema donde se ejecuta, en lugar de tenerlos escritos en su propio código. Aplicadas a los secretos, permiten que el código diga algo como «leé la contraseña de la variable correspondiente» mientras el valor real vive fuera, en el entorno de la máquina o del servicio donde corre la aplicación, y nunca queda escrito en el código ni en el repositorio. Esto aporta dos beneficios importantes. El primero y principal es de seguridad: el secreto se saca del código, que es justamente el lugar donde no debe estar. El segundo es de flexibilidad: la misma aplicación, sin cambiar una sola línea, puede correr en desarrollo, en pruebas y en producción con credenciales distintas, porque lo único que cambia es el entorno que provee cada valor. Este principio de mantener la configuración y los secretos en el entorno y no en el código es una de las bases del enfoque moderno de despliegue de aplicaciones.

Es un servicio dedicado específicamente a custodiar credenciales, que resuelve el problema de dónde guardar y cómo entregar los secretos de forma segura a escala. Cumple varias funciones clave. Almacena los secretos cifrados en lugar de en texto plano. Controla mediante permisos quién puede leer cada secreto, ya sea una persona o un servicio, permitiendo aplicar el principio de mínimo privilegio. Registra cada acceso, de modo que queda una auditoría de quién leyó qué y cuándo. Y centraliza el cambio, de manera que un secreto se actualiza en un solo lugar y todas las aplicaciones que lo usan reciben el nuevo valor sin necesidad de tocar código. Existen gestores de secretos ofrecidos como servicio por las plataformas de nube y también soluciones que se pueden autoalojar. Lo importante no es cuál se elija, sino adoptar el patrón: el secreto vive en el gestor, y las aplicaciones y los pipelines lo solicitan en el momento de arrancar, con permisos acotados y de forma auditable.

Rotar un secreto significa cambiarlo por uno nuevo cada cierto tiempo de forma periódica, y la razón es acotar el daño de una filtración que podría no haberse detectado. Si un secreto permaneciera inalterado para siempre y en algún momento se filtrara sin que nadie lo advirtiera, un atacante tendría acceso indefinido con esa credencial. Al rotarlo periódicamente, en cambio, cualquier secreto comprometido deja de ser válido en la siguiente rotación, de modo que su ventana de utilidad para quien lo haya obtenido es corta. La rotación es una defensa en profundidad: no evita la filtración, pero limita cuánto tiempo sirve. Un gestor de secretos facilita mucho esta práctica, porque permite cambiar el valor en un único lugar y propagarlo automáticamente a todo lo que lo use, sin la fricción de actualizarlo a mano en muchos sitios, que es justamente lo que suele llevar a que la rotación no se haga. Los estándares de gestión de claves tratan este ciclo de vida en detalle.

Lo primero y más importante es entender el orden correcto de las acciones, que es contraintuitivo. El primer paso debe ser revocar el secreto comprometido de inmediato, es decir invalidarlo en el servicio al que da acceso para que deje de funcionar. El segundo paso es generar un secreto nuevo y desplegarlo donde haga falta para que la aplicación siga operando. Y solo el tercer paso es limpiar el historial del repositorio para quitar el secreto de las versiones anteriores. La razón de este orden es crucial: mientras el secreto filtrado siga siendo válido, borrarlo del repositorio no sirve absolutamente de nada, porque quien lo haya visto ya tiene una copia y puede usarlo; lo único que corta el riesgo real es invalidar la credencial. Por eso tratar una filtración de secretos debe encararse como lo que es, un incidente de seguridad, aplicando los principios de la respuesta ante incidentes y de la gestión de vulnerabilidades: contener primero, remediar después.

Sí, es exactamente la misma regla en todos esos contextos, porque el principio de fondo es siempre el mismo: los secretos no deben quedar incrustados en nada que se versione, se comparta o se distribuya. En Docker, eso significa no escribir secretos en la imagen ni en el Dockerfile, ya que quedan grabados en las capas, e inyectarlos como variables de entorno al ejecutar. En Kubernetes, significa no ponerlos en los manifiestos versionados sino usar los objetos de secretos y un gestor externo. En los pipelines de integración y despliegue continuos, significa no escribirlos en el archivo del workflow sino cargarlos en el almacén de secretos cifrados de la plataforma. En la infraestructura como código con Terraform, significa no ponerlos en los archivos de configuración y además proteger el estado, que puede contenerlos. En todos los casos el patrón es idéntico: el secreto vive en un mecanismo aparte pensado para protegerlo, se inyecta o se referencia en tiempo de ejecución, y jamás se incrusta en el código, la imagen, el manifiesto o la configuración que se guarda y se comparte.