MCP-Server auf Kubernetes mit kmcp und AgentGateway angehen

Wir verwenden hier kmcp mit der Version 0.1.9.

Beachten Sie bei diesem speziellen Beispiel, dass der GitHub MCP-Server ein Token benötigt, das Sie als Kubernetes-Secret bereitstellen müssen. Geben Sie den Namen Ihres Secrets in das Feld „secretRefs” ein. Der erstellte Dienst kann dann in Kombination mit einem Ingress verwendet werden, um den MCP-Server verfügbar zu machen. Andererseits können Sie auch wieder kgateway zusammen mit AgentGateway verwenden und diese mit kmcp kombinieren. Wie im AgentGateway-Beispiel angegeben, können Sie die interne Service-URL verwenden, um den MCP-Server mit kgateway freizugeben.

MCP-Authentifizierung mit OAuth2

In einem Unternehmenskontext möchten Sie Ihre MCP-Server möglicherweise nicht ohne Authentifizierung und Autorisierung öffentlich zugänglich machen. Das Protokoll ermöglicht es Ihnen, Ihre MCP-Server zu schützen und sich über OAuth2 gegenüber ihnen zu authentifizieren. Dadurch können Ihre MCP-Server und sogar Ihre MCP-Tools und -Ressourcen mit RBAC gesteuert werden. AgentGateway macht es recht einfach, einen MCP-Server mit OAuth2 einzurichten, auch wenn dies vom MCP-Server nicht nativ unterstützt wird. Dazu benötigen Sie einen Identitätsanbieter. In unseren Beispielen verwenden wir Keycloak. OAuth2 wird derzeit in AgentGateway nicht nativ unterstützt, wenn es in Kombination mit kgateway verwendet wird. Es ist möglich, eine rohe AgentGateway-Konfiguration mit kgateway bereitzustellen, was jedoch eine undokumentierte und experimentelle Funktion ist. Wir vereinfachen den Prozess hier, indem wir AgentGateway als eigenständige Lösung verwenden. Nehmen wir an, wir haben Keycloak ordnungsgemäß eingerichtet und konfiguriert und verschiedene Benutzer sowie einen Bereich für unsere MCP-Authentifizierung erstellt. Mit einem MCP-Server, der beispielsweise mit kmcp eingerichtet wurde, könnte unsere AgentGateway-Konfiguration wie folgt aussehen:

binds:
- port: 8080
  listeners:
  - routes:
      - backends:
          - mcp:
              targets:
              - name: mcp
                mcp:
                  host: http://localhost:8081/mcp/
        matches:
          - path:
              exact: /github/mcp
          - path:
              exact: /.well-known/oauth-protected-resource/github/mcp
          - path:
              exact: /.well-known/oauth-authorization-server/github/mcp
          - path:
              exact: /.well-known/oauth-authorization-server/github/mcp/client-registration
        name: mcp-github
        policies:
          cors:
            allowHeaders:
            - "*"
            allowOrigins:
            - "*"
          mcpAuthentication:
            issuer: http://keycloak.192.168.49.2.nip.io/realms/mcp
            jwksUrl: http://keycloak.192.168.49.2.nip.io/realms/mcp/protocol/openid-connect/certs
            audience: mcp_proxy
            provider:
              keycloak: {}
            resourceMetadata:
              resource: http://localhost:8080/github/mcp
              scopesSupported:
              - profile
              - offline_access
              - openid
              - email
              - roles
              bearerMethodsSupported:
              - header
              - body
              resourceDocumentation: http://localhost:8080/github/mcp/docs
          mcpAuthorization:
            rules:
            # Allow anyone to call “get_me”
            - 'mcp.tool.name == "get_me"'
            # Only the admin user can call “delete_repository”
            - 'jwt.sub = "admin" && mcp.tool.name == "delete_repository"'

Dieses Beispiel umschließt die AgentGateway-Authentifizierungskonfiguration um unseren GitHub MCP-Server, der von unserem Cluster aus erreichbar ist. In der Konfiguration können Sie die für die Authentifizierung erforderlichen Keycloak-URLs definieren. Dort können Sie auch Regeln für die Autorisierung mithilfe der „Common Expression Language” (CEL) erstellen. Damit können Sie bestimmte Tools so einschränken, dass sie nur von bestimmten Benutzern oder bestimmten Gruppen aufgerufen werden können.

