--- 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 mit dem Anthropic-Helm-Chart auf einem Kubernetes-Cluster. --- „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 mit einem, den der Setup-Hook des Charts für dich erstellt, oder mit einem bestehenden Tunnel, den du in der [Claude 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 zu verwenden, [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, ruft das Tunnel-Token ab, generiert eine CA, registriert sie bei Anthropic und speichert alles in einem Secret. Du benötigst eine Federation-Regel mit dem Scope `workspace:manage_tunnels`. * **[Manuell](https://platform.claude.com/docs/de/agents-and-tools/mcp-tunnels/concepts#credential-provisioning).** Verzichte auf 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 Anmeldedaten dem Cluster als Secrets bereit. * **Einen Kubernetes-Cluster**, auf dem du mit `helm` und `kubectl` bereitstellen kannst. Der Tab **Ohne programmatischen Zugriff** verwendet außerdem `openssl` (1.1.1 oder neuer). * **Ausgehende Netzwerkverbindung** 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 dir kein MCP-Server zum Testen zur Verfügung steht, 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 du die entsprechende Route hinzufügst. ## Installieren Die Setup-Komponente tauscht das projizierte ServiceAccount-Token des Clusters über deine Federation-Regel 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 manuell handhaben 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 Federation-Regel zu erstellen. Die Setup-Komponente läuft unter einem eigenen ServiceAccount im Release-Namespace; der genaue Name folgt Helms `fullname`-Konvention. Führe daher bei jedem anderen Release-Namen als `mcp-tunnel` den Befehl `helm template ... | grep -A2 'kind: ServiceAccount'` aus, um ihn zu bestätigen, bevor du die Regel erstellst. Der Rest dieser Anleitung geht vom Release-Namen `mcp-tunnel` im Namespace `mcp-tunnel` aus, wobei der ServiceAccount `mcp-tunnel-setup` ist. | Feld | Wert | | -------- | ------------------------------------------------------ | | Subject | `system:serviceaccount:mcp-tunnel:mcp-tunnel-setup` | | Audience | `api.anthropic.com` (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 Federation-Regeln 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 nicht die Tunnels API auf; er erneuert das Zertifikat lokal und benötigt nur Kubernetes-RBAC, das das Chart gewährt. Die Federation-Regel muss ihn nicht abdecken. ```bash helm show values \ oci://us-docker.pkg.dev/anthropic-public-registry/charts/mcp-tunnel \ --version 2.1.0 > values.yaml ``` Bearbeite `values.yaml` und setze die `api.wif.*`-Schlüssel mit der Federation-Regel-ID 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 weisen den Service-CIDR außerhalb der standardmäßigen privaten Bereiche zu; wenn deine Routen auf clusterinterne Services zielen, füge hier `gateway.config.upstream.allowed_ips` hinzu, wie in [Upstream-IP-Validierung](https://platform.claude.com/docs/de/agents-and-tools/mcp-tunnels/troubleshooting#upstream-ip-validation) beschrieben. 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.1.0 \ -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.1.0 \ --namespace mcp-tunnel --create-namespace \ -f values.yaml ``` Die Setup-Komponente läuft als Helm-Pre-Install-Hook-Job, daher blockiert `helm install`, 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 Federation-Regel zielt (dem Standard-Workspace der Organisation, sofern du nicht `api.wif.workspaceId` setzt), und speichert dessen ID und Domain im Secret `mcp-tunnel`. 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 der [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 nie ein zweiter Tunnel erstellt. Die `api.wif.*`-Werte sind Bezeichner, keine Secrets, daher stellt ihre Speicherung in Helm-Release-History-Secrets kein Risiko dar. Die sensiblen ruhenden Daten sind das von der Setup-Komponente erstellte Secret `mcp-tunnel`, das das Tunnel-Token und die privaten TLS-Schlüssel enthält. Wende die Standardpraktiken 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 übertragen wird. Das SAN des Serverzertifikats muss `*.` enthalten, wie in den [Zertifikatsanforderungen](https://platform.claude.com/docs/de/agents-and-tools/mcp-tunnels/reference#certificate-requirements) beschrieben. ```bash export TUNNEL_DOMAIN=YOUR_TUNNEL_DOMAIN_HERE mkdir -p mcp-tunnel/data cd mcp-tunnel # Selbstsignierte CA. Explizite Extensions, damit sie die Zertifikats- # anforderungen unabhängig von den openssl.cnf-Defaults 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" # Extension-Datei für das Server-Zertifikat. Mit -extfile (statt # -copy_extensions, das erst ab OpenSSL 3.0 verfügbar ist) funktioniert das auch mit # OpenSSL 1.1.x. 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 hat keine Wirkung, wenn der Namespace bereits existiert (zum Beispiel aus dem Schritt zum [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.1.0 > 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 weisen den Service-CIDR außerhalb der standardmäßigen privaten Bereiche zu; wenn deine Routen auf clusterinterne Services zielen, füge hier `gateway.config.upstream.allowed_ips` hinzu, wie in [Upstream-IP-Validierung](https://platform.claude.com/docs/de/agents-and-tools/mcp-tunnels/troubleshooting#upstream-ip-validation) beschrieben. 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.1.0 \ -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.1.0 \ --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 bereitstellt. 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. Wenn 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 ist 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 umfassen `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. ### 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 ein Cloud-SDK-Sidecar), binde es mit `setup.extraVolumes` und `setup.extraVolumeMounts` ein. 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 abrufst. ### 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` nicht zu setzen ist unbedenklich (die Setup-Komponente verwendet beim erneuten Ausführen 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 Federation-Regel von `org:manage_tunnels` auf `workspace:manage_tunnels`. ### Konfiguration ändern Für routinemäßige Änderungen wie Routen, Replikatanzahl oder NetworkPolicy: ```bash helm upgrade mcp-tunnel \ oci://us-docker.pkg.dev/anthropic-public-registry/charts/mcp-tunnel \ --version 2.1.0 \ -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 daran scheitern, gelöschte Routen zu entfernen. ### Das Tunnel-Token rotieren Mit programmatischem Zugriff erhöhst du `tunnel.tokenVersion` in `values.yaml` und führst das Upgrade mit `--set setup.force=true` durch. Die Setup-Komponente läuft bei Upgrades nur erneut, wenn dies erzwungen wird: ```bash helm upgrade mcp-tunnel \ oci://us-docker.pkg.dev/anthropic-public-registry/charts/mcp-tunnel \ --version 2.1.0 \ -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 klickst du auf der Tunnel-Detailseite in der Console auf **Rotate token** und aktualisierst 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 jeder Pod, der mit dem alten Token neu startet (Eviction, Node-Drain, OOM), nicht wieder verbinden. Aktualisiere das Secret nach der Rotation umgehend; bei strengeren Verfügbarkeitsanforderungen verwende programmatischen Zugriff, damit das Chart die Rotation atomar durchführt. ### Zertifikatserneuerung Das Chart bietet Automatisierung, 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 stellt einen CronJob bereit (benannt nach dem Helm-`fullname` mit dem Suffix `-cert-renew`), der täglich `setup renew-cert` ausführt (zu `serverCert.cronSchedule`, standardmäßig `0 0 * * *` UTC). Der Job tut nichts, es sei denn, das Zertifikat läuft innerhalb von `serverCert.renewBefore` ab (standardmäßig 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 im laufenden Betrieb aus dem Secret-Mount neu, sodass kein Neustart des Deployments erforderlich ist. Ohne programmatischen Zugriff gibt es keinen CronJob. Signiere aus dem Verzeichnis `mcp-tunnel/`, das du nach der Installation aufbewahrt 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 im laufenden Betrieb aus dem Secret-Mount neu. ## Nächste Schritte Verbinde einen Upstream-MCP-Server mit einem Managed Agent oder der Messages API. Hinweise zur Härtung, Rotation von Anmeldedaten und Reaktion auf Sicherheitsvorfälle. Diagnostiziere Probleme mit Konnektivität, TLS und Routing.