Servidor MCP Kubernetes: kubectl seguro para agentes AI

En pocas palabras: Para evitar desastres como un “kubectl delete ns prod” alucinado, en 2026 se usa un servidor MCP Kubernetes con acceso read-only por defecto, allowlist de verbos, dry-run forzado y aprobación humana obligatoria. Así exponés kubectl a agentes de IA con herramientas tipadas y parámetros validados.

Si le das a un agente de IA un comando kubectl sin restricciones, es cuestión de tiempo —horas, no días— hasta que un kubectl delete ns prod alucinado te vuele producción. En 2026, la forma limpia de evitar ese desastre es un servidor MCP Kubernetes con read-only por defecto, allowlist de verbos, dry-run forzado y un gate de aprobación humana para cualquier mutación destructiva.

Un servidor MCP Kubernetes es una pieza de infraestructura que expone operaciones de kubectl a agentes de IA mediante el Model Context Protocol, con herramientas tipadas y argumentos estructurados en vez de un string libre. El host —Claude, un IDE, un orquestador— descubre las herramientas desde el servidor MCP y las invoca con parámetros validados, manteniendo el radio de explosión acotado.

¿Por qué no deberías darle un comando kubectl libre a un agente AI?

Tres modos de falla te explotan en la cara cuando soltás un agente con run_kubectl(command: string) en producción.

Comandos alucinados. Los LLM inventan flags y nombres de recursos con una confianza que asusta. Un agente que alucina kubectl delete deployment --all -n prod no lo piensa dos veces —lo ejecuta. Y si el tool recibe un string libre, el cluster obedece sin chistar.

Bucles de reintento asesinos. Ponele que el agente tira un comando, falla por un error de sintaxis, y el loop de razonamiento decide “reintentar con más fuerza”. Primero prueba con --force, después con --grace-period=0, y cuando te querés acordar borró la mitad del cluster “para resolver el error”.

Falta total de límites de alcance. Sin namespace scoping ni allowlist, el agente tiene las llaves del reino. Puede listar secrets, modificar deployments en cualquier namespace, o peor: ejecutar un kubectl delete ns prod porque el prompt del usuario era ambiguo y el modelo “interpretó” que había que limpiar recursos. Lo explicamos a fondo en en el análisis de CI/CD para 2026.

¿Qué es el Model Context Protocol y cómo se aplica a Kubernetes?

El Model Context Protocol (MCP) es un estándar abierto de Anthropic que permite a un agente de IA descubrir herramientas, invocarlas con argumentos estructurados y recibir resultados tipados. El host —Claude, un IDE como VS Code, un orquestador— se comunica con el servidor MCP, que expone un catálogo de tools con schemas bien definidos. Nada de strings libres, nada de prompt injection accidental.

Aplicado a Kubernetes, el servidor MCP traduce intenciones del agente en llamadas controladas a la API del cluster. En vez de run_kubectl("delete pod x"), el agente invoca delete_pod(name: string, namespace: string) con parámetros que el servidor valida, registra y —si hace falta— bloquea. La diferencia es la misma que entre darle a alguien un formulario con campos específicos o una shell con sudo.

Requisitos para construir un servidor MCP seguro para Kubernetes

Armar esto como corresponde —no como un prototipo de fin de semana— implica cinco componentes que no son negociables:

• Servidor MCP con tools tipadas. Cada operación de kubectl se expone como una función con argumentos definidos (nombre, namespace, labels). Nada de pasar un string crudo y rezar.
• Configuración de kubectl con permisos mínimos. El service account que usa el servidor tiene un RBAC ajustado. Si el agente solo necesita leer pods en staging, eso es todo lo que tiene.
• Lista blanca de verbos. Get, list, watch, describe están habilitados. Delete, create, update, patch están bloqueados por defecto y solo se habilitan con condiciones explícitas.
• Server-side dry-run forzado. Toda mutación se ejecuta primero con --dry-run=server. El servidor MCP aplica el dry-run antes de tocar el cluster, y el resultado se loguea para auditoría.
• Namespace scoping y gate de aprobación humana. Las operaciones se limitan a un namespace configurado. Si el agente necesita ejecutar algo destructivo, el servidor pausa y solicita confirmación explícita de un humano antes de proceder.

Pasos para implementar el servidor MCP con seguridad

El tutorial de la guía publicada en dev.to arranca con un servidor que expone herramientas read-only y después agrega capas de control una por una.

Paso 1: Crear el servidor MCP. Usás el SDK de MCP en Python o TypeScript, definís un server que se conecte a tu cluster vía kubeconfig, y exponés tools como get_pods, get_deployments, describe_resource. Cada tool recibe parámetros tipados y ejecuta el comando kubectl correspondiente.

Paso 2: Read-only por defecto. Las primeras tools que implementás son solo de lectura. El agente puede inspeccionar el estado del cluster, listar recursos, ver logs. Cero mutaciones.

