Claude Platform Docs
Managed AgentsKonfiguration für Unternehmen

Agent-Identität und Anmeldeinformationen

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.

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: 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: Der Server speichert Vault-Anmeldedaten in AWS Secrets Manager, Google Cloud Secret Manager, HashiCorp Vault oder Azure Key Vault.
  • Anmeldeinformationen als Umgebungsvariablen: 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:

    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.

    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.

  5. Ändere die Einstellungsdatei. Trage den Hostnamen des Empfängers in mcp.allowed_hostnames ein und füge diesen Abschnitt hinzu:

    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) oder kms_key (AWS KMS oder Google Cloud KMS). Die Konfigurationsreferenz beschreibt beide Einstellungen.

Das Token an einen MCP-Server senden

MCP-Connector beschreibt die Felder des MCP-Server-Eintrags eines Agenten. Füge diesem Eintrag ein auth-Feld hinzu:

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 <token> anstelle einer Vault-Anmeldeinformation. Weder das Modell noch der Worker erhalten es.

Um sowohl das Token als auch Vault-Anmeldedaten zu senden, ersetze das auth-Feld durch ein agent_token_header-Feld:

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 · TypeScript SDK · Go SDK · Java SDK · PHP SDK · Ruby SDK

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, <issuer>/.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 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.

./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 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 hinzu:

secret_store:
  type: aws_secrets_manager
  region: us-east-1
  prefix: cma-server/prod/

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.

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:

    docker compose exec cma-server /opt/cma-server/bin/linux_amd64/cma-server validate-store -config /etc/cma-server/config.yaml

  • Auf einem Host:

    ./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 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 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:

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 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.

  1. Das Image des Gateways erstellen und pushen

    docker buildx build --platform "$PLATFORM" -f kubernetes/egress/Dockerfile -t "$REGISTRY/cma-egress:$TAG" --push .

  2. Die Zertifizierungsstelle und den Schlüssel des Gateways erstellen

    (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.

  3. Die Sandboxes früherer Sitzungen entfernen

    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:

    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:

    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.

  4. Die Serverseite einschalten

    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:

    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:

    helm upgrade cma-server kubernetes/server/chart --namespace cma-server -f cma-server-values.yaml --wait

  5. Die Sandbox-Seite einschalten

    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:

    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.

    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 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 muss den Typ limited haben, und jeder Host in allowed_hosts muss auf der egress.allowed_hostnames-Liste des Servers stehen.
  • injection_location 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:

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. 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:

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.

War diese Seite hilfreich?