Déployer un serveur MCP EKS sécurisé et prêt pour la production pour administrer des clusters EKS via le langage naturel

2025-08-14 1664 mots 8 minutes

/images/eks-mcp-server/featuredimage.png

Contenu

Les agents IA ouvrent aujourd’hui des perspectives fascinantes, notamment lorsqu’ils ont accès à des outils externes via des API. C’est là que réside leur plein potentiel : nous pouvons désormais passer de la simple génération de texte à l’exécution d’actions concrètes sur des systèmes tels que les infrastructures Cloud.

Dans cet article, j’explorerai comment déployer et administrer des infrastructures Cloud, telles que les clusters Kubernetes, en langage naturel, tout en garantissant la sécurité et l’industrialisation.

Introduction

Je me suis donc posé la question suivante :

Comment pouvons-nous déployer et administrer des infrastructures Cloud, telles que les clusters Kubernetes, en langage naturel, tout en garantissant la sécurité et l’industrialisation ?

C’est la question à laquelle j’ai voulu répondre en travaillant sur une démonstration : déployer un serveur MCP capable d’administrer un cluster AWS EKS en langage naturel, tout en respectant les contraintes de sécurité et d’architecture d’un système d’information d’entreprise.

Qu’est-ce que le Model Context Protocol (MCP) ?

Le Model Context Protocol (MCP) est un protocole proposé par Anthropic, qui définit un format standardisé permettant aux LLM d’interagir avec des outils ou des environnements.

En d’autres termes, ce protocole fait le pont entre les capacités conversationnelles des LLM et les systèmes d’action sur des systèmes tels que les API, les bases de données, ou ici, les clusters Kubernetes.

Source : descope.com

Pourquoi une version sécurisée du serveur MCP EKS ?

Dans ce projet, j’ai voulu explorer comment un serveur MCP pourrait être déployé à distance, de manière sécurisée et dans un environnement d’entreprise. Je me suis donc lancé dans le déploiement d’un serveur MCP capable d’administrer un cluster EKS (Elastic Kubernetes Service) à la demande, via un client MCP (Claude Desktop).

Il y a quelques semaines, j’ai découvert qu’AWS avait publié un nouveau serveur MCP : Amazon EKS MCP Server. Ce serveur offre une interface MCP avec des outils pour l’administration directe de clusters EKS (Elastic Kubernetes Service) via un LLM.

Cependant, dans sa version originale, ce serveur était conçu pour un usage local, en mode stdio, et n’intègre aucun mécanisme d’authentification. Il est donc difficile de l’utiliser dans des environnements cloud d’entreprise, où la sécurité et la traçabilité sont essentielles.

Modifications clés apportées

Je me suis donc attelé à modifier le code source du serveur pour :

Activer l’exécution à distance en activant le mode de communication HTTP Server-Side Events (SSE)
Définir des health checks afin qu’il puisse être exposé via un ALB
Ajouter une couche d’authentification basée sur OAuth 2.0, pour restreindre et sécuriser l’accès au serveur
Ajouter des fonctions supplémentaires, notamment pour gérer les enregistrements DNS sur Route53
Maintenir la compatibilité avec les clients MCP standards, tels que Claude Desktop

L’objectif ultime est simple : administrer des clusters EKS en langage naturel, de manière sécurisée.

Concrètement, cela signifie pouvoir envoyer des instructions telles que :

“Déploie un nouveau service X sur mon cluster haute disponibilité et expose-le”
“Quel est l’état de mon cluster ? Quelles optimisations pourraient être faites ?”
“Pourquoi mon déploiement Y ne fonctionne-t-il pas ?”

…depuis un client comme Claude Desktop, et voir ces actions exécutées sur une infrastructure AWS, sans écrire une seule ligne de YAML ni toucher à kubectl.

Architecture de la solution

En discutant avec mon collègue Pierre-Ange, j’ai appris qu’AWS avait publié un guide de bonnes pratiques pour déployer de manière sécurisée des serveurs MCP sur leur infrastructure. Ce guide est accessible sur le dépôt GitHub suivant : aws-solutions-library-samples/guidance-for-deploying-model-context-protocol-servers-on-aws

Plutôt que de réinventer la roue, je me suis inspiré de l’architecture proposée par AWS, en l’adaptant à mes propres besoins pour le déploiement de mon serveur MCP EKS modifié.

Architecture du serveur MCP EKS sécurisé

Composants clés

L’architecture comprend :

ECS Fargate pour déployer facilement les serveurs MCP et fournir une scalabilité horizontale, permettant à plusieurs clients MCP de se connecter au service
Authentification OAuth 2.0 via Cognito et un serveur d’authentification (MAS) pour décharger et mutualiser les mécanismes d’authentification des serveurs MCP, avec une table DynamoDB pour stocker les tokens
Distribution CloudFront avec un WAF (Web Application Firewall) devant un ALB pour exposer de manière sécurisée les serveurs MCP et les rendre accessibles depuis les clients MCP
Permissions IAM au moindre privilège pour restreindre ce que le serveur peut faire sur le compte AWS
Un cluster EKS Auto Mode, pour un accès direct aux contrôleurs de gestion réseau, stockage et nœuds

Pour en savoir plus sur EKS Auto Mode, j’ai écrit un article il y a quelques mois sur ce nouveau mode de gestion de cluster EKS : EKS Auto Mode : ce qu’il faut savoir avant de faire le pas

Configuration de l’authentification OAuth 2.0

Une fois l’architecture décrite ci-dessus implémentée avec Terraform, j’ai dû itérer plusieurs fois sur la configuration du serveur MCP modifié, notamment sur la gestion de l’authentification OAuth 2.0.

