Claude-Apps-Gateway für Amazon Bedrock, Claude Platform auf AWS, Google Cloud und Microsoft Foundry

• Warum Claude-Apps-Gateway, was es gegenüber dem Betrieb Ihres eigenen hinzufügt, und wann etwas anderes besser passt
• Ein Schnellstart mit Voraussetzungen, der ein Gateway von Null zu einem angemeldeten Entwickler bringt
• Entwickler verbinden, einschließlich der Einstellung der Gateway-URL durch verwaltete Einstellungen
• Verfügbarkeit und Einschränkungen, die abdecken, welche Claude-Code-Funktionen über das Gateway funktionieren und was der Server unterstützt

​

Warum Claude apps gateway

• Anmeldedaten: Der Upstream-API-Schlüssel oder die Cloud-Anmeldedaten befinden sich nur in Ihrer Infrastruktur. Entwickler authentifizieren sich mit Corporate SSO und erhalten kurzlebige Bearer-Token, daher erfolgt das Offboarding in Ihrem IdP. Heben Sie die Bereitstellung eines Benutzers auf und sein Gateway-Zugriff läuft innerhalb der Sitzungsdauer ab, standardmäßig eine Stunde.
• Zugriffskontrolle: Ihre IdP-Gruppen werden Modell-Allowlists, verwaltete Einstellungen-Richtlinien und Upstreams zugeordnet. Das Gateway erzwingt Modellzugriff auf der Serverseite, lehnt Anfragen für nicht gewährte Modelle ab und wählt die verwaltete Einstellungsrichtlinie jeder Gruppe aus, die die CLI auf der Ebene der verwalteten Einstellungen anwendet. Verschiedene Teams erhalten verschiedene Modelle, Tools und Berechtigungen, und ein Entwickler kann nicht überschreiben, was seine Richtlinie sperrt.
• Einstellungsbereitstellung: Das Gateway liefert verwaltete Einstellungen selbst an angemeldete Clients und ersetzt servergesteuerte Einstellungen aus der claude.ai-Admin-Konsole.
• Telemetrie: Jedes konfigurierte Ziel empfängt OpenTelemetry-Protokoll (OTLP)-Metriken mit Token-Zählungen, Modell, Benutzeridentität und Latenz standardmäßig, mit Protokollen und Traces als optionale Ziele pro Ziel.
• Upstream-Routing: Clients sprechen die Anthropic Messages API mit dem Gateway, und das Gateway übersetzt für jeden Upstream, ob Amazon Bedrock, Claude Platform on AWS, Google Clouds Agent Platform, Microsoft Foundry oder die Anthropic API, mit Failover zwischen ihnen. Sie können Regionen, Anbieter oder Failover-Reihenfolge ändern, ohne dass Entwickler dies bemerken oder neu konfigurieren müssen.

​

Andere Gateway-Implementierungen

​

Schnellstart

​

Voraussetzungen

​

Schritte

listen:
  host: 0.0.0.0
  port: 8080
  # Erforderlich, sofern der Host keine Loopback-Adresse ist. Wird für den IdP
  # redirect_uri und das Discovery-Dokument verwendet.
  public_url: https://claude-gateway.internal.example.com

oidc:
  issuer: https://login.example.com        # muss /.well-known/openid-configuration bedienen
  client_id: 0oa1example2
  client_secret: ${OIDC_CLIENT_SECRET}
  allowed_email_domains: [example.com]        # lehne id_tokens außerhalb Ihrer Organisation ab
  userinfo_fallback: true                  # für IdPs, deren id_token E-Mail/Gruppen auslässt; ansonsten harmlos

session:
  jwt_secret: ${GATEWAY_JWT_SECRET}        # openssl rand -base64 32
  ttl_hours: 1                             # begrenzt auch die Widerrufungslatenz bei IdP-Entbereitstellung

store:
  postgres_url: ${GATEWAY_POSTGRES_URL}    # fügen Sie ?sslmode=require für verwaltetes Postgres hinzu

upstreams:
  - provider: bedrock
    region: us-east-1
    auth: {} # leer: AWS-Standard-Anmeldekette
# (IRSA, EC2/ECS-Task-Rolle, Umgebungsvariablen, ~/.aws)

# Modelle werden pro Upstream automatisch übersetzt. Der integrierte Katalog
# ordnet claude-opus-4-8 us.anthropic.claude-opus-4-8 zu und so weiter für jedes
# von Bedrock unterstützte Claude-Modell. Setzen Sie false und fügen Sie eine `models:`-Liste hinzu, um
# nur bestimmte Modelle verfügbar zu machen.
auto_include_builtin_models: true

