Un LLM genera manifiestos de Kubernetes que funcionan, pero con agujeros: cómo detectarlos antes del despliegue

El manifiesto que ha producido la red neuronal parece impecable: sangrías correctas, campos conocidos, `kubectl apply` no protesta y el pod pasa a Running. Según el anuncio del análisis en Habr, ahí está precisamente la trampa. Los problemas aparecen más tarde, ya en producción. La causa es que los LLM reproducen configuraciones obsoletas e inseguras, de las que los datos de entrenamiento van sobrados. Para dimensionar el problema: Ingress de `extensions/v1beta1` se eliminó en Kubernetes 1.22, y PodSecurityPolicy desapareció en 1.25. Los tutoriales antiguos con esos objetos siguen en la red, y el modelo los cita sin reparos.

Advertencia: el anuncio disponible no incluye detalles, solo tesis. A continuación nos basamos en ellas y en las características conocidas de Kubernetes.

Por qué un YAML verosímil es peligroso

El modelo optimiza la probabilidad del siguiente token, no la seguridad del clúster. Años de ejemplos públicos, respuestas en foros y repositorios con configuraciones de demostración le enseñan el manifiesto «típico». El manifiesto típico de la documentación es mínimo a propósito: sin límites de recursos, sin restricciones de seguridad y, a menudo, con la etiqueta `latest`. Para un entorno de aprendizaje eso es normal. Para un clúster de producción, no.

La validación del esquema no detecta este problema. Comprueba la forma: que los campos existan y los tipos coincidan. Un contenedor ejecutado como root con `privileged: true` es formalmente correcto. Un manifiesto sin sondas readiness también lo es; simplemente el tráfico llegará al pod antes de que la aplicación esté lista para recibirlo.

El conjunto clásico de defectos que se encuentran al revisar este tipo de YAML:

• `apiVersion` de APIs eliminadas o declaradas obsoletas, por lo que el manifiesto se rompe al actualizar el clúster;
• imágenes con la etiqueta `latest` en lugar de una versión fija o un digest;
• ausencia de `resources.requests` y `limits`, es decir, riesgo de «vecino ruidoso» y de terminaciones por OOM;
• ejecución como root, sin `runAsNonRoot`, `allowPrivilegeEscalation: false` ni `readOnlyRootFilesystem`;
• ausencia de sondas liveness y readiness;
• secretos directamente en `env` en lugar de un Secret o un almacén externo;
• `hostNetwork`, `hostPath` y `privileged`, trasladados desde ejemplos de depuración;
• servicios expuestos al exterior y ausencia de NetworkPolicy.

Dónde poner las barreras

El primer nivel es la validación del esquema contra la versión concreta del clúster. Para ello sirven kubeconform y `kubectl apply --dry-run=server`: el dry-run del lado del servidor pasa el manifiesto por el servidor de API y los controladores de admission sin crear objetos. Para localizar APIs obsoletas existe Pluto.

El segundo nivel es el análisis estático de seguridad y buenas prácticas: kube-linter, Checkov, Trivy (modo config), Kubescape. Detectan contenedores root, ausencia de límites y modos privilegiados. Todo esto se ejecuta en el CI en cada pull request, con independencia de si el archivo lo escribió una persona o un modelo.

El tercer nivel son las políticas en el propio clúster. Pod Security Admission con el perfil `restricted` rechaza en la entrada los pods inseguros. Kyverno u OPA Gatekeeper añaden reglas propias: prohibición de `latest`, límites obligatorios, registros permitidos. Si el autor del manifiesto pasó algo por alto, el clúster no admitirá ese objeto.

Cómo trabajar con generación por IA en la práctica

Trate la respuesta del modelo como un pull request de un becario: rápido, seguro de sí mismo y sin entender su entorno. En el prompt indique de forma explícita la versión de Kubernetes, los requisitos de seguridad y las políticas de la organización. Pida que explique cada parámetro no trivial y luego contraste la explicación con la documentación.

No deje que los manifiestos generados lleguen directamente al clúster. Debe haber un solo camino: repositorio, CI con linters, revisión humana, despliegue con GitOps y rollout gradual con seguimiento de métricas. Así la velocidad de generación sigue siendo una ventaja y no un incidente aplazado.

Por último: si el equipo no tiene políticas que rechacen automáticamente las malas configuraciones, la IA se limitará a acelerar su aparición. Primero hacen falta las barreras y después la automatización.