Los Helm charts por defecto de la pila de IA despliegan ejecución root sin autenticar
Una auditoría de 15 charts de Ray, vLLM, LiteLLM, Qdrant, Weaviate y servidores MCP encuentra ejecución root sin autenticar, contraseñas en claro y bases vectoriales abiertas.
Un equipo de consultoría ha montado un cluster limpio y ha instalado con helm install, sin tocar un solo valor, los charts más habituales de la pila de IA: Ray, KubeRay, vLLM, LiteLLM, Qdrant, Weaviate y varios servidores MCP. El resultado es que los valores por defecto dejan ejecución remota como root sin autenticar, contraseñas de base de datos en texto plano y bases vectoriales abiertas a lectura y escritura anónima.
Ray y KubeRay: root sin contraseña
El despliegue por defecto de Ray acepta envío de jobs sin autenticación desde la red interna del cluster. Los contenedores de worker arrancan con sudo sin contraseña. Cualquier pod comprometido que alcance la API de Ray en una red plana obtiene ejecución remota arbitraria como root, sin ninguna barrera por medio.
Los servidores MCP no salen mejor parados. Varias implementaciones populares protegen el acceso local comprobando únicamente la cabecera Host: localhost. Un SSRF básico o cualquier proxy interno que pase -H "Host: localhost" se salta la comprobación al instante. En las pruebas, uno de los servidores MCP para Kubernetes montaba un ClusterRole con lectura de Secrets en todo el cluster y permisos de pod exec, servido por HTTP sin autenticación.
Contraseñas en variables de entorno
En LiteLLM el despliegue principal sí toma la contraseña de la base de datos desde un Secret con secretKeyRef, pero el Job de migración la incrusta en claro como variable de entorno. Cualquiera con permisos básicos de lectura en el cluster —desarrolladores, cuentas de servicio de CI, dashboards— puede lanzar kubectl get job -o yaml y sacarla del bloque env sin tener permiso para leer Secrets.
Varios charts de bases vectoriales siguen trayendo valores por defecto que habilitan acceso anónimo de lectura y escritura. Los embeddings y los documentos ingeridos quedan consultables por cualquier servicio interno sin cabecera de autenticación.
Los autores del análisis señalan además dos puntos ciegos de las herramientas habituales. De los 15 charts revisados, 14 no incluyen ningún objeto NetworkPolicy, y los 15 mantienen automountServiceAccountToken: true. Checkov, Trivy y Kubescape no detectaron los contenedores anidados dentro de Custom Resource Definitions como los clusters de Ray.
El repositorio con los manifiestos de reproducción y los logs de las sondas está en GitHub, y el informe completo en sorami.com.au.
Para quien opera plataformas, la conclusión es incómoda: la conversación sobre la cadena de suministro de IA se centra en prompt injection y jailbreaks, mientras los valores por defecto de la capa de plataforma se parecen a los de Kubernetes de hace cinco o siete años. Sin reglas de admisión con Kyverno o OPA Gatekeeper, NetworkPolicies obligatorias y tokens de cuenta de servicio desactivados en los namespaces de IA, el perímetro interno queda abierto. Los charts upstream tendrán que decidir si cambian sus valores por defecto o si siguen delegando el problema en quien los despliega.