services:
  gateway:
    image: registry.example.com/claude-gateway:2.1.198
    ports: ["8080:8080"]
    volumes: ["./gateway.yaml:/etc/claude/gateway.yaml:ro"]
    environment:
      OIDC_CLIENT_SECRET: ${OIDC_CLIENT_SECRET}
      GATEWAY_JWT_SECRET: ${GATEWAY_JWT_SECRET}
      GATEWAY_POSTGRES_URL: postgres://gw:pw@postgres/gateway
      # AWS-Anmeldedaten: in der Produktion diese auslassen und eine Instance-Rolle verwenden.
      # Für lokales Compose-Testen, übergeben Sie Ihre eigenen:
      AWS_ACCESS_KEY_ID: ${AWS_ACCESS_KEY_ID}
      AWS_SECRET_ACCESS_KEY: ${AWS_SECRET_ACCESS_KEY}
      AWS_SESSION_TOKEN: ${AWS_SESSION_TOKEN}
    depends_on:
      postgres:
        condition: service_healthy
  postgres:
    image: postgres:16-alpine
    environment: { POSTGRES_USER: gw, POSTGRES_PASSWORD: pw, POSTGRES_DB: gateway }
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U gw"]
      interval: 5s
    volumes: ["pgdata:/var/lib/postgresql/data"]
volumes: { pgdata: }

{"ts":"2026-06-10T17:03:21.114Z","evt":"config.load","path":"/etc/claude/gateway.yaml","sha256":"…"}
[gateway] 2026-06-10T17:03:21.395Z info waiting for migration lock (another replica may be migrating; check pg_locks for key 6775156 if this persists)
[gateway] 2026-06-10T17:03:21.408Z info migration 1 applied
…
[gateway] 2026-06-10T17:03:21.431Z info migration 6 applied
[gateway] 2026-06-10T17:03:21.512Z info claude gateway listening on http://0.0.0.0:8080

curl -s https://claude-gateway.internal.example.com/.well-known/oauth-authorization-server | jq

{
  "issuer": "https://claude-gateway.internal.example.com",
  "device_authorization_endpoint": "…/oauth/device_authorization",
  "token_endpoint": "…/oauth/token",
  "grant_types_supported": ["urn:ietf:params:oauth:grant-type:device_code", "refresh_token"]
}

curl -s -X POST https://claude-gateway.internal.example.com/oauth/device_authorization | jq

{
  "device_code": "…",
  "user_code": "WDJB-MJHT",
  "verification_uri": "https://claude-gateway.internal.example.com/device",
  "verification_uri_complete": "https://claude-gateway.internal.example.com/device?user_code=WDJB-MJHT",
  "expires_in": 600,
  "interval": 5
}

​

Entwickler verbinden

openssl x509 -noout -fingerprint -sha256 -in cert.pem | cut -d= -f2 | tr -d : | tr 'A-F' 'a-f'

​

Gateway-URL festlegen

{
  "forceLoginMethod": "gateway",
  "forceLoginGatewayUrl": "https://claude-gateway.internal.example.com",
  "parentSettingsBehavior": "merge"
}

​

Gateway-URL in den Benutzereinstellungen festlegen

{
  "forceLoginMethod": "gateway",
  "forceLoginGatewayUrl": "https://claude-gateway.internal.example.com"
}

• Nur Benutzereinstellungen: Claude Code liest die beiden Schlüssel aus ~/.claude/settings.json, nicht aus der .claude/settings.json oder .claude/settings.local.json eines Projekts.
• Verwaltete Einstellungen deaktivieren sie: Sobald die Einstellungen eines Administrators die Maschine über eine Datei mit verwalteten Einstellungen, eine macOS-Plist oder Windows-HKLM-Richtlinie oder einen Policy-Helper erreichen, ignoriert Claude Code ein in den Benutzereinstellungen benanntes Gateway.

​

Ein Gateway auf öffentlichem Adressraum zulassen, den Sie besitzen

{
  "gatewayInternalNetworks": ["203.0.113.0/24"]
}

