Model Context Protocol (MCP) sur OpenShift : L'Architecture Sécurisée pour Connecter vos Agents IA au SI d'Entreprise

L’avènement des systèmes d’agents autonomes (agentic workflows) en entreprise marque une rupture fondamentale : les modèles de fondation (LLMs) ne se contentent plus de générer du texte, ils agissent directement sur l’environnement opérationnel en exécutant des actions (tool calling), en interrogeant des bases de données de production, en déclenchant des pipelines GitOps ou en modifiant des configurations d’infrastructure.

Cependant, l’intégration historique des outils reposait sur des connecteurs ad-hoc, des wrappers REST propriétaires et des SDKs dispersés, créant une surface d’attaque critique et un cauchemar de maintenance.

Le Model Context Protocol (MCP), désormais standard ouvert plébiscité par l’industrie, résout ce défi en fournissant un protocole universel client-serveur pour exposer du contexte, des prompts et des outils aux agents IA. Mais en environnement d’entreprise régulé (bancaire, santé, défense, industrie), brancher un agent IA sur un serveur MCP ne peut se faire sans une gouvernance d’infrastructure stricte.

Découvrez comment concevoir, conteneuriser et sécuriser une architecture MCP Zero-Trust sur Red Hat OpenShift et OpenShift AI (RHOAI).

---

1. Pourquoi le Model Context Protocol (MCP) Change la Donne

Le protocole MCP repose sur une séparation nette entre l’hôte (Host Application / Agent), le client MCP et les serveurs MCP (MCP Servers) fournissant les capacités :

• Resources (Ressources) : Flux de données passifs en lecture seule (fichiers logs, schémas de BDD, métriques Prometheus).
• Tools (Outils) : Fonctions exécutables avec effets de bord contrôlés (requête SQL, rollback de déploiement ArgoCD, génération de ticket Jira).
• Prompts : Modèles d’instructions dynamiques contextualisés par le serveur MCP.

┌─────────────────────────────────────────────────────────────────────────────┐
│                   Agent IA / Llama Stack / Client MCP                       │
│                     (Pod sur OpenShift AI / RHOAI)                          │
└──────────────────────────────────────┬──────────────────────────────────────┘
                                       │
            Transport Sécurisé (mTLS / HTTP SSE / JSON-RPC 2.0)
                                       │
┌──────────────────────────────────────▼──────────────────────────────────────┐
│                    Passerelle MCP & Ingress Sécurisée                       │
│              (OpenShift Service Mesh / Istio + Envoy Filter)                │
└──────────────┬───────────────────────┬───────────────────────┬──────────────┘
               │                       │                       │
               ▼                       ▼                       ▼
    ┌──────────────────────┐┌──────────────────────┐┌──────────────────────┐
    │ MCP Server: OpenShift││ MCP Server: Database ││  MCP Server: GitOps  │
    │  API & Cluster Ops   ││    (PostgreSQL)      ││   (ArgoCD / Tekton)  │
    └──────────────────────┘└──────────────────────┘└──────────────────────┘

Contrairement au protocole stdio conçu pour des environnements postes de travail (workstations), l’architecture cloud-native d’entreprise impose le transport HTTP avec Server-Sent Events (SSE) ou gRPC/WebSocket, encapsulé dans un maillage de services Kubernetes.

---

2. Risques de Sécurité et Menaces Spécifiques aux Serveurs MCP

Brancher des agents autonomes sur des serveurs d’outils introduit des vulnérabilités critiques répertoriées dans l’OWASP Top 10 for LLMs :

1. Injection de Prompts Indirecte (Indirect Prompt Injection) : Un contenu non vérifié ingéré via une Resource MCP détourne les instructions du modèle pour invoquer des Tools destructeurs.
2. Élévation de Privilèges par Rebond (Privilege Escalation) : L’agent dispose d’un jeton de service sur-dimensionné lui permettant d’exécuter des actions d’administration non autorisées à l’utilisateur final.
3. Fuite de Données Sensibles (Data Exfiltration) : Exfiltration de secrets d’infrastructure via des paramètres d’outils externes ou des requêtes réseau non supervisées.
4. Déni de Service & Boucles Infinies (Tool Execution Loops) : Exécution récursive incontrôlée d’appels d’outils saturant les backends.

---

3. Architecture de Déploiement Sécurisée sur Red Hat OpenShift

Pour neutraliser ces menaces, l’implémentation MCP en entreprise repose sur 4 piliers d’infrastructure :

A. Isolation Réseau et Authentification mTLS (OpenShift Service Mesh)

Chaque serveur MCP est déployé dans son propre Namespace dédié, isolé par des NetworkPolicies strictes et intégré dans OpenShift Service Mesh (Istio) avec chiffrement mutuel mTLS et injection de Sidecars Envoy.

B. Authentification OAuth2 / OIDC & Token Exchange

L’agent ne transmet jamais ses propres identifiants d’infrastructure. Une passerelle d’authentification (Red Hat Single Sign-On / Keycloak) procède à un échange de jetons (Token Exchange RFC 8693) pour restreindre la portée (scope) du jeton transmis au serveur MCP aux seuls droits de l’utilisateur ayant sollicité l’agent.

C. Surveillance eBPF à l’Exécution (Red Hat Advanced Cluster Security - RHACS)

RHACS surveille en temps réel les appels système (syscalls) générés par les conteneurs de serveurs MCP via ses sondes eBPF. Tout fork inattendu, ouverture de socket réseau vers une IP publique non déclarée ou modification de fichier binaire déclenche un arrêt instantané du Pod (Process Baseline Enforcement).

