Nasazení MCP serverů v Kubernetes: architektura a JWT

# Centralizované nasazení MCP serverů v Kubernetes: architektura, autentizace a správa tajemství

Lokální spuštění MCP serverů prostřednictvím balíčkových manažerů nebo kontejnerů se rychle stává úzkým místem při škálování AI infrastruktury na tým. Rozptýlené runtime prostředí, nekontrolované šíření přihlašovacích údajů a absence jediné vstupní body blokují bezpečnou integraci jazykových modelů do firemního okruhu. V tomto článku je rozebrán praktický postup migrace od izolovaných instancí k centralizované architektuře v Kubernetes s využitím sidecar proxy, validace JWT a orchestrace tajemství.

Evoluce architektury: od lokálních procesů k kontejnerizaci

Na počáteční fázi zavádění Model Context Protocol stačí použít připravené remote endpointy od dodavatelů. Konfigurace se omezí na zadání URL v klientské aplikaci, zatímco autentizaci a škálování přebírá poskytovatel. Při připojování interních systémů (Kubernetes, Grafana, databáze) však vzniká potřeba spouštět servery samostatně.

Standardní přístup přes lokální volání npx, uvx nebo kompilovaných binárních souborů vytváří problém se správou závislostí. Každá integrace vyžaduje samostatné runtime prostředí, což vede ke konfliktům verzí a zkomplikuje onboarding nových zaměstnanců. Navíc ukládání tokenů přístupu k produkčním prostředím do lokálních konfiguračních souborů porušuje základní principy informační bezpečnosti.

Kontejnerizace řeší problém izolace prostředí. Spuštění každého MCP serveru v samostatném kontejneru s prohlašováním proměnných prostředí umožňuje standardizovat nasazení na úrovni jedné pracovní stanice. Příklad konfigurace pro izolované spuštění:

{
  "mcpServers": {
    "grafana": {
      "command": "docker",
      "args": [
        "run", "--rm", "-i",
        "-e", "GRAFANA_URL",
        "-e", "GRAFANA_SERVICE_ACCOUNT_TOKEN",
        "grafana/mcp-grafana",
        "-t", "stdio"
      ],
      "env": {
        "GRAFANA_URL": "https://grafana.example.com",
        "GRAFANA_SERVICE_ACCOUNT_TOKEN": "<token>"
      }
    }
  }
}

Navzdory zlepšení izolace lokální Docker nevyřešuje úkol kolektivního přístupu. Automatizované pipeline, CI/CD systémy a netechničtí specialisté nemohou efektivně interagovat s rozptýlenými kontejnery. Vzniká potřeba přesunout MCP servery do společné infrastruktury s centralizovanou správou životního cyklu.

Orchestrace v Kubernetes: proxy a univerzální nasazení

Přesun MCP serverů do klastru vyžaduje řešení architektoní nekompatibility: většina serverů pracuje přes stdio, zatímco síťová interakce v Kubernetes je založena na HTTP a HTTPS. K odstranění tohoto rozporu se používá sidecar pattern s využitím MCP Gateway. Proxy kontejner přijímá příchozí HTTP požadavky (Streamable HTTP nebo SSE), převádí je do standardního vstupního proudu cílového procesu a vrací odpověď zpět do sítě.

Protože MCP servery v režimu Streamable HTTP jsou stateless služby, ideálně se hodí pro horizontální škálování přes HPA. Aby se zabránilo duplikování manifestů pro každou integraci, je vhodné použít univerzální Helm chart, který podporuje dva režimy provozu:

• proxy — spuštění sidecar kontejneru pro převod HTTP na stdio.
• native — přímé vystavení služeb, které již podporují HTTP transport.

Konfigurace nasazení přes values.yaml umožňuje flexibilní správu síťových nastavení, prohlašování tajemství a směrování:

mode: proxy
proxy:
  image:
    repository: node
    tag: "20-bookworm"
    pullPolicy: IfNotPresent
  gateway:
    package: "@michlyn/mcpgateway"
    stdioCommand: "npx -y @digitalocean/mcp --services apps,droplets,doks,networking"
    outputTransport: streamable-http
    port: 8080
    httpPath: /mcp