• Jeder Eintrag ist ein IPv4-Block, geschrieben als seine erste Adresse und ein Präfix von /8 bis /32.
• Die Liste enthält höchstens vier Blöcke, und keine zwei überlappen sich.
• Kein Block überlappt privaten Adressraum: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 127.0.0.0/8, 169.254.0.0/16 und 100.64.0.0/10. /login akzeptiert ein Gateway dort bereits ohne diesen Schlüssel.
• Kein Block überlappt Raum, der niemals das Netzwerk einer Organisation ist: 198.18.0.0/15 und 192.0.0.0/24, die VPN- und NAT64-Clients als lokale Adressen halten; die Dokumentationsbereiche 192.0.2.0/24, 198.51.100.0/24 und 203.0.113.0/24; und die reservierten Bereiche 0.0.0.0/8, 192.88.99.0/24 und Multicast 224.0.0.0/4. Sie können Blöcke in 240.0.0.0/4 deklarieren, die einige große Netzwerke als internen Unicast-Raum verwenden.

• Jede Adresse, zu der sich der Hostname des Gateways auflöst, liegt in diesem einen Block. Claude Code lehnt einen Namen ab, der auch Datensätze außerhalb davon, private und IPv6-Adressen eingeschlossen, hat.
• Die Maschine des Entwicklers verbindet sich von innerhalb desselben Blocks. Claude Code lehnt eine Maschine hinter NAT, in einem Container oder WSL2 oder auf einem VPN ab, dessen Adresspool außerhalb des Blocks liegt, und benennt die Adresse, von der sich die Maschine verbunden hat.
• Die Verbindung ist direkt. Wenn HTTPS_PROXY für den Gateway-Host gilt, lehnt /login ab und benennt den NO_PROXY-Eintrag, der hinzugefügt werden soll.

​

Richtlinie an Claude Desktop-Sitzungen liefern

​

Welche Maschinen benötigen die Opt-in

​

Opt-in festlegen

​

Übergeordnete Einstellungen einschränken

• deny-Einträge: weitergeleitet mit nur ihrem path oder name und dem Modus.
• Dateieinträge mit mode: mask: weitergeleitet nur als Sentinel, als vollständige Dateimaskierung, deren injectHosts die leere Liste ist, daher ersetzt der Proxy niemals den echten Wert für einen übergeordneten Eintrag auf einer beliebigen Plattform. Alle strukturierten Maskierungsfelder werden ebenfalls gelöscht, daher kann ein übergeordnetes Extraktionsmuster keine strengere Maskierung verdrängen, die eine andere Quelle für denselben Pfad setzt.
• envVars-Einträge mit mode: mask: nicht weitergeleitet. deny ist die einzige Einschränkung, die der übergeordnete Kanal durch envVars-Einträge ausdrücken kann.
• awsPairs und sigv4: nur als Einschränkung weitergeleitet. Aus sigv4 werden nur deny-Werte beibehalten, und ein übergeordneter Prozess, der überhaupt einen sigv4-Block definiert, setzt alle drei Anfrageformen, streaming, presigned und sigv4a, fest auf deny. Ein awsPairs-Paar wird niemals in einer Form weitergeleitet, die erneut signieren kann; ein Paar, das eine der konventionellen AWS-Variablen benennt, wird durch einen inerten Eintrag ersetzt, der die automatische Kopplung von AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY und AWS_SESSION_TOKEN unterdrückt.

​

Sperren bereitstellen

{
  "forceLoginMethod": "gateway",
  "forceLoginGatewayUrl": "https://claude-gateway.internal.example.com",
  "parentSettingsBehavior": "merge",
  "allowManagedPermissionRulesOnly": true,
  "allowManagedMcpServersOnly": true,
  "allowManagedHooksOnly": true,
  "allowedMcpServers": [{ "serverUrl": "https://mcp.internal.example.com/*" }],
  "sandbox": {
    "network": {
      "allowManagedDomainsOnly": true,
      "allowedDomains": ["github.com", "*.npmjs.org"]
    },
    "filesystem": {
      "allowManagedReadPathsOnly": true,
      "denyRead": ["~/"],
      "allowRead": ["~/projects"]
    }
  }
}

​

Sperrverhalten über Quellen hinweg

• Netzwerkdomänen: Das Sperren mit einer leeren verwalteten Domänenliste blockiert den gesamten ausgehenden Verkehr in der Sandbox.
• MCP-Server: Das Sperren ohne allowedMcpServers in einer Admin-Quelle oder in den übergeordneten Einstellungen lädt jeden Server, den deniedMcpServers nicht blockiert.
• Lesepfade: allowRead-Einträge erlauben nur Pfade in denyRead-Regionen erneut, daher koppeln Sie sie mit einem verwalteten denyRead.

​

Einstellungen, die die Sperren nicht abdecken

