Despliega un servidor MCP seguro para gestionar clústeres de EKS usando lenguaje natural.

Agentes de IA: de la generación de texto a la acción en sistemas Cloud

Los agentes de IA actuales abren perspectivas fascinantes, sobre todo cuando tienen acceso a herramientas externas mediante APIs. Es ahí donde reside su verdadero potencial. Ahora podemos pasar de la simple generación de texto a la ejecución de acciones concretas en sistemas como infraestructuras Cloud.

Sin embargo, aún existe una brecha entre las demostraciones de agentes basados en LLM y su implementación real en los sistemas de información empresariales.

Así que me hice la siguiente pregunta:

¿Cómo podemos desplegar y administrar infraestructuras Cloud, como clústeres de Kubernetes, usando lenguaje natural, garantizando al mismo tiempo seguridad e industrialización?

A esta pregunta quise responder con una demostración: desplegar un servidor MCP capaz de administrar un clúster AWS EKS en lenguaje natural, cumpliendo con las restricciones de seguridad y arquitectura de un sistema de información corporativo.

¿Qué es el Model Context Protocol (MCP)?

El Model Context Protocol (MCP) es un protocolo propuesto por Anthropic. Define una forma estandarizada de que los LLM interactúen con herramientas o entornos.

En otras palabras, este protocolo conecta las capacidades conversacionales de los LLM con sistemas de acción como APIs, bases de datos o, en este caso, clústeres de Kubernetes.