Wenn Ihr MCP-Client versucht, eine Verbindung zum MCP-Server herzustellen, öffnet sich ein Anmeldeformular, in dem Sie sich mit Ihren konfigurierten Benutzeranmeldedaten anmelden können. Beachten Sie, dass Ihr MCP-Client den OAuth2-Flow für MCP unterstützen muss.

Dieses Beispiel zeigt einen wichtigen Teil der MCP-Authentifizierung. Der zweite Teil umfasst die Authentifizierung gegenüber Drittanbieterdiensten. Am häufigsten wird dies mit API-Schlüsseln durchgeführt, die bei der Einrichtung des MCP-Servers konfiguriert werden. Dies ist jedoch möglicherweise kein geeigneter Ansatz für Anwendungsfälle, die einen Ansatz erfordern, der unterschiedliche Benutzerberechtigungen und Mandantenfähigkeit berücksichtigt. Im Idealfall würde der MCP-Server die Anmeldedaten der Benutzer zur Authentifizierung bei Drittanbieterdiensten verwenden und die Berechtigungen der Benutzer zum Abrufen von Daten und Aufrufen von Tools nutzen. Dies ist ein bekanntes Problem und ein aktuelles Thema im Protokoll. Auf hoher Ebene wird dies über eine MCP-Funktion namens „Elicitation” (Ermittlung) erfolgen. Dadurch kann der MCP-Server zusätzliche Benutzereingaben oder Informationen von unserem MCP-Client anfordern. In unserem Fall könnte dies für benutzergenerierte API-Schlüssel oder Token verwendet werden. Es gibt sogar eine laufende Diskussion über URL-Modus-Elicitation, die die Sicherheit dieses Workflows weiter erhöht. Die Elicitation-Funktion ist ebenfalls recht neu, was bedeutet, dass die meisten MCP-Clients sie noch nicht unterstützen, aber die Akzeptanz wächst.

Es gibt auch andere MCP-Gateways, die versuchen, dieses Problem zu lösen. LiteLLM, eine Software, die in einem anderen Blog-Artikel vorgestellt wurde, wurde aktualisiert, um MCP-Server zu unterstützen und sie mit verschiedenen Authentifizierungsmechanismen zu verbessern.

Zusammenfassung

Das Model Context Protocol (MCP) entwickelt sich rasch zu einer grundlegenden Technologie für die standardisierte und anbieterunabhängige Integration großer Sprachmodelle in externe Systeme. Während MCP-Server natürlich gut für containerisierte Umgebungen geeignet sind, bringt ihr Hosting in Kubernetes Überlegungen hinsichtlich Netzwerk, Sicherheit und betrieblicher Komplexität mit sich, insbesondere bei der Verwendung von stdio-basierten Servern oder Bereitstellungen, denen Unternehmensfunktionen wie Authentifizierung, Autorisierung und Beobachtbarkeit fehlen. Lösungen wie AgentGateway, kgateway, LiteLLM und kmcp schließen diese Lücken, indem sie robuste Transportschichten, OAuth2-basierten Schutz, RBAC-Funktionen und vereinfachte Bereitstellungsworkflows hinzufügen. Zusammen ermöglichen sie die Ausführung sowohl nativer MCP-Server als auch rein stdio-basierter Implementierungen in Kubernetes-Umgebungen der Produktionsklasse.

Da sich das MCP-Ökosystem weiterentwickelt, werden kommende Funktionen wie die URL-Modus-Ermittlung die sichere, mandantenfähige und benutzerbewusste Integration weiter stärken. Mit zunehmender Reife der Tools, MCP-Clients, Gateways und des Protokolls werden sie zu einem zentralen Baustein für AI-Agentenarchitekturen auf Unternehmensebene. Das Hosting von MCP-Servern auf Kubernetes, unterstützt durch diese neuen Tools und Standards, bietet eine skalierbare, sichere und zukunftssichere Grundlage für die Entwicklung von LLM-basierten Anwendungen.

Further readings

• https://liquidreply.net/news/manage-a-unified-llm-api-platform-with-litellm
• https://github.com/modelcontextprotocol/modelcontextprotocol/pull/887
• https://kgateway.dev/docs/agentgateway/latest/
• https://www.keycloak.org/documentation
• https://www.anthropic.com/news/model-context-protocol
• https://kagent.dev/docs/kmcp