• forceLoginOrgUUID: Claude Code berücksichtigt einen übergeordneten Wert, wenn die verwalteten Einstellungen, die es anwendet, keine Organisations-UUID setzen. Gateway-Anmeldung überprüft diesen Schlüssel nicht. Eine Organisations-UUID in den verwalteten Einstellungen, die Claude Code anwendet, blockiert den übergeordneten Wert und ist die Organisations-UUID, die Claude Code erzwingt. Wenn Ihre Flotte eine Anthropic-Organisation festlegt, finden Sie unter Welche verwaltete Quelle Anmeldeschlüssel liefert, wo Sie forceLoginOrgUUID setzen.
• allowedMcpServers: Claude Code berücksichtigt eine übergeordnete Allowlist, wenn keine Admin-Liste in Kraft ist. allowManagedMcpServersOnly blockiert sie nicht, da die Sperre diejenige Liste als verwalteten Wert erzwingt, die gewinnt, einschließlich einer übergeordneten Liste, wenn keine Admin-Quelle eine Liste liefert. Eine Liste in der Admin-Quelle mit der höchsten Priorität blockiert die übergeordnete und ist die Liste, die Claude Code erzwingt, daher setzen Sie allowedMcpServers dort, neben der Sperre. Vor v2.1.223 blockierte ein Wert für einen der beiden Schlüssel in jeder Admin-Quelle den übergeordneten.
• availableModels: Claude Code berücksichtigt eine übergeordnete Modelliste, wenn die gewinnende verwaltete Quelle keine setzt. Wenn Ihre Flotte Modelle einschränkt, setzen Sie availableModels in der Gewinnerquelle.
• allowedProviders: Claude Code berücksichtigt eine übergeordnete Allowlist für API-Anbieter, wenn die gewinnende verwaltete Quelle keine setzt. Wenn Ihre Flotte einschränkt, welche API-Anbieter Entwickler verwenden können, setzen Sie allowedProviders in der Gewinnerquelle. Erfordert Claude Code v2.1.285 oder später.
• strictKnownMarketplaces: Claude Code berücksichtigt eine übergeordnete Plugin-Marketplace-Allowlist, wenn die gewinnende verwaltete Quelle keine setzt. Claude Desktop 2.16120.0 oder später sendet eine, wenn seine verwaltete Konfiguration von Benutzern hinzugefügte Plugin-Marketplaces ausschaltet. Wenn Ihre Flotte Marketplaces einschränkt, setzen Sie strictKnownMarketplaces in der Gewinnerquelle. Erfordert Claude Code v2.1.282 oder später.
• blockedMarketplaces: eine übergeordnete Marketplace-Blockliste passiert und ergänzt jede Blockliste, die eine verwaltete Quelle setzt, da eine Blockliste nur weiter einschränken kann. Erfordert Claude Code v2.1.282 oder später.
• strictPluginOnlyCustomization: dieser Schlüssel passiert den Filter unabhängig von jeder Sperre, und er lässt Claude Code die eigene Anpassung des Entwicklers ignorieren, einschließlich schützender Hooks. Keine Sperre blockiert ihn.

​

Wie Hook- und Skill-Schlüssel in übergeordneten Einstellungen wirksam werden

• Stoppen: Benutzer-, Projekt- und lokale Hooks sowie Hooks, die im Frontmatter eines Agenten oder in der settings-Option des SDK deklariert sind.
• Laufen weiter: die SDK-Hook-Callbacks Ihrer Anwendung und die Hooks eines Administrators aus verwalteten Einstellungen. Ihre Anwendung kann die Hooks des Administrators nicht ausschalten.

​

Claude Desktop verbinden

​

CI-Pipelines und Remote-Maschinen

​

Was auf Entwickler erzwungen wird

• Modellzugriff: Anfragen für Modelle, die die Richtlinie nicht gewährt, geben 400 zurück, und die /model-Auswahl wird auf die availableModels-Allowlist der Richtlinie gefiltert. Dies schließt das Modell ein, mit dem eine Sitzung startet, bevor der Entwickler eines auswählt; siehe Sitzungen mit einem Modell starten, das die Richtlinie zulässt.
• Telemetrie-Ziel: In Sitzungen, die sich über /login angemeldet haben, sendet die CLI ihre OTLP/HTTP-Exporte an das Gateway statt an einen lokal gesetzten OTEL_EXPORTER_OTLP_ENDPOINT, es sei denn, eine Richtlinie benennt Ihren Collector als Endpunkt. Das Gateway leitet die Exporte, die es empfängt, an die Ziele in telemetry.forward_to weiter.
  • In den eingebetteten Sitzungen, die Claude Desktop startet, sendet die CLI ihre Exporte an den konfigurierten OTEL_EXPORTER_OTLP_ENDPOINT. Die CLI hängt das Gateway-Sitzungstoken an diese Exporte nur an, wenn dieser Endpunkt auf das Gateway selbst zeigt.
  • Ohne konfiguriertes Ziel für ein Signal akzeptiert das Gateway es und verwirft es.
  • Wenn Sie bereits Claude Code-Telemetrie direkt erfassen, fügen Sie Ihren Collector als forward_to-Ziel hinzu, oder benennen Sie ihn in einer Richtlinie, um das Relay zu überspringen.