Source: descope.com (https://www.descope.com/learn/post/mcp)

¿Por qué un servidor MCP seguro?

En este proyecto, quise explorar cómo desplegar un servidor MCP de forma remota, segura y en un entorno empresarial. Así que trabajé en el despliegue de un servidor MCP seguro capaz de administrar un clúster AWS EKS bajo demanda, desde un cliente MCP (Claude Desktop).

Hace unas semanas descubrí que AWS había publicado un nuevo servidor MCP: Amazon EKS MCP Server. Este servidor ofrece una interfaz MCP con herramientas para la administración directa de clústeres EKS mediante un LLM.

Sin embargo, su versión original está pensada para uso local (modo stdio) y no integra ningún mecanismo de autenticación. Esto dificulta su uso en entornos Cloud empresariales, donde la seguridad y la trazabilidad son clave.

Así que modifiqué el código fuente del servidor para:

• Permitir la ejecución remota activando el modo de comunicación HTTP Server-Sent Events (SSE).
• Definir health checks para exponerlo mediante un ALB.
• Añadir una capa de autenticación basada en OAuth 2.0, para restringir y proteger el acceso.
• Añadir funciones adicionales, como la gestión de registros DNS en Route53.
• Mantener la compatibilidad con clientes MCP estándar, como Claude Desktop.

El objetivo es simple: administrar clústeres EKS con lenguaje natural, de forma segura.

En concreto, poder dar instrucciones como:

• “Despliega un nuevo servicio X en mi clúster de alta disponibilidad y expónlo”
• “¿Cuál es el estado de mi clúster? ¿Qué optimizaciones se podrían aplicar?”
• “¿Por qué no funciona mi despliegue Y?”

…desde un cliente como Claude Desktop, y ver cómo estas acciones se ejecutan en una infraestructura AWS, sin escribir ni una línea de YAML ni usar kubectl.n an AWS infrastructure, without writing a single line of yaml or touching kubectl.

Arquitectura de la solución: Servidor MCP seguro

Hablando con mi compañero Pierre-Ange, supe que AWS había publicado una guía de buenas prácticas para desplegar servidores MCP seguros en su infraestructura:

GitHub: aws-solutions-library-samples/guidance-for-deploying-model-context-protocol-servers-on-aws

Me inspiré en la arquitectura propuesta por AWS y la adapté a mis necesidades para desplegar mi versión modificada del servidor MCP para EKS.

Incluye:

• Uso de ECS Fargate para desplegar servidores MCP con escalado horizontal, permitiendo múltiples conexiones simultáneas.
• Autenticación OAuth 2.0 vía Cognito y un servidor de autenticación (MAS), con una tabla DynamoDB para almacenar los tokens.
• Distribución CloudFront con WAF frente a un ALB, para exponer el servidor MCP de forma segura.
• Permisos IAM mínimos necesarios (least privilege).
• Un clúster EKS en modo Auto, con acceso directo a los controladores de red, almacenamiento y nodos.

Architecture diagram of the implemented solution, inspired by the one proposed by AWS

Configuración de la autenticación OAuth 2.0

Una vez implementada la arquitectura descrita anteriormente con Terraform, tuve que iterar varias veces sobre la configuración del servidor MCP modificado, especialmente en la gestión de la autenticación OAuth 2.0.

En primer lugar, para que el cliente MCP de Claude Desktop pudiera conectarse a mi servidor MCP remoto, era necesario definir una configuración del servidor MCP en su archivo de configuración (claude_desktop_config.json, en el caso de Claude Desktop). En concreto, para especificar la dirección del servidor MCP y el hecho de que se puede acceder a él de forma remota (mcp-remote).

Así es como se ve mi archivo de configuración:

{
  "mcpServers": {
    "eks": {
      "command": "npx",
      "args": [
        "-y",
        "mcp-remote", 
        "https://eks-mcp-server.exemple.com/sse"
      ]
    }
  }
}

Cuando se lanza el cliente MCP de Claude Desktop, el servidor MCP devuelve un código HTTP 401. Esto indica que se requiere autenticación para acceder.

El navegador predeterminado se abre automáticamente.

El usuario es redirigido a la URL de autorización OAuth definida en el servidor.

Y, a continuación, a una página de inicio de sesión gestionada por AWS Cognito.

Esto sigue las especificaciones del protocolo MCP definidas en esta página.

Para esta demostración, utilicé AWS Cognito como proveedor de identidad (IdP), con un User Pool que contiene mi usuario (correo/contraseña). Sin embargo, es perfectamente posible (e incluso recomendable) conectar con el IdP corporativo, como por ejemplo Entra ID.

Una vez autenticado, el token se envía automáticamente al cliente MCP. A partir de ahí, el cliente puede intercambiar datos con el servidor MCP y aprovechar sus funcionalidades…

Para entenderlo con más detalle, aquí tienes un esquema que ilustra las distintas etapas del proceso de autenticación:

Concretamente, desde el lado del usuario:

Abro Claude Desktop, se abre el navegador y me redirige a una página de inicio de sesión gestionada con AWS Cognito:

2. Inicio sesión con mi dirección de correo electrónico y contraseña:

3. I return to Claude Desktop and confirm that the connection to my MCP EKS server is functional:

Gestión de permisos para administrar un clúster EKS

Ahora que Claude Desktop está conectado de forma segura a mi servidor MCP, queda un paso importante: otorgar al servidor MCP los permisos necesarios para administrar el clúster EKS.

El servidor MCP se despliega en una tarea Fargate (ECS). Para que pueda interactuar con la API de AWS, a esta tarea se le asigna un rol IAM con todos los permisos necesarios para administrar un clúster EKS.

Al mismo tiempo, configuré una entrada de acceso a EKS que otorga al rol IAM de mi tarea ECS derechos de administrador en el clúster de Kubernetes. Por supuesto, es importante aplicar el principio de mínimo privilegio en este rol, pero para los fines de esta demostración, he habilitado los permisos de administrador en EKS por simplicidad.

Servidor MCP seguro listo: ¡a jugar!

Una vez completados estos requisitos previos, mi servidor MCP seguro está autorizado para interactuar con el clúster EKS. A partir de ahí, puedo configurar el contexto para facilitar la toma de decisiones del LLM. Ahora ya puedo formular instrucciones en lenguaje natural con Claude.

Ejemplo 1: Despliegue de un videojuego – Sonic

“Despliega el juego Sonic usando esta imagen de Docker: dazdaz/sonic. El contenedor escucha en el puerto 8080”

Esta acción es traducida por el LLM en una secuencia de llamadas a la API de Kubernetes, que son ejecutadas por el servidor MCP para EKS:

Y tras unos minutos:

Ejemplo 2: Análisis del estado del clúster y recomendaciones

Otro ejemplo:

“¿Cuál es el estado de mi clúster? ¿Qué optimizaciones se podrían aplicar?”

Te dejo que admires el resultado. Confieso que la primera vez me sorprendió por su precisión y la velocidad del análisis.

Cabe destacar que estoy utilizando únicamente un modelo base (Claude 4 Sonnet). Lo que significa que el resultado podría ser aún mejor si se empleara un modelo personalizado, ajustado (fine-tuned) o con RAG, para disponer de un modelo experto en EKS y con un mayor conocimiento de su entorno.

Conclusión

Para concluir este artículo, hemos demostrado que hoy en día es posible industrializar soluciones basadas en agentes mediante servidores MCP para gestionar infraestructuras Cloud, en este caso sobre AWS.

A través del ejemplo de un servidor MCP para EKS, integrado en una arquitectura de AWS segura y resiliente, hemos mostrado que no solo es factible administrar clústeres Kubernetes de forma conversacional, sino también hacerlo cumpliendo con los estándares de seguridad, operatividad y escalabilidad que exigen las empresas.

La automatización y la interacción simplificada que ofrece este tipo de soluciones mediante lenguaje natural y agentes de IA abren la puerta a una nueva era en la gestión de infraestructuras, donde la complejidad se abstrae y el rendimiento se optimiza.

Para avanzar aún más y acercarse a las prácticas empresariales, las áreas de mejora incluirían:

• Desplegar servidores MCP especializados para interactuar con herramientas como Terraform (IaC), ArgoCD (GitOps) o un SCM como GitHub o GitLab, con el fin de seguir el rastro de los distintos códigos y configuraciones generados y aplicados por los agentes de IA.
• Rastrear, auditar y versionar las operaciones realizadas por los agentes de IA para garantizar un cumplimiento continuo.
• Mejorar el rendimiento de los agentes mediante modelos especializados, usando enfoques como el fine-tuning, la integración de modelos propietarios personalizados o Retrieval-Augmented Generation (RAG), para dotar al LLM de capacidad para tomar decisiones precisas basadas en el estado real de la infraestructura global y su historial.