--- title: MCP-Tunnel mit Helm bereitstellen url: https://platform.claude.com/docs/de/agents-and-tools/mcp-tunnels/deploy-helm description: Installiere den Tunnel-Stack auf einem Kubernetes-Cluster mithilfe des Anthropic Helm-Charts. --- „MCP tunnels" (MCP-Tunnel) befinden sich in der „research preview" (Forschungsvorschau). [Fordere Zugang an](https://claude.com/form/mcp-tunnels), um sie auszuprobieren. Das Anthropic Helm-Chart installiert den [Tunnel-Stack](https://platform.claude.com/docs/de/agents-and-tools/mcp-tunnels/concepts#components) als einzelnes Deployment und verbindet ihn mit deinem Tunnel: entweder einem, den der Setup-Hook des Charts für dich erstellt, oder einem bestehenden Tunnel, den du in der [Console](https://platform.claude.com/docs/de/agents-and-tools/mcp-tunnels/console#create-a-tunnel) erstellt hast. ## Bevor du beginnst Du benötigst: * **Einen Tunnel.** Mit programmatischem Zugriff erstellt der Setup-Hook des Charts einen für dich, wenn du keine Tunnel-ID angibst; um stattdessen einen bestehenden Tunnel anzubinden, [erstelle ihn in der Console](https://platform.claude.com/docs/de/agents-and-tools/mcp-tunnels/console#create-a-tunnel) und notiere die Tunnel-ID (`tnl_...`). Die manuelle Bereitstellung beginnt immer mit einem in der Console erstellten Tunnel; du benötigst außerdem dessen Tunnel-Token und Tunnel-Domain. * **Eine Möglichkeit für das Chart, sich bei der Tunnels API zu authentifizieren.** * **[Programmatischer Zugriff](https://platform.claude.com/docs/de/agents-and-tools/mcp-tunnels/concepts#credential-provisioning) (empfohlen).** Die [Setup-Komponente](https://platform.claude.com/docs/de/agents-and-tools/mcp-tunnels/concepts#components) authentifiziert sich über „Workload Identity Federation“ (Workload-Identitätsföderation), ruft das Tunnel-Token ab, generiert eine CA, registriert sie bei Anthropic und speichert alles in einem Secret. Du benötigst eine Föderationsregel mit dem Scope `workspace:manage_tunnels`. * **[Manuell](https://platform.claude.com/docs/de/agents-and-tools/mcp-tunnels/concepts#credential-provisioning).** Überspringe den programmatischen Zugriff. Du [holst das Tunnel-Token aus der Console](https://platform.claude.com/docs/de/agents-and-tools/mcp-tunnels/console#get-the-connection-details), generierst selbst eine CA und ein Serverzertifikat, [registrierst die CA in der Console](https://platform.claude.com/docs/de/agents-and-tools/mcp-tunnels/console#add-a-ca-certificate) und stellst die Zugangsdaten dem Cluster als Secrets bereit. * **Einen Kubernetes-Cluster**, auf den du mit `helm` und `kubectl` deployen kannst. Der Tab **Ohne programmatischen Zugriff** verwendet zusätzlich `openssl` (1.1.1 oder neuer). * **Ausgehende Netzwerkkonnektivität** vom Cluster zu `api.anthropic.com` (443 TCP) und zum [Tunnel-Edge](https://platform.claude.com/docs/de/agents-and-tools/mcp-tunnels/concepts#components) (7844 TCP und UDP). Siehe die vollständigen [Netzwerkanforderungen](https://platform.claude.com/docs/de/agents-and-tools/mcp-tunnels/overview#network-requirements). * **Einen oder mehrere MCP-Server**, die laufen und vom Cluster aus unter den Adressen erreichbar sind, die du unter `gateway.config.routes` konfigurierst. Falls du noch keinen hast, [verwende den Beispielserver](https://platform.claude.com/docs/de/agents-and-tools/mcp-tunnels/deploy-helm#optional-use-a-sample-mcp-server). ## Optional: Einen Beispiel-MCP-Server verwenden Wenn du keinen MCP-Server zum Testen zur Verfügung hast, verwende diesen minimalen: ```bash kubectl create namespace mcp-tunnel --dry-run=client -o yaml | kubectl apply -f - kubectl -n mcp-tunnel apply -f - <<'EOF' apiVersion: v1 kind: ConfigMap metadata: name: hello-mcp-src data: hello_server.py: | from mcp.server.fastmcp import FastMCP mcp = FastMCP("hello-server", host="0.0.0.0", port=9000) @mcp.tool() def hello(name: str = "world") -> str: """Say hello to someone.""" return f"Hello, {name}!" if __name__ == "__main__": mcp.run(transport="streamable-http") --- apiVersion: apps/v1 kind: Deployment metadata: name: hello-mcp spec: replicas: 1 selector: matchLabels: { app: hello-mcp } template: metadata: labels: { app: hello-mcp } spec: containers: - name: hello-mcp image: python:3.13-slim command: ["sh", "-c", "pip install --quiet mcp && python /app/hello_server.py"] volumeMounts: - { name: src, mountPath: /app } ports: - { containerPort: 9000 } volumes: - name: src configMap: { name: hello-mcp-src } --- apiVersion: v1 kind: Service metadata: name: hello-mcp spec: selector: { app: hello-mcp } ports: - { port: 9000, targetPort: 9000 } EOF ``` Die folgenden Installationsschritte weisen darauf hin, wo die entsprechende Route hinzuzufügen ist. ## Installation Die Setup-Komponente tauscht das projizierte ServiceAccount-Token des Clusters über deine Föderationsregel aus, ruft das Tunnel-Token ab, generiert eine CA und ein Serverzertifikat und registriert die CA bei Anthropic. Ein täglicher CronJob erneuert das Serverzertifikat bei Bedarf, sodass du keine Secrets von Hand verwalten musst. Folge [WIF mit Kubernetes verwenden](https://platform.claude.com/docs/de/manage-claude/wif-providers/kubernetes), um den OIDC-Issuer deines Clusters zu registrieren und eine Föderationsregel zu erstellen. Die Setup-Komponente läuft unter ihrem eigenen ServiceAccount im Release-Namespace; der genaue Name folgt Helms `fullname`-Konvention. Führe daher für jeden anderen Release-Namen als `mcp-tunnel` `helm template ... | grep -A2 'kind: ServiceAccount'` aus, um ihn zu bestätigen, bevor du die Regel erstellst. Der Rest dieses Leitfadens geht vom Release-Namen `mcp-tunnel` im Namespace `mcp-tunnel` aus, wobei der ServiceAccount `mcp-tunnel-setup` heißt. | Feld | Wert | | -------- | ---------------------------------------------------------- | | Subject | `system:serviceaccount:mcp-tunnel:mcp-tunnel-setup` | | Audience | `api.anthropic.com` (der Standard des Charts; ohne Schema) | | Scope | `workspace:manage_tunnels` | Die Standard-Audience des Charts ist `api.anthropic.com` ohne Schema, aber das Formular für Föderationsregeln in der Console schlägt `https://api.anthropic.com` vor. Beide müssen Byte für Byte übereinstimmen, sonst schlägt die Authentifizierung fehl. Setze entweder die Audience der Regel auf `api.anthropic.com` oder setze `api.wif.audience` in `values.yaml` auf `https://api.anthropic.com`. Wenn sich der Tunnel in einem anderen Workspace als dem Standard-Workspace der Organisation befindet, [füge außerdem den Service-Account der Regel zu diesem Workspace hinzu](https://platform.claude.com/docs/de/manage-claude/workspaces#role-inheritance) (die Tunnels API autorisiert anhand der Workspace-Mitgliedschaften des Service-Accounts). Notiere die ID der Regel (`fdrl_...`); du setzt sie als `api.wif.federationRuleId`. Der tägliche CronJob zur Zertifikatserneuerung verwendet einen separaten ServiceAccount (ebenfalls vom Helm-`fullname` abgeleitet), ruft aber die Tunnels API nicht auf; er erneuert das Zertifikat lokal und benötigt nur Kubernetes-RBAC, das das Chart gewährt. Die Föderationsregel muss ihn nicht abdecken. ```bash helm show values \ oci://us-docker.pkg.dev/anthropic-public-registry/charts/mcp-tunnel \ --version 2.0.2 > values.yaml ``` Bearbeite `values.yaml` und setze die `api.wif.*`-Schlüssel mit der ID der Föderationsregel und der Organisations-ID sowie einen `routes`-Eintrag für jeden [Upstream-MCP-Server](https://platform.claude.com/docs/de/agents-and-tools/mcp-tunnels/concepts#components): ```yaml values.yaml api: wif: federationRuleId: "fdrl_..." organizationId: "00000000-0000-0000-0000-000000000000" # Set when the tunnel is in a non-default workspace and the # rule's service account is a member of that workspace. # workspaceId: "wrkspc_..." tunnel: # Leave empty to have the setup hook create a tunnel during install. # Set to attach to an existing tunnel from the Console. id: "" # Increment to rotate the tunnel token on the next upgrade. # See the "Rotate the tunnel token" section. tokenVersion: "1" gateway: config: routes: docs: http://docs-mcp.internal:8080 search: http://search-mcp.internal:8080 ``` Mit diesen Routen erreicht Claude die Server unter `docs.` und `search.`. Einige verwaltete Kubernetes-Distributionen vergeben den Service-CIDR außerhalb der standardmäßigen privaten Bereiche; wenn deine Routen auf Services innerhalb des Clusters zielen, füge hier `gateway.config.upstream.allowed_ips` gemäß [Upstream-IP-Validierung](https://platform.claude.com/docs/de/agents-and-tools/mcp-tunnels/troubleshooting#upstream-ip-validation) hinzu. Wenn du den [Beispiel-MCP-Server](https://platform.claude.com/docs/de/agents-and-tools/mcp-tunnels/deploy-helm#optional-use-a-sample-mcp-server) verwendest, setze `routes` stattdessen auf `echo: http://hello-mcp:9000`. Rendere das Chart und prüfe die Ausgabe gemäß den Prüfverfahren deiner Organisation: ```bash helm template mcp-tunnel \ oci://us-docker.pkg.dev/anthropic-public-registry/charts/mcp-tunnel \ --version 2.0.2 \ -n mcp-tunnel \ -f values.yaml > rendered.yaml ``` ```bash helm install mcp-tunnel \ oci://us-docker.pkg.dev/anthropic-public-registry/charts/mcp-tunnel \ --version 2.0.2 \ --namespace mcp-tunnel --create-namespace \ -f values.yaml ``` Die Setup-Komponente läuft als Helm-Pre-Install-Hook-Job, sodass `helm install` blockiert, bis sie abgeschlossen ist. Bei Erfolg löscht Helm den Job automatisch. Wenn `helm install` mit einem Hook-Fehler fehlschlägt, siehe [Authentifizierungsfehler der Setup-Komponente](https://platform.claude.com/docs/de/agents-and-tools/mcp-tunnels/troubleshooting#setup-component-authentication-failures). Wenn `tunnel.id` leer ist, erstellt die Setup-Komponente den Tunnel in dem Workspace, auf den deine Föderationsregel zielt (dem Standard-Workspace der Organisation, sofern du nicht `api.wif.workspaceId` setzt), und speichert dessen ID und Domain im `mcp-tunnel`-Secret. Die Domain, die du für die [Verifizierung](https://platform.claude.com/docs/de/agents-and-tools/mcp-tunnels/deploy-helm#verify-the-deployment) benötigst, findest du auf der Detailseite des Tunnels, die du über die Seite [MCP tunnels](https://platform.claude.com/settings/workspaces/default/mcp-tunnels) (`platform.claude.com/settings/workspaces/default/mcp-tunnels`) in der Console öffnest. Wähle in der Workspace-Auswahl in der Seitenleiste den Workspace aus, der den Tunnel enthält. Du kannst die Domain auch aus dem Secret auslesen: ```bash kubectl -n mcp-tunnel get secret mcp-tunnel \ -o jsonpath='{.data.tunnel-domain}' | base64 -d ``` Ein erneutes Ausführen der Setup-Komponente (bei [Upgrades](https://platform.claude.com/docs/de/agents-and-tools/mcp-tunnels/deploy-helm#upgrades) oder [Token-Rotation](https://platform.claude.com/docs/de/agents-and-tools/mcp-tunnels/deploy-helm#rotate-the-tunnel-token)) verwendet die in diesem Secret gespeicherte Tunnel-ID wieder; es wird niemals ein zweiter Tunnel erstellt. Die `api.wif.*`-Werte sind Bezeichner, keine Secrets, daher ist ihre Speicherung in den Release-History-Secrets von Helm kein Risiko. Die sensiblen ruhenden Daten sind das Secret `mcp-tunnel`, das die Setup-Komponente erstellt und das das Tunnel-Token und die privaten TLS-Schlüssel enthält. Wende die Standardverfahren deiner Organisation zum Schutz von Kubernetes-Secrets auf diesen Namespace an. In diesem Modus (`setup.enabled: false`) führt das Chart keine API-Aufrufe durch; die Setup-Komponente läuft nicht und es gibt keinen Cert-Renew-CronJob. Verwende diesen Weg, wenn du Workload Identity Federation lieber nicht einrichten möchtest. [Erstelle den Tunnel](https://platform.claude.com/docs/de/agents-and-tools/mcp-tunnels/console#create-a-tunnel) und [hole das Tunnel-Token aus der Console](https://platform.claude.com/docs/de/agents-and-tools/mcp-tunnels/console#get-the-connection-details). Notiere die Tunnel-Domain von der Detailseite. Du setzt sie als `gateway.config.tunnel_domain`. Der Proxy lauscht auf einfachem WebSocket, wobei [inneres TLS](https://platform.claude.com/docs/de/agents-and-tools/mcp-tunnels/concepts#components) innerhalb dieses Streams mit dem hier generierten Zertifikat transportiert wird. Der SAN des Serverzertifikats muss gemäß den [Zertifikatsanforderungen](https://platform.claude.com/docs/de/agents-and-tools/mcp-tunnels/reference#certificate-requirements) `*.` enthalten. ```bash export TUNNEL_DOMAIN=YOUR_TUNNEL_DOMAIN_HERE mkdir -p mcp-tunnel/data cd mcp-tunnel # Selbstsignierte CA. Explizite Erweiterungen, damit sie die Zertifikats- # anforderungen unabhängig von den openssl.cnf-Standards der Distro erfüllt. openssl req -x509 -newkey rsa:2048 -nodes \ -keyout data/ca.key -out data/ca.crt \ -days 3650 -subj "/CN=mcp-tunnel-ca" \ -addext "basicConstraints=critical,CA:TRUE" \ -addext "keyUsage=critical,keyCertSign,cRLSign" \ -addext "subjectKeyIdentifier=hash" # Erweiterungsdatei für das Serverzertifikat. -extfile (statt # -copy_extensions, das nur in OpenSSL 3.0+ verfügbar ist) hält dies auf # OpenSSL 1.1.x lauffähig. cat > data/tls.ext < Das Chart liest bestimmte Schlüssel; die Secret-Namen sind konfigurierbar, die Schlüssel jedoch nicht. Der folgende Befehl zur Namespace-Erstellung ist wirkungslos, wenn der Namespace bereits existiert (zum Beispiel aus dem Schritt mit dem [Beispiel-MCP-Server](https://platform.claude.com/docs/de/agents-and-tools/mcp-tunnels/deploy-helm#optional-use-a-sample-mcp-server)). ```bash kubectl create namespace mcp-tunnel --dry-run=client -o yaml | kubectl apply -f - kubectl -n mcp-tunnel create secret generic mcp-tunnel-token \ --from-literal=tunnel-token='eyJ...' kubectl -n mcp-tunnel create secret generic mcp-tunnel-cert \ --from-file=tls.crt=data/tls.crt \ --from-file=tls.key=data/tls.key ``` ```bash helm show values \ oci://us-docker.pkg.dev/anthropic-public-registry/charts/mcp-tunnel \ --version 2.0.2 > values.yaml ``` Bearbeite `values.yaml` und setze die folgenden Schlüssel: ```yaml values.yaml setup: enabled: false external: tunnelTokenSecretName: mcp-tunnel-token # must contain key: tunnel-token serverCertSecretName: mcp-tunnel-cert # must contain keys: tls.crt, tls.key gateway: config: # Required when setup.enabled is false. Replace the placeholder with # the $TUNNEL_DOMAIN value you exported earlier. When setup.enabled # is true the chart injects this from the Secret as a -tunnel-domain # flag instead. tunnel_domain: YOUR_TUNNEL_DOMAIN_HERE routes: docs: http://docs-mcp.internal:8080 search: http://search-mcp.internal:8080 ``` Einige verwaltete Kubernetes-Distributionen vergeben den Service-CIDR außerhalb der standardmäßigen privaten Bereiche; wenn deine Routen auf Services innerhalb des Clusters zielen, füge hier `gateway.config.upstream.allowed_ips` gemäß [Upstream-IP-Validierung](https://platform.claude.com/docs/de/agents-and-tools/mcp-tunnels/troubleshooting#upstream-ip-validation) hinzu. Wenn du den [Beispiel-MCP-Server](https://platform.claude.com/docs/de/agents-and-tools/mcp-tunnels/deploy-helm#optional-use-a-sample-mcp-server) verwendest, setze `routes` stattdessen auf `echo: http://hello-mcp:9000`. ```bash helm template mcp-tunnel \ oci://us-docker.pkg.dev/anthropic-public-registry/charts/mcp-tunnel \ --version 2.0.2 \ -n mcp-tunnel \ -f values.yaml > rendered.yaml ``` ```bash helm install mcp-tunnel \ oci://us-docker.pkg.dev/anthropic-public-registry/charts/mcp-tunnel \ --version 2.0.2 \ --namespace mcp-tunnel --create-namespace \ -f values.yaml ``` ## Das Deployment verifizieren Verifiziere Ende-zu-Ende von Anthropics Seite aus: Verwende `https://./` in einer Managed-Agent-Sitzung oder einer Messages-API-Anfrage, wobei `` ein Schlüssel aus `gateway.config.routes` ist und `` der Pfad, unter dem der Upstream-MCP-Server ausliefert. Mit dem [Beispiel-MCP-Server](https://platform.claude.com/docs/de/agents-and-tools/mcp-tunnels/deploy-helm#optional-use-a-sample-mcp-server) ist das `https://echo./mcp`. Siehe [Die getunnelten MCP-Server verwenden](https://platform.claude.com/docs/de/agents-and-tools/mcp-tunnels/overview#use-the-tunneled-mcp-servers) für die Anfrageformate. Falls das fehlschlägt, prüfe die Pod-Logs (`kubectl -n mcp-tunnel logs deploy/mcp-tunnel -c mcp-proxy` und `-c cloudflared`) und konsultiere die [Fehlerbehebung](https://platform.claude.com/docs/de/agents-and-tools/mcp-tunnels/troubleshooting). ## Optionale Konfiguration ### Egress mit NetworkPolicy einschränken Ingress zum Proxy-Pod wird standardmäßig verweigert (`networkPolicy.ingress.enabled: true`). Um zusätzlich den Pod-Egress einzuschränken, setze `networkPolicy.egress.enabled: true` und befülle `networkPolicy.egress.mcpServers` mit Pod-Label-Selektoren oder CIDR-Bereichen, die deine Upstream-MCP-Server abdecken. Egress von cloudflared zum Tunnel-Edge wird separat über `networkPolicy.egress.cloudflaredEgressCIDRs` erlaubt. ### Den Proxy anpassen Felder unter `gateway.config.*` werden an die Proxy-Konfigurationsdatei durchgereicht. Häufige Anpassungen sind `upstream.allowed_ips`, `log_level` und `upstream.tls`. Siehe die Referenz zur [Proxy-Konfiguration](https://platform.claude.com/docs/de/agents-and-tools/mcp-tunnels/reference#proxy-configuration) für die vollständige Feldliste. Das Chart setzt immer `listen_addr`, `tls.cert_file` und `tls.key_file`; sie in `gateway.config` zu setzen, hat keine Wirkung. ### Ein eigenes OIDC-Token bereitstellen Standardmäßig projiziert das Chart ein Kubernetes-ServiceAccount-Token für die Setup-Komponente. Um ein Token von einem anderen Identitätsanbieter zu verwenden (etwa [SPIFFE](https://platform.claude.com/docs/de/manage-claude/wif-providers/spiffe), Vault oder einem Cloud-SDK-Sidecar), mounte es mit `setup.extraVolumes` und `setup.extraVolumeMounts`. Richte dann `api.wif.tokenFile` auf den Mount-Pfad. Das Chart setzt `ANTHROPIC_IDENTITY_TOKEN_FILE` auf diesen Pfad, und die Setup-Komponente liest das Token von dort. ## Upgrades Übergib `helm upgrade` immer `--version`, damit du nicht unerwartet ein neueres Chart beziehst. ### Upgrade von Chart 1.x Chart 2.0.0 verschiebt die Tunnel-ID von `api.wif.tunnelId` nach `tunnel.id`. Bearbeite vor dem Upgrade deine `values.yaml`: Verschiebe den `tnl_...`-Wert nach `tunnel.id` und entferne `api.wif.tunnelId`. `tunnel.id` ungesetzt zu lassen ist unbedenklich (die Setup-Komponente verwendet bei erneuter Ausführung die bereits im Secret `mcp-tunnel` gespeicherte Tunnel-ID wieder), aber das explizite Verschieben hält deine `values.yaml` korrekt. Aktualisiere außerdem in der Console den Scope deiner Föderationsregel von `org:manage_tunnels` auf `workspace:manage_tunnels`. ### Konfiguration ändern Für Routineänderungen wie Routen, Replikazahl oder NetworkPolicy: ```bash helm upgrade mcp-tunnel \ oci://us-docker.pkg.dev/anthropic-public-registry/charts/mcp-tunnel \ --version 2.0.2 \ -n mcp-tunnel \ -f values.yaml ``` Pflege eine vollständige `values.yaml`, anstatt dich auf `--reuse-values` zu verlassen. Helms Deep-Merge-Verhalten kann stillschweigend dabei scheitern, gelöschte Routen zu entfernen. ### Das Tunnel-Token rotieren Mit programmatischem Zugriff erhöhe `tunnel.tokenVersion` in `values.yaml` und führe das Upgrade mit `--set setup.force=true` aus. Die Setup-Komponente läuft bei Upgrades nur erneut, wenn sie dazu gezwungen wird: ```bash helm upgrade mcp-tunnel \ oci://us-docker.pkg.dev/anthropic-public-registry/charts/mcp-tunnel \ --version 2.0.2 \ -n mcp-tunnel \ -f values.yaml \ --set setup.force=true ``` Die Setup-Komponente authentifiziert sich mit Workload Identity Federation; es gibt kein API-Token, das widerrufen werden müsste. Ohne programmatischen Zugriff klicke auf der Tunnel-Detailseite in der Console auf **Rotate token** und aktualisiere dann das Secret `mcp-tunnel-token`: ```bash kubectl -n mcp-tunnel create secret generic mcp-tunnel-token \ --from-literal=tunnel-token='eyJ...' --dry-run=client -o yaml | kubectl apply -f - kubectl -n mcp-tunnel rollout restart deploy/mcp-tunnel ``` Ein Klick auf **Rotate token** macht das aktuelle Token sofort ungültig. Bis das Secret aktualisiert und der Rollout abgeschlossen ist, kann sich kein Pod, der mit dem alten Token neu startet (Eviction, Node-Drain, OOM), wieder verbinden. Aktualisiere das Secret umgehend nach der Rotation; bei strengeren Verfügbarkeitsanforderungen verwende programmatischen Zugriff, damit das Chart die Rotation atomar durchführt. ### Zertifikatserneuerung Das Chart stellt Automatisierung bereit, aber du bleibst dafür verantwortlich, den Ablauf zu überwachen und zu bestätigen, dass die Erneuerung abgeschlossen wird. Mit programmatischem Zugriff erfolgt die Zertifikatserneuerung automatisch. Das Chart deployt einen CronJob (benannt nach dem Helm-`fullname` mit dem Suffix `-cert-renew`), der täglich `setup renew-cert` ausführt (gemäß `serverCert.cronSchedule`, Standard `0 0 * * *` UTC). Der Job ist wirkungslos, solange das Zertifikat nicht innerhalb von `serverCert.renewBefore` vor dem Ablauf liegt (Standard 30 Tage). Die Erneuerung erfolgt lokal: Der Job signiert ein neues Zertifikat mit der bereits im Secret gespeicherten CA, führt keine API-Aufrufe durch und benötigt nur das Kubernetes-RBAC, das das Chart gewährt. Der Proxy lädt das Zertifikat per Hot-Reload aus dem Secret-Mount, sodass kein Neustart des Deployments nötig ist. Ohne programmatischen Zugriff gibt es keinen CronJob. Signiere aus dem Verzeichnis `mcp-tunnel/` heraus, das du nach der Installation behalten hast, ein neues Serverzertifikat mit der bestehenden CA (generiere die CA nicht neu): ```bash export TUNNEL_DOMAIN=YOUR_TUNNEL_DOMAIN_HERE openssl req -new -key data/tls.key -out /tmp/server.csr \ -subj "/CN=${TUNNEL_DOMAIN}" openssl x509 -req -in /tmp/server.csr \ -CA data/ca.crt -CAkey data/ca.key -CAcreateserial \ -out data/tls.crt -days 90 -extfile data/tls.ext kubectl -n mcp-tunnel create secret generic mcp-tunnel-cert \ --from-file=tls.crt=data/tls.crt --from-file=tls.key=data/tls.key \ --dry-run=client -o yaml | kubectl apply -f - ``` Der Proxy lädt das Zertifikat per Hot-Reload aus dem Secret-Mount. ## Nächste Schritte Binde einen Upstream-MCP-Server an einen Managed Agent oder die Messages API an. Hinweise zur Härtung, Rotation von Zugangsdaten und Reaktion auf Sicherheitsvorfälle. Diagnostiziere Konnektivitäts-, TLS- und Routing-Probleme.