D. Filtrage des Entrées/Sorties avec Guardrails (TrustyAI & Granite Guardian)

Avant que l’argument d’un outil ne soit envoyé au serveur MCP ou que la réponse ne soit réinjectée dans le contexte du LLM, une couche de validation évalue la toxicité, la conformité PII (données personnelles) et l’absence de tentatives d’injection.

---

4. Manifestes Kubernetes de Production : Déployer un Serveur MCP Sécurisé

Voici le déploiement déclaratif d’un serveur MCP PostgreSQL hautement sécurisé sur OpenShift :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: mcp-server-postgres
  namespace: ai-agents-prod
  labels:
    app.kubernetes.io/name: mcp-server-postgres
    app.kubernetes.io/part-of: agentic-platform
spec:
  replicas: 2
  selector:
    matchLabels:
      app: mcp-server-postgres
  template:
    metadata:
      labels:
        app: mcp-server-postgres
        sidecar.istio.io/inject: "true"
    spec:
      serviceAccountName: mcp-postgres-sa
      securityContext:
        runAsNonRoot: true
        seccompProfile:
          type: RuntimeDefault
      containers:
      - name: mcp-server
        image: registry.internal.aperta.ch/ai/mcp-postgres-sse:1.2.0
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 8080
          name: http-sse
        env:
        - name: MCP_TRANSPORT
          value: "sse"
        - name: DATABASE_URL
          valueFrom:
            secretKeyRef:
              name: pg-readonly-credentials
              key: connection_string
        securityContext:
          allowPrivilegeEscalation: false
          readOnlyRootFilesystem: true
          capabilities:
            drop:
            - ALL
        resources:
          limits:
            cpu: "500m"
            memory: "512Mi"
          requests:
            cpu: "100m"
            memory: "128Mi"
        livenessProbe:
          httpGet:
            path: /healthz
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 10

Et la politique réseau associée interdisant tout trafic sortant non autorisé :

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: mcp-server-postgres-isolation
  namespace: ai-agents-prod
spec:
  podSelector:
    matchLabels:
      app: mcp-server-postgres
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app.kubernetes.io/name: rhoai-llama-stack-agent
    ports:
    - protocol: TCP
      port: 8080
  egress:
  - to:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: database-prod
    ports:
    - protocol: TCP
      port: 5432
  - to: # Autoriser uniquement le DNS interne OpenShift
    - namespaceSelector: {}
      podSelector:
        matchLabels:
          k8s-app: kube-dns
    ports:
    - protocol: UDP
      port: 53

---

5. Comparatif des Approches d’Intégration d’Outils pour Agents IA

Critère	API REST / Plugins Sur-Mesure	Serveur MCP Local (Desktop stdio)	MCP Cloud-Native sur OpenShift & RHOAI
Standardisation	Faible (spécifique à chaque framework LangChain/LlamaIndex)	Élevée (spécification MCP JSON-RPC)	Maximale (spécification MCP universelle + intégration Llama Stack)
Sécurité Réseau	Disparate (souvent HTTP sans mTLS)	Aucune (exécution sur le poste utilisateur)	Chiffrement mTLS mûr, Service Mesh, NetworkPolicies Zero-Trust
Audit & Contrôle d’Accès	Jeton statique partagé	Droits du compte utilisateur local	Token Exchange OAuth2, RBAC Kubernetes, Process Baselines RHACS
Scalabilité & Résilience	Gestion manuelle	Mono-utilisateur	Haute disponibilité Kubernetes, réplication automatique, auto-healing
Gouvernance & Guardrails	Code applicatif sur mesure	Absent	Inspection TrustyAI, modération Granite Guardian et traçabilité OpenTelemetry

---

6. Guide d’Implémentation pour les Équipes Plateforme & Sécurité

Pour industrialiser vos serveurs MCP en production :

1. Bannissez le mode stdio en production : Utilisez systématiquement le transport SSE sur HTTPS avec terminaison TLS contrôlée.
2. Appliquez le principe du moindre privilège aux bases de données : Le serveur MCP dédié aux requêtes analytiques ne doit disposer que d’un utilisateur SQL en lecture seule (SELECT uniquement sur une vue ou un schéma anonymisé).
3. Tracez chaque exécution d’outil avec OpenTelemetry : Corrélez le TraceID de la requête utilisateur avec l’appel d’outil MCP pour garantir une auditabilité complète en cas d’incident.
4. Isolez les serveurs MCP exécutant du code : Pour les serveurs MCP d’exécution Python/Bash (code interpreter), utilisez des moteurs de conteneurs sandboxed comme Kata Containers ou OpenShift Virtualization afin d’empêcher toute fuite vers le noyau de l’hôte.

---

Industrialisez vos Architectures d’Agents IA avec Aperta Scientia

La sécurisation et l’orchestration des agents IA d’entreprise nécessitent une synergie parfaite entre les compétences Cloud-Native Kubernetes et l’ingénierie des systèmes d’IA.

Aperta Scientia prépare vos équipes aux défis d’infrastructure de pointe :

• AS300 — AI Platform Engineer : Le cursus d’élite de 3 mois pour maîtriser le déploiement d’OpenShift AI (RHOAI), l’intégration sécurisée du Model Context Protocol (MCP), le serving LLM avec vLLM, les bases vectorielles Milvus, et la gouvernance avec TrustyAI.
• AS200 — New DevOps Platform Engineer : Le cursus fondamental pour concevoir des clusters Red Hat OpenShift résilients, automatiser en GitOps (ArgoCD), sécuriser avec RHACS et administrer les réseaux multi-clusters avec RHACM.