vault:
  enabled: true
  role: "mcp"
  path: "kubernetes_dev-fra1-01"
env:
  - name: DIGITALOCEAN_API_TOKEN
    value: vault:devops/data/ai/mcp/digitalocean#token
ingress:
  enabled: true
  className: "internal"
  annotations:
    nginx.ingress.kubernetes.io/proxy-buffering: "off"
    nginx.ingress.kubernetes.io/proxy-http-version: "1.1"
    nginx.ingress.kubernetes.io/proxy-read-timeout: "3600"

Integrace s HashiCorp Vault nebo External Secrets Operator zaručuje, že přihlašovací údaje se nedostanou do systému kontroly verzí. Ingress controller nebo Gateway API zajišťuje směrování, zatímco vypnutí bufrizace a zvýšení timeoutů je nutné pro správnou funkci dlouhodobých spojení a streamování dat.

Bezpečnost a autentizace: JWT, Envoy a správa přístupu

Absence vestavěných mechanismů autentizace v samotném protokolu MCP vyžaduje implementaci ochrany na úrovni infrastrukturního šgateway. Základní autentizace nenabízí dostatečnou úroveň bezpečnosti pro firemní prostředí, proto je optimální volbou validace JWT přes Envoy Gateway. Šgateway kontroluje podpis tokenu, vydavatele a publikum dříve, než požadavek dosáhne podu s MCP serverem.

Generování klíčů a tokenů probíhá standardními kryptografickými nástroji. Veřejný klíč se zabalí do formátu JWKS a umístí do ConfigMap, odkud ho Envoy načte pro ověření:

# Generace RSA klíčů a vytvoření JWT
openssl genrsa -out mcp-jwt-private.pem 4096
openssl rsa -in mcp-jwt-private.pem -pubout -out mcp-jwt-public.pem
KID=$(openssl rand -hex 16)
HEADER=$(echo -n "{\"alg\":\"RS256\",\"typ\":\"JWT\",\"kid\":\"${KID}\"}" | base64 -w0 | tr '+/' '-_' | tr -d '=')
PAYLOAD=$(echo -n "{\"sub\":\"claude-desktop\",\"aud\":\"mcp-servers\",\"iss\":\"https://your-domain.com\",\"iat\":$(date +%s),\"exp\":$(( $(date +%s) + 31536000 ))}" | base64 -w0 | tr '+/' '-_' | tr -d '=')
SIGNATURE=$(echo -n "${HEADER}.${PAYLOAD}" | openssl dgst -sha256 -sign mcp-jwt-private.pem | base64 -w0 | tr '+/' '-_' | tr -d '=')
echo "${HEADER}.${PAYLOAD}.${SIGNATURE}"

Na současné úrovni vývoje protokolu zůstává řada architektoních omezení. Přístup k cílovým systémům probíhá přes jednotné servisní účty, což je přijatelné pro čtení, ale vytváří rizika při zápisech. Protokol nepřenáší kontext koncového uživatele, což blokuje uživatelskou autorizaci a detailní audit volání nástrojů. Logování na úrovni Envoy zachycuje jen síťové metadata, ne parametry volání konkrétních MCP metod.

Co je důležité

• Lokální spuštění MCP serverů se nesháluje na tým kvůli konfliktům runtime a riziku úniku přihlašovacích údajů.
• Sidecar pattern s MCP Gateway řeší nekompatibilitu stdio transportu a síťových protokolů Kubernetes.
• Stateless architektura Streamable HTTP umožňuje použít standardní HPA pro automatické horizontální škálování.
• Validaci JWT a směrování je třeba vyvést na úroveň API Gateway, protože protokol sám o sobě nemá mechanismy autentizace.
• Absence přenosu uživatelského kontextu v MCP zatím omezuje možnosti granulární autorizace a end-to-end auditu.

— Editorial Team