Gestión de secretos:

por qué las claves no van en el repositorio y qué hacer en su lugar

DevSecOps  |  unfantasmaenelsistema.com

Casi todo el mundo lo ha hecho alguna vez: una clave de API pegada en un fichero de configuración, una contraseña de base de datos en un `docker-compose.yml`, un token en un script de despliegue que «solo era para probar». Y luego ese código se sube a un repositorio. En cuanto ese commit existe, el secreto deja de ser secreto: queda en el historial de Git, se replica en cada clon, en cada fork y en cada mirror, y sigue ahí aunque borres la línea en el commit siguiente.

La gestión de secretos es la disciplina que resuelve ese problema para todo lo que no es una persona delante de un teclado: servidores, pipelines de CI/CD, contenedores y servicios que necesitan autenticarse entre sí sin que la credencial acabe escrita en texto claro en un sitio del que ya no se puede sacar. Este artículo recorre por qué el problema es tan persistente, cómo se detecta una fuga y qué herramientas y patrones se usan hoy para gestionarlo bien.

1. Por qué un secreto en el repositorio ya no es un secreto

Git no guarda ficheros, guarda una cadena de instantáneas enlazadas. Cuando añades una clave a un fichero y haces commit, ese contenido queda referenciado por el hash de ese commit para siempre. Borrarlo en un commit posterior solo añade una instantánea nueva sin la línea; la anterior, con el secreto, sigue siendo accesible con `git log`, `git show` o cualquier herramienta que recorra el historial.

Y aunque reescribieras el historial con `git filter-repo` o similar, ya es tarde en la práctica: si el repositorio se ha empujado a un servidor compartido, cualquiera con acceso ha podido clonarlo. En un repositorio público, los bots que rastrean GitHub en busca de credenciales encuentran una clave nueva en cuestión de segundos, no de horas. El commit puede haber quedado también en forks, en mirrors internos, en cachés de CI, en la copia local de cada compañero y en los sistemas de indexado de seguridad de la propia plataforma.

2. Detección: encontrar los secretos antes (y después) de que salgan

La primera capa de defensa es no dejar que el secreto llegue al repositorio, y la segunda es detectarlo cuanto antes si llega. Las herramientas de escaneo buscan patrones conocidos (formatos de clave de AWS, tokens de GitHub, claves privadas PEM, cadenas de conexión) y también entropía alta, que delata cadenas aleatorias que parecen credenciales.

Lo eficaz es combinar niveles: un hook de `pre-commit` que corre gitleaks en local para el descuido cotidiano, el mismo escaneo como paso obligatorio de CI para lo que se salte el hook, y la protección en el push de la plataforma como último filtro. Ninguno sustituye a los demás.

# Escanear todo el historial de un repositorio en busca de secretos
gitleaks detect --source . --report-format sarif --report-path gitleaks.sarif
 
# Como hook de pre-commit (.pre-commit-config.yaml)
#   - repo: https://github.com/gitleaks/gitleaks
#     rev: v8.18.0
#     hooks:
#       - id: gitleaks
 
# Comprobar si un token encontrado sigue vivo, sin exponerlo en claro
trufflehog git file://. --only-verified

3. Dónde deberían vivir los secretos: los gestores

Un gestor de secretos es un servicio cuya única función es guardar credenciales cifradas, controlar quién puede leer cada una, y registrar cada acceso. La aplicación no lleva la contraseña: lleva una identidad con la que pide la contraseña al gestor en el momento de arrancar o de usarla.

3.1 Familias principales

• HashiCorp Vault (y su fork OpenBao): gestor completo y agnóstico de plataforma. Almacén cifrado, políticas por ruta, auditoría, y motores que generan credenciales dinámicas para bases de datos, nube y PKI. Es el más potente y el que más operación requiere
• Gestores de la nube (AWS Secrets Manager, GCP Secret Manager, Azure Key Vault): integrados con el IAM del proveedor, rotación gestionada para sus propios servicios, cero infraestructura que mantener. A cambio, atan el diseño a esa nube
• sops + age (o KMS): no es un servicio, es un formato. Cifra los valores de un fichero YAML/JSON dejando las claves legibles, de modo que el fichero cifrado sí puede vivir en Git. Encaja de forma natural en flujos GitOps, donde el repositorio es la fuente de verdad
• Kubernetes: los `Secret` nativos son solo base64 (no cifrado) salvo que actives cifrado en reposo en etcd; lo habitual es combinarlos con un operador (External Secrets Operator, Sealed Secrets) que sincroniza desde un gestor real