Paso 3: Agregar allowlist de verbos. Cuando necesitás que el agente pueda crear o actualizar recursos, habilitás verbos específicos uno por uno. create_deployment puede existir, pero delete_namespace no —y no hay forma de que el agente lo invente porque no es un tool expuesto. Relacionado: en la comparativa de Jenkins y GitHub Actions.

Paso 4: Implementar dry-run del lado del servidor. Cada tool que muta el cluster ejecuta primero kubectl apply --dry-run=server y devuelve el resultado al agente. Si el dry-run es exitoso y el cambio está dentro de lo esperado, recién ahí se aplica en serio.

Paso 5: Fijar namespace. El servidor MCP se configura con un namespace por defecto —digamos staging— y todas las operaciones se limitan a ese scope. Si el agente pide algo en prod, el servidor rechaza la solicitud.

Paso 6: Gate de aprobación humana. Para operaciones destructivas (delete, scale down a cero, modificar network policies), el servidor MCP emite una solicitud de aprobación que un humano debe confirmar. El agente queda en espera hasta que alguien dice “sí, dale”.

Cómo configurar la lista blanca de comandos permitidos

La diferencia entre un servidor MCP seguro y un desastre es la allowlist. Habilitás get, list, watch, describe y logs para que el agente pueda diagnosticar. Bloqueás delete, create, update y patch por defecto; si un caso de uso los necesita, los habilitás con condiciones.

El error de diseño más común es exponer run_kubectl(command: string) como atajo. Eso es darle al agente una shell con sudo y esperar que no la use mal. No importa qué tan bueno sea el prompt de sistema: el modelo va a alucinar algo en el momento menos oportuno, y el string se ejecuta sin validación. La allowlist no es un lujo —es la diferencia entre dormir tranquilo y despertarte a las 3 AM con el cluster en llamas.

Integración de dry-run y ámbito de namespace en el servidor MCP

Forzar dry-run en cada mutación es de esas ideas que parecen obvias pero casi nadie implementa en el primer prototipo. El servidor MCP intercepta la llamada del agente, ejecuta kubectl apply -f manifest.yaml --dry-run=server -n staging, y solo si el resultado es válido procede con la operación real. El dry-run corre con los mismos webhooks de validación que el apply real, así que si hay un error de política o de schema, explota en el dry-run y no en producción. Cubrimos ese tema en detalle en en la guía de hreflang para SEO internacional.

El namespace scoping se configura a nivel del servidor, no del agente. El agente ni siquiera sabe que existen otros namespaces. Si alguien —o algo— intenta acceder a prod, el servidor responde con un error y loguea el intento. Esto reduce el radio de explosión a un solo namespace, y si ese namespace es staging o dev, el riesgo es aceptable.

¿Qué hacer cuando el agente necesita ejecutar acciones destructivas?

Tarde o temprano el agente va a necesitar hacer algo que modifica el cluster de verdad —reiniciar un deployment, escalar pods, aplicar un cambio de configuración. Para esos casos, el servidor MCP implementa un gate de aprobación humana.

El flujo es así: el agente invoca la tool de mutación, el servidor ejecuta el dry-run, y si el cambio pasa las validaciones pero está marcado como destructivo, el servidor pausa la operación y requiere un token de aprobación explícito que un humano (o un motor de políticas) emite fuera de banda. La operación queda en estado pendiente hasta que alguien la aprueba o la rechaza. Si la aprueban, se ejecuta. Si la rechazan, el agente recibe el feedback y puede intentar otra estrategia.

Enfoque	Comando libre	Servidor MCP seguro
Exposición de herramientas	Un solo tool run_kubectl(string)	Tools tipadas por operación (get_pods, describe_svc)
Validación de argumentos	Ninguna — el string se ejecuta tal cual	Parámetros estructurados y validados por schema
Permisos por defecto	Los del kubeconfig (generalmente admin)	Read-only, allowlist explícita de verbos
Dry-run forzado	No existe	Server-side en cada mutación
Namespace scoping	Sin límite — el agente ve todo el cluster	Fijado a un namespace configurado
Aprobación de mutaciones peligrosas	No hay — el agente ejecuta y listo	Gate humano para delete, scale down, etc.
Riesgo de alucinación	Alto — un comando inventado se ejecuta sin filtro	Bajo — el agente solo puede invocar tools que existen

Ejemplos concretos de uso en un cluster real

Diagnóstico de un pod que no arranca. El agente recibe una alerta de que el pod api-gateway-7f8c9 en staging está en CrashLoopBackOff. Invoca get_pod(name="api-gateway-7f8c9", namespace="staging"), después get_logs y describe_resource. Descubre que falta una variable de entorno, se lo reporta al operador, y no toca nada más. Sin permisos de mutación, el riesgo es cero.

Escalado controlado de un deployment. El agente detecta que el deployment worker-procesos está al 90% de CPU y sugiere escalar de 3 a 5 réplicas. Invoca scale_deployment(name="worker-procesos", replicas=5, namespace="staging"). El servidor MCP ejecuta el dry-run, confirma que el deployment existe y que el namespace es correcto, y como la operación no es destructiva (escalar para arriba no rompe nada), la aplica sin pedir aprobación humana. El operador recibe una notificación de que el escalado ocurrió, pero no tuvo que intervenir.

