Hallazgos sueltos
Los problemas de seguridad aparecían por casualidad, como efecto colateral de otros trabajos: un token encontrado aquí, una base desactualizada allá, una herramienta expuesta más allá. No había una visión única de la superficie de ataque, y cada hallazgo quedaba sin dueño, sin severidad y sin plan.
Propuse un barrido con método, y con una regla que no iba a romper: no tocar nada.
Mirar sin tocar
Analicé los clústeres Kubernetes de producción en siete frentes: versiones frente a las fechas de fin de soporte, exposición de red, permisos, secretos, configuración de los workloads, acceso a las bases de datos y paneles administrativos expuestos.
Todo se hizo en modo solo lectura. No se usó ninguna credencial encontrada, y no se cambió nada durante el análisis. Para decir que algo estaba "abierto a internet", probé desde una conexión común, sin VPN, para no confundirlo con "abierto para quien está en la red interna". Cuando encontré la misma contraseña sirviendo a varios sistemas, probé la reutilización comparando hashes, sin que el informe contuviera un solo secreto. Y cada hallazgo quedó registrado con el comando y el valor observado.
En un segundo producto, amplié el análisis con una revisión estática de 14 repositorios contra el OWASP Top 10 de 2025 y una verificación externa pasiva de los hosts públicos.
Qué apareció
El primer barrido tuvo 13 hallazgos: dos críticos, cuatro altos, cinco medios y dos bajos. Había credenciales en texto plano en ConfigMaps, con la misma contraseña reutilizada en varias bases, de modo que una sola filtración abriría producción y el backup al mismo tiempo. Había tokens de acceso a Git en texto plano en la configuración de GitOps, también presentes en el historial del repositorio. Había bases y paneles accesibles desde internet sin restricción de origen, versiones de Kubernetes y de sistema operativo sin soporte, permisos demasiado amplios y una CVE crítica, con CVSS 9,8, en un componente de borde que el propio proyecto ya había descontinuado. En el CI, acciones de terceros se referenciaban por branch y corrían con credenciales de producción en el entorno.
En el informe del segundo producto, separé 16 acciones para el equipo de DevOps y 12 sugerencias para el equipo de desarrollo, para que cada lado supiera exactamente qué le tocaba.
El orden importa
Cada hallazgo crítico se convirtió en una tarjeta propia, con acciones en orden de riesgo, criterios de aceptación y plan de reversión. Muchas veces, el orden correcto era la parte más importante. Rotar una credencial tiene que venir antes de limpiar el historial de Git, porque reescribir el historial sin revocar la clave no sirve: el valor ya se filtró. En la API de Kubernetes, primero entran en la regla las IPs de la VPN y de la red interna, y solo después sale la regla abierta, con aviso al equipo que usa kubectl. Y las políticas de seguridad de pods empiezan en modo aviso y auditoría antes de bloquear nada.
Las primeras correcciones
Eliminé el vínculo de administrador del clúster ligado a un usuario individual en dos clústeres, después de confirmar que la persona mantenía el acceso por el grupo de IAM y de guardar una copia del objeto. Empecé a migrar las credenciales de ConfigMap a Secret, reduciendo las copias de la contraseña maestra, sin ningún impacto en producción: ningún contenedor reiniciado y ningún evento de error. Y diseñé la mitigación de la CVE crítica del ingress, con un paso inmediato y reversible y la migración a otro controlador, host por host.
Qué cambió
La seguridad de la infraestructura pasó de hallazgos sueltos a un inventario único, con severidad, evidencia y dueño. Los ítems críticos se convirtieron en tarjetas con plan de ejecución y de reversión, y las primeras correcciones entraron sin ningún impacto en producción.
Lo que me llevo
Un análisis de seguridad solo sirve si es seguro y accionable. Seguro: solo lectura, sin usar credenciales encontradas y sin secretos en el informe. Accionable: cada hallazgo con evidencia, severidad, dueño y el orden correcto de corrección. En seguridad, hacer lo correcto en el orden equivocado causa el problema que se quería evitar.