4. Secretos dinámicos y de vida corta

La mejor credencial filtrada es la que ya ha caducado. Un secreto dinámico se genera bajo demanda, con permisos mínimos y una validez de minutos u horas, y se destruye al expirar. Si se filtra en un log, cuando alguien lo lee ya no sirve.

El ejemplo clásico es el acceso a base de datos: en lugar de una contraseña fija compartida por todas las instancias del servicio, el gestor crea un usuario temporal en la base de datos cada vez que un servicio arranca, con un TTL corto, y lo elimina al vencer. Lo mismo aplica a credenciales de nube (roles asumidos por minutos), a certificados de cliente emitidos por un PKI interno, o a tokens de acceso a APIs internas.

5. Inyección en tiempo de ejecución y sus fugas

Una vez que el secreto está en un gestor, hay que hacérselo llegar al proceso que lo usa. Cada mecanismo tiene un perfil de fuga distinto.

6. Rotación, revocación y contenedores

Un programa de secretos maduro define, para cada tipo de credencial, un periodo máximo de vida y un procedimiento de revocación inmediata para cuando algo se tuerce. La revocación tiene que ser independiente de la rotación: si sospechas de una fuga a las tres de la madrugada, necesitas poder invalidar esa credencial concreta sin esperar al ciclo normal ni desplegar nada.

6.1 En imágenes de contenedor

• Un secreto copiado en una capa de la imagen queda en esa capa aunque una instrucción posterior lo borre: `docker history` y el desempaquetado de capas lo recuperan. Nunca va en el `Dockerfile` ni en un `COPY`
• Los secretos de build (para descargar dependencias privadas, por ejemplo) se pasan con `RUN –mount=type=secret`, que los expone solo durante ese paso y no los persiste en la imagen
• Los secretos de ejecución se inyectan al arrancar el contenedor desde el orquestador o el gestor, no se hornean en la imagen

6.2 En CI/CD

• Los secretos del pipeline se guardan en el almacén de secretos del propio CI o se leen de un gestor externo mediante identidad federada (OIDC), que evita tener un token de larga vida guardado en el CI
• Enmascarado de secretos en los logs activado, y cuidado con los `echo`, los `set -x` y los pasos que imprimen el entorno al depurar
• Los pull requests desde forks no deberían tener acceso a los secretos del repositorio: es un vector clásico de exfiltración

# .sops.yaml: reglas de cifrado por ruta y por clave age
creation_rules:
  - path_regex: secrets/prod/.*\.yaml$
    key_groups:
      - age:
          - age1ql3z7hjy54pw3hyww5ayyfg7zqgvc7w3j2elw8zmrj2kg5sfn9aqmcac8p
  - path_regex: secrets/dev/.*\.yaml$
    age: age1lggyhqq0h2r3z0d0jd9q0zj0z0w0z0z0z0z0z0z0z0z0z0z0z0sq0x2r0
 
# Editar un secreto cifrado en el sitio (sops descifra en memoria)
sops secrets/prod/database.yaml
 
# Descifrar en el arranque del servicio, sin escribir a disco
sops --decrypt secrets/prod/database.yaml | app --config -

Conclusión

El error de fondo casi nunca es criptográfico: es de proceso. El secreto acaba en un sitio del que no se puede sacar (un commit, una capa de imagen, un log) porque en el momento de escribirlo era lo más rápido. La gestión de secretos consiste en hacer que la opción correcta —pedírselo a un gestor en tiempo de ejecución— sea también la más cómoda, y en poner redes (escaneo en el commit, en el CI y en el push) para el día que alguien tenga prisa.

Si tienes que quedarte con tres ideas: los secretos no viven en el código sino en un gestor; cuanto más corta sea su vida, menos importa que se filtren; y una credencial que ha pasado por un repositorio se rota primero y se investiga después.

unfantasmaenelsistema.com | Seguridad, sistemas y todo lo que no debería funcionar (pero funciona)