Errores comunes al armar un servidor MCP para Kubernetes

1. Usar el kubeconfig de admin. Si el service account del servidor MCP tiene cluster-admin, la allowlist y el namespace scoping son papel mojado —el agente puede escalar privilegios si encuentra una forma de invocar un tool que no esperabas. Creá un service account dedicado con RBAC mínimo, y si el agente necesita acceso a múltiples namespaces, definilos explícitamente. Sobre eso hablamos en en la guía de OpenClaw para agentes locales.

2. No loguear las operaciones. Un servidor MCP sin audit log es un agujero negro. Si el agente hace algo raro, necesitás saber qué tool invocó, con qué parámetros, cuándo, y cuál fue el resultado. Guardá los logs en un sistema centralizado —Loki, ELK, CloudWatch— y revisalos cada tanto. (Spoiler: el agente va a intentar cosas que no esperabas, y el log es tu única defensa para debuggear.)

3. Confiar en que el prompt de sistema alcanza. “Le puse en el prompt que no borre nada” no es un control de seguridad, es un deseo. Los LLM no son deterministas y los prompts no son firewalls. La seguridad tiene que estar en el servidor MCP, no en instrucciones que el modelo puede ignorar, olvidar, o —en el peor de los casos— contradecir porque el usuario le pidió algo ambiguo.

4. Exponer tools genéricas por comodidad. “Total, es solo para staging” es la frase que precede a todos los incidentes evitables. Si exponés run_kubectl en staging, eventualmente alguien va a apuntar ese mismo servidor a producción “para probar algo rápido”. Cada tool que exponés es un vector de ataque. Menos tools, menos superficie.

Preguntas Frecuentes

¿Cómo evitar que un agente AI ejecute comandos destructivos en Kubernetes?

La única forma segura es no exponer un comando kubectl libre. Implementá un servidor MCP con tools tipadas, permisos read-only por defecto, una allowlist de verbos seguros (get, list, watch, describe), dry-run forzado en cada mutación, y un gate de aprobación humana para operaciones destructivas. El agente solo puede invocar tools que existen, con parámetros validados.

¿Qué es el Model Context Protocol para Kubernetes?

Es un protocolo que permite a agentes de IA —como Claude o un asistente en un IDE— descubrir y llamar herramientas de Kubernetes con argumentos estructurados. En vez de pasar un string libre a kubectl, el agente invoca funciones tipadas como get_pods(namespace) o describe_deployment(name) que el servidor MCP valida antes de ejecutar contra el cluster.

¿Por qué no usar un comando kubectl libre en un agente AI?

Porque los LLM alucinan comandos, inventan flags y nombres de recursos, y entran en bucles de reintento que amplifican el daño. Un run_kubectl(command: string) sin validación es equivalente a darle una shell con permisos de admin a un sistema que no es determinista. El riesgo de un kubectl delete ns prod accidental es real y documentado.

¿Qué herramientas necesito para crear un MCP server en Kubernetes?

Necesitás el SDK de MCP (disponible en Python y TypeScript), un cluster de Kubernetes con un kubeconfig dedicado, y un service account con RBAC mínimo. El servidor se despliega como un proceso que expone tools al host MCP —Claude Desktop, un IDE, o un orquestador— y traduce las invocaciones en comandos kubectl validados y controlados.

¿Qué hace el dry-run del lado del servidor en un MCP server?

El dry-run forzado ejecuta cada mutación con --dry-run=server antes de aplicarla al cluster. Esto valida el manifiesto contra los webhooks de admisión y las políticas del cluster sin modificar nada. Si el dry-run falla, la operación se rechaza. Si pasa, el servidor decide si procede o si requiere aprobación humana según la peligrosidad del cambio.

Conclusión

Un agente de IA con acceso a Kubernetes es una herramienta potente —si está bien contenida. El patrón que se consolidó en 2026 es claro: MCP server con tools tipadas, read-only por defecto, allowlist, dry-run y gate humano. No es más trabajo que armar un wrapper de kubectl genérico, y la diferencia es que el wrapper genérico te va a explotar en la cara en el momento menos oportuno.

Si estás armando infraestructura para agentes en tu cluster, empezá por el servidor MCP seguro. Si ya tenés algo corriendo con un run_kubectl libre, poné un namespace de staging, ajustá el RBAC, y empezá a migrar antes de que el agente aprenda a borrar cosas que no debería. El tiempo que le dediques ahora te ahorra el incidente que te va a despertar un domingo a las 4 de la mañana.

Fuentes

• Build a Kubernetes MCP Server: Safe kubectl Access for AI Agents – dev.to — guía práctica con el diseño completo del servidor MCP seguro.
• Model Context Protocol – documentación oficial — especificación del protocolo MCP de Anthropic.
• kubectl Reference – Kubernetes documentation — documentación oficial de comandos kubectl y flags disponibles.