BookinglyTech News
Ciberseguridad

SecretWatch, un CLI para vigilar la rotación de secretos en AWS, Vault, GCP y GitHub

El proyecto es open source y autoalojado, y centraliza las políticas de caducidad y el historial de auditoría de cuatro gestores de secretos. Su autor pide comentarios antes de que alguien lo lleve a producción.

2 min de lecturar/selfhosted0 vistas

SecretWatch es un CLI open source y autoalojado que reúne en un solo sitio el estado de rotación de los secretos repartidos entre AWS Secrets Manager, HashiCorp Vault KV v2, GCP Secret Manager y los secretos de GitHub Actions. La propuesta apunta a un problema conocido: cada consola ve solo sus propios secretos y nadie tiene la foto completa de qué está caducado y cuándo toca cambiarlo.

El programa permite definir políticas de rotación por secreto o por patrón —los que empiezan por prod- caducan a los 30 días, los dev- a los 180— y mantiene un historial de auditoría con quién rotó cada cosa y cuándo, alimentado desde CloudTrail, Cloud Audit Logs y el log de auditoría de GitHub. Todo se consulta desde un panel web, con alertas por Slack, y la caché vive en SQLite. Según su autor, el programa es completamente local y las credenciales no salen de la máquina.

Lo que falta por saber

La información publicada se queda corta en los detalles que importan antes de meter esto en un entorno real. No hay enlace al repositorio, ni licencia, ni versión, ni instrucciones de instalación. Tampoco explica con qué credenciales lee los cuatro proveedores a la vez ni qué permisos necesita para consultar CloudTrail y los logs de auditoría, que es justo donde suele torcerse este tipo de agregadores. ¿Se despliega como contenedor? ¿Cómo se guardan las credenciales contra los backends? ¿Es un binario, un script? Nada de eso aparece.

El autor pide precisamente eso: saber qué está roto y qué haría falta para confiar en la herramienta. Es un proyecto en fase temprana y se nota.

Lo interesante del planteamiento no es el inventario, que ya lo hacen las consolas y varias herramientas comerciales, sino juntar cuatro backends distintos bajo una misma política de caducidad y un mismo registro de auditoría. Ese es el trabajo aburrido que nadie quiere hacer a mano y el que suele terminar en una hoja de cálculo desactualizada. Si el proyecto acaba publicando el código y dejando claro su modelo de permisos, hay hueco para él en equipos que ya conviven con Vault y con cloud a la vez. De momento queda un anuncio sin repositorio y sin más datos que los que da su autor.