• Anmeldedaten: Das Gateway-Token ist die einzige Anmeldeinformation der Sitzung. Anthropic-Profile und jede frühere claude.ai-Anmeldung werden ignoriert, während Sie angemeldet sind, daher müssen sich Entwickler nicht zuerst von claude.ai abmelden. Für konfigurierte ANTHROPIC_API_KEY-, ANTHROPIC_AUTH_TOKEN- oder apiKeyHelper-Anmeldedaten oder einen API-Schlüssel, der durch eine frühere Claude Console-Anmeldung gespeichert wurde, siehe Administratorrichtlinie erfordert eine Cloud-Gateway-Anmeldung.
• Verwaltete Einstellungen: Gesperrte Schlüssel können nicht lokal überschrieben werden. Die CLI wendet die Richtlinie beim Start an und wendet Änderungen bei jeder stündlichen Abfrage an, abgesehen von den Änderungen, die nur beim nächsten Start angewendet werden.
• Start bei nicht erreichbarem Gateway: Angemeldete Sitzungen beenden sich beim Start mit einem Fehler nach etwa 10 Sekunden, anstatt ohne ihre Einstellungen zu starten.
• Start, nachdem das Gateway die Sitzung beendet hat: siehe Fail-Closed-Startup erzwingen für die Starts, die vom Gateway abgemeldet öffnen, und die, die sich beenden, wenn das Gateway mit einem 401 antwortet.
• Entbereitstellung: Eine Sitzung, deren Benutzer im IdP deaktiviert ist, läuft innerhalb von ttl_hours ab, wenn die nächste Aktualisierung fehlschlägt.
• Abmeldung: /logout löscht die Gateway-Anmeldedaten von der Maschine des Entwicklers.
  • Wenn das Discovery-Dokument des Gateways einen revocation_endpoint auf dem eigenen Schema, Host und Port der Gateway-URL bewirbt, sendet /logout auch die gespeicherten Token an diesen Endpunkt, damit das Gateway die Sitzung auf seiner Seite beenden kann. Die Anfrage ist Best Effort, daher wird die Abmeldung auf der Maschine des Entwicklers abgeschlossen, unabhängig davon, ob der Endpunkt antwortet. Die Sperrung erfordert Claude Code v2.1.275 oder später auf der Entwicklermaschine.
  • Der Gateway-Server in der claude-Binärdatei bewirbt keinen, daher beendet eine Abmeldung von ihm die Sitzung nur auf der Maschine des Entwicklers. Um Sitzungen serverseitig zu beenden, siehe JWT-Geheimnis-Rotation.

​

Was die Organisation sehen kann

​

Verfügbarkeit und Einschränkungen

​

Nächste Schritte

• Erweitern Sie gateway.yaml über die minimale Konfiguration hinaus, um beispielsweise Pro-Gruppen-RBAC, Multi-Upstream-Failover oder Telemetrie-Ziele hinzuzufügen. Die Konfigurationsreferenz behandelt jede Option.
• Wechseln Sie von Compose zu einer Produktionsbereitstellung auf Kubernetes oder Cloud Run, richten Sie Ihren IdP ordnungsgemäß ein und überprüfen Sie das Sicherheitsmodell. Der Bereitstellungs- und Operationsleitfaden behandelt IdP-spezifische Einrichtung, Container-Image-Anforderungen, Health-Probes und Fehlerbehebung.
• Legen Sie Ausgabengrenzen für einzelne Entwickler oder Gruppen fest, damit eine unkontrollierte Workload Ihre gesamte Verpflichtung nicht verbrauchen kann. Ausgabenlimits behandelt die Admin-API und wie die Durchsetzung funktioniert.
• Für ein vollständiges durchgearbeitetes Beispiel auf AWS mit ECS Fargate oder EKS, Amazon RDS und Secrets Manager siehe Bereitstellung auf AWS.
• Für ein vollständiges durchgearbeitetes Beispiel auf Google Cloud mit Cloud Run, Cloud SQL und Secret Manager siehe Bereitstellung auf Google Cloud.