Configuration du client MCP

Tout d’abord, pour permettre au client MCP Claude Desktop de se connecter à mon serveur MCP distant, une configuration de serveur MCP doit être définie dans son fichier de configuration (claude_desktop_config.json pour Claude Desktop). Notamment, pour spécifier l’adresse du serveur MCP et le fait qu’il peut être accessible à distance (mcp-remote).

Voici à quoi ressemble mon fichier de configuration :

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

Flux d’authentification

Le processus d’authentification suit ces étapes :

Lorsque le client MCP Claude Desktop est lancé, le serveur MCP renvoie un code HTTP 401, indiquant qu’une authentification est requise pour l’accès
Le navigateur web par défaut s’ouvre automatiquement
L’utilisateur est redirigé vers l’URL d’autorisation OAuth définie sur le serveur
Et redirige vers une page de connexion gérée par AWS Cognito

Cela suit les spécifications du protocole MCP définies dans la documentation MCP Authorization.

Diagramme du flux d’authentification OAuth 2.0

Pour cette démonstration, j’ai utilisé AWS Cognito comme IdP (Identity Provider), avec un User Pool contenant mon utilisateur (email/mot de passe). Cependant, il est tout à fait possible (et même recommandé) de se connecter à l’IdP de l’entreprise, tel qu’un Entra ID, par exemple.

Une fois authentifié, le token est automatiquement renvoyé au client MCP. Le client peut alors échanger des données avec le serveur MCP, et profiter des fonctionnalités du serveur.

Expérience utilisateur

Concrètement, côté utilisateur :

J’ouvre Claude Desktop, mon navigateur s’ouvre et me redirige vers une page de connexion gérée avec AWS Cognito :

Je me connecte avec mon adresse email et mon mot de passe :

Je reviens sur Claude Desktop et confirme que la connexion à mon serveur MCP EKS est fonctionnelle :

Gestion des permissions pour administrer un cluster EKS

Maintenant que Claude Desktop est connecté de manière sécurisée à mon serveur MCP, il reste une étape importante : Donner au serveur MCP les permissions nécessaires pour administrer le cluster EKS.

Le serveur MCP est déployé sur une tâche Fargate (ECS). Pour lui permettre d’interagir avec l’API AWS, cette tâche se voit attribuer un rôle IAM avec toutes les permissions requises pour administrer un cluster EKS.

Parallèlement, j’ai configuré un EKS Access Entry qui donne au rôle IAM de ma tâche ECS les droits d’administrateur sur le cluster Kubernetes. Bien sûr, il est important de définir les permissions de ce rôle au moindre privilège, mais pour les besoins de cette démonstration, j’ai activé les droits d’administrateur EKS pour simplifier.

Jouons ! 🕹️

Une fois ces prérequis en place, mon serveur MCP EKS est autorisé à interagir avec le cluster EKS. En amont, je peux configurer le contexte pour faciliter la prise de décision de mon LLM. Je peux maintenant formuler des instructions en langage naturel avec Claude.

Exemple 1 : Déploiement d’un jeu vidéo (Sonic 🦔🎮)

“Déploie le jeu Sonic basé sur cette image docker : dazdaz/sonic. Le conteneur écoute sur le port 8080”

Cette action est traduite par le LLM en une séquence d’appels à l’API Kubernetes, exécutée par le serveur MCP EKS :

Et après quelques minutes :

Exemple 2 : Analyse de l’état du cluster et recommandations

Un autre exemple :

“Quel est l’état de mon cluster ? Quelles optimisations pourraient être faites ?”

Je vous laisse admirer le résultat, qui, je l’avoue, m’a époustouflé par sa véracité et sa rapidité d’analyse la première fois :

Notez que j’utilise uniquement un modèle fondation (Claude 4 Sonnet). Ce qui signifie que le résultat pourrait être encore meilleur si nous utilisions un modèle personnalisé, un modèle fine-tuné, ou du RAG pour avoir un modèle expert EKS et une meilleure connaissance de son environnement.

Conclusion

Pour conclure cet article, nous avons montré qu’il est possible aujourd’hui d’industrialiser des solutions agentiques basées sur des serveurs MCP pour gérer des infrastructures Cloud, dans ce cas sur AWS.

En utilisant l’exemple d’un serveur MCP EKS et en l’intégrant dans une architecture AWS sécurisée et résiliente, nous avons montré qu’il n’est pas seulement faisable de gérer des clusters Kubernetes de manière conversationnelle, mais aussi de le faire tout en respectant les standards de sécurité, d’opérabilité et de scalabilité requis par les entreprises.

L’automatisation et l’interaction simplifiée offertes par ce type de solution via le langage naturel et les agents IA ouvrent la voie à une nouvelle ère de gestion d’infrastructure, où la complexité est abstraite et les performances améliorées.

Pistes d’amélioration

Pour aller plus loin et se rapprocher des pratiques métier, les pistes d’amélioration incluraient :

Déployer des serveurs MCP spécialisés pour interagir avec des outils comme Terraform (IaC), ArgoCD (GitOps) ou un SCM comme GitHub ou GitLab. Pour garder une trace des différents codes et configurations générés et appliqués par les agents IA.
Tracer, auditer et versionner les opérations effectuées par les agents IA pour garantir une conformité continue.
Améliorer les performances des agents via des modèles spécialisés, en utilisant des approches telles que le fine-tuning, l’intégration de modèles propriétaires personnalisés, ou le Retrieval-Augmented Generation (RAG) pour fournir un LLM, capable de prendre des décisions précises basées sur l’état réel de l’infrastructure globale et son historique.