Linter manifiesto de Kubernetes

Los manifiestos de Kubernetes generalmente se revisan a ojo en una solicitud de extracción, lo que significa que el mismo puñado de errores de endurecimiento siguen llegando a producción: una implementación sin límite de memoria que eventualmente es eliminada por OOM y se lleva un nodo con ella, un contenedor que felizmente se ejecuta como root porque nadie configuró runAsNonRoot, o un Pod anclado a una etiqueta de imagen como `:latest` que cambia silenciosamente debajo de una implementación. Este linter detecta esa clase de problema en el momento en que pega un manifiesto, sin necesidad de un clúster en ejecución, contexto kubectl ni ninguna credencial.

Debajo del capó, incluye un pequeño analizador YAML hecho a mano escrito específicamente para el subconjunto realista de YAML que los manifiestos de Kubernetes realmente usan: documentos separados `---`, anidamiento basado en sangría, `key: value` y asignaciones de bloques anidados, elementos de secuencia `- ` que incluyen listas de mapas, escalares entre comillas y sin comillas, comentarios y escalares de bloques `|`/`>` para cosas como ConfigMap multilínea. valores o anotaciones. No hay ninguna biblioteca YAML externa involucrada: el analizador y el motor de reglas están incluidos con la herramienta y se ejecutan completamente en su navegador.

La tabla de reglas se basa en una guía de refuerzo de clústeres conocida (el CIS Kubernetes Benchmark, kube-score y el perfil "Restringido" de los estándares de seguridad de pod) y verifica cada contenedor en busca de solicitudes/límites de recursos faltantes, contenedores que pueden ejecutarse como raíz o en modo privilegiado, falta de sondas de actividad y preparación en cargas de trabajo de larga ejecución (implementaciones, StatefulSets, DaemonSets), montajes de volumen hostPath que exponen el sistema de archivos del host, uso de hostNetwork e imágenes de contenedor no reproducibles `:latest` o sin etiquetar. Los hallazgos se agrupan por documento y por contenedor, con una clara gravedad de error/advertencia en cada uno para que pueda distinguir qué es realmente riesgoso de lo que es simplemente un empujón de mejores prácticas.

Funciona en manifiestos únicos o archivos completos de múltiples documentos pegados directamente desde una representación de plantilla de Helm o una salida de "compilación personalizada", comprendiendo los recursos Pod, Deployment, StatefulSet, DaemonSet, Job, ReplicaSet y CronJob. Debido a que todo se ejecuta localmente, es seguro pegar manifiestos que contengan nombres de servicios internos, tamaño real de recursos o cualquier otra cosa que no desee enviar a una API de terceros, lo que resulta útil para una verificación rápida de cordura previa a la confirmación, una ayuda para la revisión de código o simplemente para aprender cómo se ve realmente "reforzado" en la práctica.