Deja de guardar secretos en el repositorio: guía práctica de gestión de secretos

Todos hemos visto (o protagonizado) ese commit: un config.yaml con la contraseña de la base de datos, un token de AWS en un script de despliegue, una clave de API en el historial de Git. Guardar secretos en el repositorio es de los errores más comunes y más caros del mundo DevOps, porque Git no olvida: aunque lo borres en el siguiente commit, sigue ahí para cualquiera que clone el historial. Hoy repasamos buenas prácticas concretas para dejar de hacerlo de una vez.

Por qué es tan grave

Un secreto filtrado en un repositorio público suele ser explotado en minutos: hay bots escaneando GitHub constantemente en busca de credenciales. Pero en repositorios privados el riesgo también existe: cualquier persona con acceso de lectura (empleados, contratistas, integraciones de CI) puede ver ese secreto, y cuando alguien deja el equipo no hay forma de saber qué se llevó. Un secreto en Git es un secreto sin control de acceso ni caducidad.

Buenas prácticas que aplico en todos mis proyectos

• Usa un gestor de secretos de verdad: HashiCorp Vault, AWS Secrets Manager, Azure Key Vault o Google Secret Manager. Todos ofrecen control de acceso, auditoría y rotación. La aplicación pide el secreto en tiempo de ejecución en lugar de llevarlo empaquetado.
• Variables de entorno, pero con cabeza: son mejores que un fichero en el repo, aunque ojo con volcarlas en logs o exponerlas en paneles de CI. Y un .env siempre en el .gitignore, con un .env.example sin valores reales como documentación.
• Si necesitas versionar secretos, cífralos: herramientas como SOPS o Sealed Secrets en Kubernetes permiten guardar en Git una versión cifrada que solo el clúster o quien tenga la clave puede descifrar. Lo mejor de ambos mundos: GitOps sin exponer nada.
• Pon un guardián en el pipeline: escáneres como gitleaks o trufflehog detectan patrones de credenciales antes de que lleguen al repositorio. Como hook de pre-commit o como paso obligatorio de CI, cuestan poco y evitan disgustos.
• Prefiere identidades a credenciales: siempre que puedas, usa roles de IAM, workload identity o OIDC entre tu CI y tu nube. La mejor gestión de un secreto es que el secreto no exista.

¿Y si ya se me ha escapado uno?

Lo primero y único urgente: rotar la credencial. Da igual lo que hagas con el historial de Git si la clave sigue siendo válida. Después ya puedes limpiar el repositorio con herramientas como git-filter-repo, avisar a quien corresponda y, sobre todo, añadir el escáner que habría evitado el incidente. El orden importa: primero revocar, luego limpiar.

# Ejemplo: hook de pre-commit con gitleaks
repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.18.0
    hooks:
      - id: gitleaks

Conclusión

La gestión de secretos no es glamurosa, pero es de esas cosas que separan un equipo maduro de uno que va a tener un disgusto. Empieza por lo barato (gitignore, escáner en CI) y ve subiendo hacia un gestor centralizado e identidades federadas. Tu futuro yo, y el departamento de seguridad, te lo agradecerán.

¿Cuál ha sido el susto más gordo que has tenido con un secreto filtrado? Cuéntamelo en los comentarios 😊