Analizador de manifiestos de Kubernetes
Pega un manifiesto de Kubernetes para detectar límites de recursos ausentes, ajustes de seguridad arriesgados y reglas RBAC demasiado amplias, con un parche sugerido.
Se ejecuta en tu navegador · no se envía nadaKubernetes e IaCNuevo
Todo se ejecuta en tu navegador. No se envía nada, incluidos los nombres de imagen, namespaces y etiquetas de tu manifiesto.
Cómo se usa
- Copia un manifiesto con "kubectl get deployment <nombre> -o yaml" o desde tus archivos de origen.
- Pega el YAML en la herramienta (usa "---" entre documentos si tienes más de uno).
- Revisa los hallazgos y la tabla de recursos.
- Abre "Cambios sugeridos" para un parche que combinar con tu manifiesto, y exporta el informe si lo necesitas.
Casos habituales
Comprueba que los límites de recursos, los probes y un contexto de seguridad seguro estén presentes antes de fusionar un manifiesto.
Pega un Role o ClusterRole para comprobar permisos con comodín o acceso a Secrets antes de vincularlo a una cuenta de servicio.
Explicación
Pega uno o varios manifiestos de Kubernetes (separados por "---" si hay varios) y la herramienta revisa cada carga de trabajo (Pod, Deployment, StatefulSet, DaemonSet, Job, CronJob) en busca de límites y solicitudes de recursos ausentes, un contexto de seguridad ausente o arriesgado (contenedores privilegiados, escalada de privilegios permitida, sistema de archivos raíz modificable, capacidades de Linux peligrosas), liveness/readiness probes ausentes, y una etiqueta de imagen sin fijar. También revisa cada Role y ClusterRole en busca de reglas RBAC demasiado amplias, como un comodín tanto en recursos como en verbos, o acceso de lectura a Secrets. Para cada contenedor con algo ausente, la herramienta sugiere un parche que puedes combinar con tu manifiesto. Todo se ejecuta localmente; el manifiesto nunca sale de tu navegador.
🔒 Tu entrada se queda en tu navegador y no se envía a ningún sitio.
Preguntas frecuentes
¿Esto valida contra la API de Kubernetes o un clúster?
No. Solo analiza el YAML que pegas y lo comprueba frente a un conjunto fijo de reglas, sin conectarse a ningún clúster ni servidor de API.
¿Por qué se señala un "runAsNonRoot: true" ausente aunque la imagen ya use un usuario no root?
Sin ese ajuste explícito, el contenedor podría seguir ejecutándose como root si la imagen se sustituye algún día por una que use root por defecto, de forma intencionada o no. Definirlo explícitamente hace esa situación imposible, no solo improbable.
¿Qué incluye el parche sugerido?
Solo los campos que esta herramienta realmente comprueba: solicitudes y límites de recursos, un contexto de seguridad más seguro, y ejemplos de liveness/readiness probes. Los valores de ejemplo (sobre todo los límites de recursos) son un punto de partida, no una medición de tu carga real, así que ajústalos a lo que el contenedor necesite de verdad.
¿Soporta CronJob y archivos con varios documentos?
Sí. CronJob se comprueba a través de su jobTemplate anidado, y puedes pegar varios documentos separados por "---", incluida una mezcla de cargas de trabajo y recursos RBAC.
Qué hacer después
¿Has encontrado un problema o tienes una sugerencia? Cuéntanoslo