--- title: Agent-Identität und Anmeldeinformationen url: https://platform.claude.com/docs/de/managed-agents/self-hosted/agent-identity description: Lass deinen selbst gehosteten Claude Managed Agents-Server ein kurzlebiges Token signieren, das jeden Agenten benennt, speichere Vault-Anmeldedaten in deinem Secret-Manager und halte Secrets mit dem Egress-Gateway aus Sandboxes heraus. --- Um Zugriff auf selbst gehostetes Claude Managed Agents anzufordern, kontaktiere dein Anthropic-Account-Team. Diese Seite zeigt, wie Systeme außerhalb deines Servers einem Agenten vertrauen können und wo du die Anmeldeinformationen aufbewahrst, die deine Agenten verwenden: * [Agent-Identität](https://platform.claude.com/docs/de/managed-agents/self-hosted/agent-identity#agent-identity): Lass einen MCP-Server oder ein Gateway jedem Agenten eigenen Zugriff gewähren. Der Server signiert ein kurzlebiges Token, das den Agenten benennt. * [Secret-Manager](https://platform.claude.com/docs/de/managed-agents/self-hosted/agent-identity#secret-manager): Der Server speichert Vault-Anmeldedaten in AWS Secrets Manager, Google Cloud Secret Manager, HashiCorp Vault oder Azure Key Vault. * [Anmeldeinformationen als Umgebungsvariablen](https://platform.claude.com/docs/de/managed-agents/self-hosted/agent-identity#environment-variable-credentials): Lass die Befehle eines Agenten einen Dienst aufrufen, während die Sandbox nur einen Platzhalter enthält. Das Egress-Gateway setzt den echten Wert in die Anfragen des Agenten ein. ## Agent-Identität Dein Server kann ein kurzlebiges „JSON Web Token“ (JSON-Web-Token), oder JWT, signieren, das einen Agenten benennt, und es mit den MCP-Aufrufen dieses Agenten senden. Der Empfänger, ein MCP-Server oder ein MCP-„gateway“ (Gateway), prüft das Token anhand öffentlicher Schlüssel, die du veröffentlichst, und kann dann jedem Agenten eigenen Zugriff gewähren. ### Den Issuer einrichten 1. **Wähle die Issuer-URL.** Unter dieser URL veröffentlichst du in Schritt 3 deine öffentlichen Schlüssel, und Empfänger rufen sie von dort ab. Ein statischer Webhost funktioniert. Verwende nicht die Adresse deines Servers, da der Server die Schlüssel nicht unter den Pfaden bereitstellt, die Empfänger abrufen. Verwende eine `https://`-URL ohne Pfad oder abschließenden Schrägstrich, auf einem Hostnamen, den du behalten kannst. 2. **Erstelle den Signaturschlüssel.** Führe diese Befehle im obersten Verzeichnis des entpackten Archivs aus: ```bash mkdir -m 700 agent-identity openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:2048 -out agent-identity/signing-key.pem ``` 3. **Veröffentliche die öffentlichen Schlüssel.** Dieser Befehl schreibt sie nach `issuer-files/.well-known/`. Stelle `issuer-files` im Stammverzeichnis des Hostnamens des Issuers bereit, mit dem Content-Type `application/json`. ```bash CMA_AGENT_IDENTITY__ISSUER=https://agents.example.com \ CMA_AGENT_IDENTITY__KEY_FILE=./agent-identity/signing-key.pem \ ./cma-server export-issuer -out issuer-files ``` 4. **Gib dem Server den Schlüssel.** 1. Wenn das Archiv ein `compose`-Verzeichnis hat, verschiebe das Verzeichnis des Schlüssels dorthin: `mv agent-identity compose/agent-identity`. 2. Lösche in `docker-compose.yml` die Zeile `volumes: *server_mounts` des Dienstes `cma-server` und entferne die Kommentierung des `volumes:`-Blocks darunter. Wenn du die `x-server-mounts`-Liste geändert hast, nimm dieselbe Änderung in diesem Block vor, da der Dienst `cma-server` die Liste nicht mehr liest. 3. Führe im Verzeichnis, das `agent-identity` enthält, `sudo chown -R root:root agent-identity` aus, es sei denn, du verwendest Docker Desktop unter macOS oder rootless Docker. Führe `kubectl -n cma-server create secret generic cma-agent-identity --from-file=agent-identity/signing-key.pem` aus. Setze dann `server.agentIdentity.secretName` in der Values-Datei des Server-Charts auf `cma-agent-identity`. 5. **Ändere die [Einstellungsdatei](https://platform.claude.com/docs/de/managed-agents/self-hosted/configuration-reference#where-settings-go).** Trage den Hostnamen des Empfängers in [`mcp.allowed_hostnames`](https://platform.claude.com/docs/de/managed-agents/self-hosted/differences#mcp-servers-need-an-allowlist-entry) ein und füge diesen Abschnitt hinzu: ```yaml agent_identity: issuer: https://agents.example.com key_file: /run/cma-server/agent-identity/signing-key.pem direct: audiences: - audience: https://mcp-gateway.example.com urls: - https://mcp-gateway.example.com ``` Jede `audience` benennt einen Empfänger als `https://`-URL. Ihre `urls` sind die URL-Präfixe der MCP-Server, die ein Token dafür empfangen können. 6. **Starte den Server neu.** Führe im Compose-Stack statt eines Neustarts `docker compose up -d` im Verzeichnis der Compose-Datei aus. Um den privaten Schlüssel aus Dateien herauszuhalten, verwende `key_secret` (deinen [Secret-Manager](https://platform.claude.com/docs/de/managed-agents/self-hosted/agent-identity#secret-manager)) oder `kms_key` (AWS KMS oder Google Cloud KMS). Die [Konfigurationsreferenz](https://platform.claude.com/docs/de/managed-agents/self-hosted/configuration-reference#agent-identity) beschreibt beide Einstellungen. ### Das Token an einen MCP-Server senden [MCP-Connector](https://platform.claude.com/docs/de/managed-agents/mcp-connector) beschreibt die Felder des MCP-Server-Eintrags eines Agenten. Füge diesem Eintrag ein `auth`-Feld hinzu: ```yaml mcp_servers: - type: url name: tickets url: https://mcp-gateway.example.com/tickets auth: type: agent_token audience: https://mcp-gateway.example.com ``` Für jede Tool-Auflistung oder jeden Tool-Aufruf signiert dein Server ein neues Token. Er sendet das Token als `Authorization: Bearer ` anstelle einer Vault-Anmeldeinformation. Weder das Modell noch der Worker erhalten es. Um sowohl das Token als auch [Vault-Anmeldedaten](https://platform.claude.com/docs/de/managed-agents/vaults) zu senden, ersetze das `auth`-Feld durch ein `agent_token_header`-Feld: ```yaml mcp_servers: - type: url name: tickets url: https://mcp-gateway.example.com/tickets agent_token_header: audience: https://mcp-gateway.example.com ``` Die Vault-Anmeldedaten werden im `Authorization`-Header gesendet, so wie bei einem Eintrag ohne eines der beiden Felder. Das Token wird in einem `Agent-Identity-Token`-Header gesendet, ohne `Bearer`-Präfix. Das SDK kennt die Felder `auth` und `agent_token_header` nicht. Füge das Feld im SDK-Code dem MCP-Server-Eintrag als zusätzliches Feld hinzu, oder sende die Anfrage als reines JSON. Diese Seiten zeigen, wie du zusätzliche Felder sendest: [Python SDK](https://platform.claude.com/docs/de/cli-sdks-libraries/sdks/python#undocumented-request-params) · [TypeScript SDK](https://platform.claude.com/docs/de/cli-sdks-libraries/sdks/typescript#undocumented-request-params) · [Go SDK](https://platform.claude.com/docs/de/cli-sdks-libraries/sdks/go#request-fields) · [Java SDK](https://platform.claude.com/docs/de/cli-sdks-libraries/sdks/java#undocumented-parameters) · [PHP SDK](https://platform.claude.com/docs/de/cli-sdks-libraries/sdks/php#undocumented-request-parameters) · [Ruby SDK](https://platform.claude.com/docs/de/cli-sdks-libraries/sdks/ruby#undocumented-request-params) Einige dieser Seiten zeigen zusätzliche Felder nur auf der obersten Ebene einer Anfrage, nicht innerhalb eines Listeneintrags. Mache in diesem Fall `mcp_servers` selbst zum zusätzlichen Feld. Sende die gesamte Liste auf diese Weise, mit `auth` oder `agent_token_header` in ihrem Eintrag. Um die Tokens eines Agenten zu stoppen, entferne den Eintrag aus dem Agenten oder archiviere den Agenten. Ein bereits gesendetes Token bleibt bis zu seinem `exp` gültig, standardmäßig höchstens 5 Minuten. ### Was der Empfänger prüft Lass den Empfänger eine Anfrage nur akzeptieren, wenn alle diese Bedingungen erfüllt sind: * Die Signatur lässt sich mit einem Schlüssel in deinem Key-Set, `/.well-known/jwks.json`, verifizieren. Der richtige Schlüssel ist derjenige, dessen ID mit `kid` im Header des Tokens übereinstimmt. Für einen RSA-Schlüssel ist der Algorithmus `RS256`. * `iss` entspricht deiner Issuer-URL, und `aud` entspricht der Audience des Empfängers. * `exp` liegt in der Zukunft, und `iat` liegt nicht in der Zukunft. * `typ` im Header des Tokens ist `agent+jwt`, und `token_use` ist `agent`. Wende dann diese Regeln an: * Stütze die Zugriffsregeln jedes Agenten auf den Claim `agent_id`, die ID des Agenten in der API. * Akzeptiere ein wiederholtes `jti`, da eine Auflistung oder ein Aufruf mehrere Anfragen mit demselben Token umfassen kann. * Lass ein Gateway jedes Tool mit seiner eigenen Anmeldeinformation aufrufen und das Token niemals weitergeben. Mit [Single Sign-On](https://platform.claude.com/docs/de/managed-agents/self-hosted/configure#single-sign-on) benennt das Token eines Tool-Aufrufs auch den Aufrufer, der die Sitzung erstellt hat, in den Claims `actor_sub` und `actor_iss`. `actor_sub` bedeutet nicht, dass der Aufrufer den Aufruf genehmigt hat. Das Modell wählt jeden Aufruf. Diese Tokens haben kein `actor_sub`: * Das Token einer Tool-Auflistung * Das Token eines Aufrufs eines Subagenten * Jedes Token einer Sitzung, die mit dem API-Key des Servers erstellt wurde Wenn eine Regel vom Aufrufer abhängt, lehne einen Tool-Aufruf ab, der kein `actor_sub` hat. ### Das MCP-Gateway testen Der Befehl `check-gateway` sendet einem MCP-Gateway gültige und ungültige Tokens. Gib dem Befehl eine eigene Einstellungsdatei, hier `check-gateway.yaml`: 1. Kopiere nur die Abschnitte `mcp` und `agent_identity` der Einstellungen des Servers in die Datei, sowie `limits.mcp_call_timeout`, wenn der Server diesen Wert setzt. 2. Ändere in der Kopie `key_file` auf den Pfad des Schlüssels auf dem Rechner, auf dem du den Befehl ausführst, etwa `./agent-identity/signing-key.pem`. Wenn du das Verzeichnis nach `compose` verschoben hast, ist das `./compose/agent-identity/signing-key.pem`. Gib für `-agent` die ID eines Agenten an, den das Gateway zulässt. Wenn root der Besitzer des Schlüssels ist, verwende `sudo`. ```bash ./cma-server check-gateway -config check-gateway.yaml -agent agent_011CYm1BLqPXpQRk5khsSXrs \ -url https://mcp-gateway.example.com/tickets ``` Der Befehl gibt für jede Anfrage, die er sendet, eine Zeile mit der Antwort des Gateways aus. Ein erfolgreicher Durchlauf gibt dann eine Zeile aus, die mit `check-gateway: PASS` beginnt, und beendet sich mit dem Code `0`. Ein fehlgeschlagener Durchlauf nennt in einer Zeile, die mit `check-gateway:` beginnt, was schiefgelaufen ist, und beendet sich mit dem Code `1`. ## Secret-Manager Standardmäßig speichert der Server die Secrets von [Vault-Anmeldedaten](https://platform.claude.com/docs/de/managed-agents/vaults) in seiner Datenbank. Mit einem `secret_store`-Abschnitt schreibt der Server das Secret neuer Vault-Anmeldedaten in deinen „secret manager“ (Secret-Manager), unter einem Namenspräfix, das du dafür reservierst. Die Datenbank behält nur eine Referenz. Füge den Block für deinen Secret-Manager zur [Einstellungsdatei](https://platform.claude.com/docs/de/managed-agents/self-hosted/configuration-reference#where-settings-go) hinzu: ```yaml secret_store: type: aws_secrets_manager region: us-east-1 prefix: cma-server/prod/ ``` ```yaml secret_store: type: gcp_secret_manager project: my-project # the project ID, not its number prefix: cma-server-prod-- ``` ```yaml secret_store: type: azure_key_vault vault_url: https://my-vault.vault.azure.net prefix: cma-server-prod-- ``` ```yaml secret_store: type: hashicorp_vault address: https://vault.internal:8200 prefix: cma-server/prod/ approle: role_id: secret_id_file: /run/vault/secret-id #kubernetes: { role: cma-server } #token_file: /run/vault/token ``` Setze genau eine der drei Anmeldemethoden: * **`approle`:** Verwende sie mit Docker Compose, auf einem Host oder mit dem Server-Helm-Chart. Der Server meldet sich mit einer Rollen-ID und mit einer Secret-ID an, die er aus einer Datei liest. * **`kubernetes`:** Verwende sie nur bei einer eigenen Kubernetes-Installation, deren Server-Pod ein Service-Account-Token hat. Der Server meldet sich mit diesem Token an. Das Server-Helm-Chart gibt den Pods des Servers kein solches Token, daher funktioniert diese Methode nicht mit dem Chart. * **`token_file`:** Verwende sie für jede andere Anmeldemethode von Vault. Führe Vault Agent neben dem Server aus und lass ihn sein Token in diese Datei schreiben. Gib dem Server beim Server-Helm-Chart die Secret-ID in einem Secret: 1. Lege die Secret-ID in einem Secret im Namespace des Servers ab und benenne dieses Secret in `server.extensionFiles.secretName` des Charts. 2. Setze `approle.secret_id_file` auf den Pfad der Secret-ID. Das Chart mountet jeden Schlüssel dieses Secrets als Datei unter `/run/cma-server/extension-files/`, daher liegt ein Schlüssel namens `secret-id` unter `/run/cma-server/extension-files/secret-id`. Binde für die `kubernetes`-Methode die Vault-Kubernetes-Rolle an den Namespace und das Service-Konto des Servers, nicht an den Namespace der Sandboxes, `cma`. ### Zugriff gewähren Gib dem Server eine Identität und beschränke sie auf das Präfix. Das Verzeichnis `iam/` des Archivs enthält eine Datei für jeden Secret-Manager: * **AWS Secrets Manager:** Ersetze die Platzhalter in `aws-secrets-manager-policy.json` und hänge die Policy an die Identität an, unter der der Server läuft. * **Google Cloud Secret Manager:** Führe die Befehle in den Kommentaren von `gcp-secret-manager-role.yaml` aus. * **Azure Key Vault:** Eine Azure-Rolle umfasst einen ganzen Key Vault, kein Präfix. Gib dem Deployment daher einen eigenen Key Vault, der die rollenbasierte Zugriffssteuerung von Azure verwendet. Ersetze `SUBSCRIPTION_ID` in `azure-key-vault-role.json` und erstelle daraus eine benutzerdefinierte Rolle. Weise die Rolle auf dem Key Vault der Identität zu, unter der der Server läuft. * **HashiCorp Vault:** Ersetze die Platzhalter in `hashicorp-vault-policy.hcl` und hänge die Policy an die Identität an, unter der der Server läuft. Gegenüber AWS und Google Cloud authentifiziert sich der Server so wie bei der Inferenz. Gegenüber Azure Key Vault authentifiziert er sich mit Microsoft Entra ID, so wie bei [Microsoft Foundry](https://platform.claude.com/docs/de/managed-agents/self-hosted/inference-provider#microsoft-foundry). ### Die Einrichtung prüfen Führe `validate-store` vor dem ersten Start und nach jeder Änderung der Policy aus. Der Befehl erstellt, liest und löscht ein Test-Secret unter dem Präfix, ohne den Server zu starten. Führe den Befehl dort aus, wo der Server läuft, mit der Umgebung des Servers: * **Docker Compose:** Führe ihn im Container des Servers aus. Ersetze auf Arm `linux_amd64` in diesem Befehl durch `linux_arm64`: ```bash docker compose exec cma-server /opt/cma-server/bin/linux_amd64/cma-server validate-store -config /etc/cma-server/config.yaml ``` * **Auf einem Host:** ```bash ./cma-server validate-store -config /etc/cma-server/config.yaml ``` * **Kubernetes:** Führe denselben Befehl als Job unter dem Service-Konto des Servers aus. Ein erfolgreicher Durchlauf endet mit einer Zeile, die `pass` lautet, und beendet sich mit dem Code `0`. Führe diese Prüfung mit Azure Key Vault gegen deinen Key Vault aus, bevor du dich darauf verlässt. ### Einschränkungen des Secret-Managers * **Lege die Einstellungen einmalig fest.** Nach jeder dieser Änderungen findet der Server die Secrets, die er vor der Änderung geschrieben hat, nicht mehr: * Du entfernst den `secret_store`-Abschnitt. * Du änderst `type`, `prefix`, `region`, `project`, `vault_url`, `mount` oder `namespace`. Die letzten beiden sind optionale HashiCorp-Vault-Einstellungen. * Du richtest `address` auf einen anderen Vault. Der Server findet diese Secrets erst wieder, wenn du die alten Werte wiederherstellst. * **Eine Identität liest das gesamte Präfix.** Wenn zwei Gruppen nicht auf die Anmeldeinformationen der jeweils anderen zugreifen dürfen, gib jeder Gruppe ein eigenes Deployment. Jedes Deployment braucht ein eigenes Präfix oder einen eigenen Key Vault und eine eigene Identität. ## Anmeldeinformationen als Umgebungsvariablen Mit einer [Anmeldeinformation als Umgebungsvariable](https://platform.claude.com/docs/de/managed-agents/vaults#add-a-credential) können die Befehle eines Agenten einen Dienst aufrufen, während die Sandbox nur einen Platzhalter für das Secret enthält. Das „egress gateway“ (Egress-Gateway) setzt den echten Wert in Anfragen an die Hosts ein, die die Anmeldeinformation auflistet. Das Gateway, `cma-egress`, ist ein Proxy im Release-Archiv, der zwischen deinen Sandboxes und dem Internet steht. Standardmäßig ist es ausgeschaltet, und dein Server akzeptiert diese Anmeldeinformationen nur bei eingeschaltetem Gateway. Bei eingeschaltetem Gateway gelten zwei Einschränkungen für deine Sandboxes: * Sandboxes erreichen das Internet nur über das Gateway. * Das Gateway verbindet sich nur mit den Hosts, die du in der Server-Einstellung `egress.allowed_hostnames` auflistest. Liste exakte öffentliche Hostnamen ohne Platzhalterzeichen auf. Nimm jeden Host auf, von dem die Befehle deiner Agenten etwas herunterladen. Wenn du ein eigenes Sandbox-Image erstellt hast, starte den Worker über `cma-with-egress`, wie [Ein eigenes Sandbox-Image erstellen](https://platform.claude.com/docs/de/managed-agents/self-hosted/call-the-api#what-an-image-of-your-own-needs) zeigt. ### Das Gateway im Compose-Stack einschalten Füge im Verzeichnis, das `docker-compose.yml` enthält, zwei Zeilen zu `.env` hinzu. Die erste listet die Hosts auf, mit denen sich das Gateway verbindet, durch Kommas getrennt. Die zweite lädt die Compose-Datei des Gateways. Starte dann den Stack: ```bash echo 'CMA_EGRESS__ALLOWED_HOSTNAMES=api.github.com' >> .env echo 'COMPOSE_FILE=docker-compose.yml:docker-compose.egress.yml' >> .env docker compose up --build -d ``` Wenn du zusätzlich eine weitere Compose-Datei verwendest, füge sie der `COMPOSE_FILE`-Zeile hinzu. Eine `COMPOSE_FILE`-Variable in deiner Shell überschreibt die Variable in `.env`, entferne daher die Variable der Shell mit unset. Die Datei des Gateways setzt die übrigen `egress`-Einstellungen des Servers, füge daher keinen `egress`-Abschnitt zu `compose.config.yaml` hinzu. ### Das Gateway auf Kubernetes einschalten Diese Schritte gehen vom Deployment aus [Auf Kubernetes bereitstellen](https://platform.claude.com/docs/de/managed-agents/self-hosted/kubernetes) aus. Sie verwenden die Variablen `REGISTRY`, `TAG` und `PLATFORM` dieser Seite sowie ihre beiden Values-Dateien. Führe die Befehle im obersten Verzeichnis des Archivs aus, mit OpenSSL 3.0 oder neuer. Das Sandbox-Chart bietet das Gateway auf Azure Kubernetes Service (AKS) nicht an. Das Upgrade des Server-Charts in diesen Schritten fügt außerdem eine Network Policy über die Pods der Server hinzu. Prüfe zwei der Ports, die sie abdeckt, bevor du beginnst: * **Port 9464, der Metrik-Port:** Die Policy schließt ihn. Wenn Prometheus diesen Port abfragt, setze `server.telemetry.prometheus.scraper.namespace` in `cma-server-values.yaml` auf den Namespace, in dem Prometheus läuft. * **Port 8400, der Port der API:** Die Policy lässt jede Quelle zu. Wenn eine eigene Policy einschränkt, wer Port 8400 erreicht, funktioniert diese Einschränkung nicht mehr. Network Policies summieren sich, daher kommt eine Verbindung durch, wenn irgendeine Policy sie zulässt. ```bash docker buildx build --platform "$PLATFORM" -f kubernetes/egress/Dockerfile -t "$REGISTRY/cma-egress:$TAG" --push . ``` ```bash (umask 077 && openssl req -x509 -newkey ec -pkeyopt ec_paramgen_curve:P-256 -nodes -days 825 \ -subj "/CN=cma-server egress gateway" \ -addext "basicConstraints=critical,CA:TRUE,pathlen:0" \ -addext "keyUsage=critical,keyCertSign,cRLSign" \ -keyout egress-ca.key -out egress-ca.crt) kubectl -n cma create secret tls cma-egress-ca --cert=egress-ca.crt --key=egress-ca.key kubectl -n cma-server create configmap cma-egress-ca --from-file=ca.crt=egress-ca.crt GATEWAY_KEY=$(openssl rand -hex 32) printf %s "$GATEWAY_KEY" | kubectl -n cma create secret generic cma-egress-gateway-key --from-file=gateway-key=/dev/stdin printf %s "$GATEWAY_KEY" | kubectl -n cma-server create secret generic cma-egress-gateway-key --from-file=gateway-key=/dev/stdin unset GATEWAY_KEY ``` Lösche dann `egress-ca.key`, den privaten Schlüssel der Zertifizierungsstelle. Jeder, der ihn besitzt, kann sich gegenüber deinen Sandboxes als jede beliebige Website ausgeben. Das Zertifikat ist 825 Tage gültig. Siehe [Das Zertifikat erneuern](https://platform.claude.com/docs/de/managed-agents/self-hosted/agent-identity#renew-the-certificate). Wenn die Umgebung noch keine Sitzungen ausgeführt hat, überspringe diesen Schritt. Eine Sandbox von vor der Änderung kann ihren Worker danach nicht starten. Diese Befehle löschen auch den Workspace jeder Sandbox: ```bash kubectl -n cma scale deployment cma-dispatcher --replicas=0 kubectl -n cma delete sandboxwarmpool cma-sandbox kubectl -n cma delete sandboxclaims --all ``` Führe auf Google Kubernetes Engine (GKE) zusätzlich diesen Befehl aus: ```bash kubectl -n cma delete sandboxes --all ``` Wiederhole `kubectl -n cma get sandboxes,pods,pvc`, bis nichts mehr gefunden wird. Der `helm upgrade` im Schritt „Die Sandbox-Seite einschalten“ startet den Dispatcher wieder. Wähle für das Gateway eine freie IPv4-Adresse im Service-Bereich des Clusters. Die Spalte `CLUSTER-IP` von `kubectl get svc -A` zeigt Adressen in diesem Bereich. Füge dies zu `cma-server-values.yaml` hinzu. Wenn die Datei bereits einen `server`-Block hat, führe diese Zeilen darin zusammen: ```yaml egressGateway: enabled: true proxyAddress: 34.118.224.53:3128 # the address that you chose, and port 3128 server: config: egress: allowed_hostnames: - api.github.com ``` Führe dann das Upgrade aus: ```bash helm upgrade cma-server kubernetes/server/chart --namespace cma-server -f cma-server-values.yaml --wait ``` Führe `kubectl -n cma-server get svc` aus, um die beiden Services des Servers aufzulisten. Bei einer Neuinstallation heißen sie `cma-server` und `cma-server-egress`. Ändere in `cma-values.yaml` `egress.mode` auf `gateway` und füge unter `egress` einen `gateway`-Block hinzu. Gib dem Block die beiden Namen, die der Befehl aufgelistet hat: ```yaml egress: mode: gateway gateway: serviceIP: 34.118.224.53 # the address that you chose serverService: cma-server serverEgressService: cma-server-egress apiServerCIDRs: - 203.0.113.10/32 # the cluster's API endpoint ``` Behalte die übrigen `egress`-Werte der Datei bei. Um die Adressen und den Port des API-Endpunkts auszugeben, führe `kubectl get endpoints kubernetes -n default` aus. Wenn der Port nicht 443 ist, setze zusätzlich `egress.gateway.apiServerPort`. ```bash helm upgrade cma kubernetes/chart --namespace cma -f cma-values.yaml --wait ``` Wenn das Upgrade bei einem Konflikt über `.spec.replicas` abbricht, führe `kubectl -n cma scale deployment cma-dispatcher --replicas=1` aus und führe dann das Upgrade erneut aus. ### Eine Anmeldeinformation hinzufügen Erstelle eine Anmeldeinformation als Umgebungsvariable, wie [Eine Anmeldeinformation hinzufügen](https://platform.claude.com/docs/de/managed-agents/vaults#add-a-credential) zeigt. Die Leitfäden zum gehosteten Dienst besagen, dass diese Anmeldeinformationen mit selbst gehosteten Sandboxes nicht unterstützt werden. Das beschreibt den gehosteten Dienst, nicht deinen Server. Dein Server fügt eigene Regeln hinzu. Er lehnt eine Anfrage, die gegen eine davon verstößt, mit einem `400`-Fehler ab, der das Feld benennt. Zwei dieser Regeln folgen: * `networking` (csharp, go: `Networking`) muss den Typ `limited` haben, und jeder Host in `allowed_hosts` (java, php: `allowedHosts`; csharp, go: `AllowedHosts`) muss auf der `egress.allowed_hostnames`-Liste des Servers stehen. * `injection_location` (java, php: `injectionLocation`; csharp, go: `InjectionLocation`) muss in JSON `{"header": true}` sein und darf nicht weggelassen werden. Nachdem du einen Host zur Liste des Servers hinzugefügt hast, wende die Änderung an. Führe auf Docker Compose `docker compose up -d` aus. Führe auf Kubernetes den `helm upgrade`-Befehl des Servers und `kubectl -n cma-server rollout restart deployment -l anthropic.com/role=server` aus. ### Das Egress-Gateway prüfen Erstelle eine Sitzung mit dem Vault der Anmeldeinformation und bitte den Agenten, zwei Befehle auszuführen. Dieses Beispiel gilt für eine Anmeldeinformation namens `GITHUB_TOKEN`, die `api.github.com` auflistet: ```bash printenv GITHUB_TOKEN curl -sS -H "Authorization: Bearer $GITHUB_TOKEN" https://api.github.com/user ``` Der erste Befehl gibt einen Platzhalter aus, der mit `cma_ph_` beginnt. Der zweite gibt das Profil des GitHub-Kontos des Tokens aus, weil das Gateway den Platzhalter durch das Token ersetzt hat. Das Gateway lehnt eine Anfrage an einen Host, der nicht auf deiner Liste steht, mit einem `403`-Fehler ab. Wenn auf Kubernetes jede Anfrage einen `503`-Fehler erhält, schreibt das Netzwerk deines Clusters wahrscheinlich die Adressen der Pods um, wie es die Option `--masquerade-all` von kube-proxy tut. Das Gateway unterscheidet Sandboxes anhand der Adressen ihrer Pods, daher müssen diese Adressen es unverändert erreichen. ### Das Zertifikat erneuern Erneuere das Zertifikat auf Kubernetes, während keine Sitzung läuft. Wiederhole den gesamten Schritt „Die Zertifizierungsstelle und den Schlüssel des Gateways erstellen“ in [Das Gateway auf Kubernetes einschalten](https://platform.claude.com/docs/de/managed-agents/self-hosted/agent-identity#turn-on-the-gateway-on-kubernetes). Er erstellt die Zertifizierungsstelle und den Schlüssel des Gateways erneut, daher brauchst du die gelöschte Datei `egress-ca.key` nicht. Nimm eine Änderung vor: Füge `--dry-run=client -o yaml | kubectl apply -f -` am Ende jeder der vier Zeilen hinzu, die `kubectl create` ausführen. Eine Zeile, die beispielsweise auf `--from-file=gateway-key=/dev/stdin` endet, endet dann auf `--from-file=gateway-key=/dev/stdin --dry-run=client -o yaml | kubectl apply -f -`. Starte dann die Server und das Gateway neu: ```bash kubectl -n cma-server rollout restart deployment -l anthropic.com/role=server kubectl -n cma rollout restart deployment/cma-egress ``` ### Einschränkungen des Egress-Gateways * **Header:** Das Gateway setzt einen Wert nur in einen Anfrage-Header ein, niemals in eine URL oder einen Body. Standardmäßig ist `Authorization` der einzige Header. Um weitere zuzulassen, liste sie zusammen mit `Authorization` in `egress.swap_header_names` auf, oder für den Compose-Stack in `CMA_EGRESS__SWAP_HEADER_NAMES` in `.env`. * **Programme, die Proxy-Variablen ignorieren:** Sandboxes finden das Gateway über `HTTPS_PROXY` und verwandte Variablen. Java-Tools wie Maven und Gradle lesen diese Variablen nicht, daher erreichen sie nichts.