gateway.yaml. Il file definisce tutto ciò che il gateway fa: dove ascolta, come gli sviluppatori accedono, dove va l’inferenza e quali criteri e telemetria si applicano. Questa pagina è il riferimento per ogni opzione in quel file.
Per scrivere il vostro primo file, iniziate dalla guida rapida, che crea una configurazione minima funzionante e la esegue. Una volta che avete una configurazione con cui siete soddisfatti, la guida alla distribuzione copre la containerizzazione e l’hosting su Kubernetes, Cloud Run o la vostra piattaforma.
Il gateway legge il file una volta, all’avvio, con claude gateway --config /path/to/gateway.yaml. Ogni opzione è convalidata rispetto a uno schema all’avvio, quindi una configurazione malformata non riesce all’inizio con un errore a livello di campo piuttosto che al primo utilizzo.
L’esempio completo alla fine di questa pagina esercita ogni sezione.
Struttura del file
Cinque sezioni sono obbligatorie. Ogni altra sezione è facoltativa e una sezione omessa assume i suoi valori predefiniti. Le chiavi sconosciute causano un errore all’avvio, quindi un errore di battitura emerge come errore denominato piuttosto che come impostazione ignorata silenziosamente. Sezioni obbligatorie:listen: indirizzo di binding, URL pubblico, terminazione TLSoidc: il vostro provider di identità (IdP), inclusi emittente, client, mappatura dei claim e chi può accederesession: i token bearer che il gateway conia, con segreto e duratastore: PostgreSQL, per le concessioni dei dispositivi e i contatori dei limiti di velocitàupstreams: dove va l’inferenza, sia Anthropic, Amazon Bedrock, Claude Platform su AWS, Agent Platform di Google Cloud o Microsoft Foundry
admin: autenticazione dell’API Admin e conservazione dei limiti di spesaenforcement: comportamento fail-open o fail-closed dei limiti di spesamodelseauto_include_builtin_models: elenco di modelli curato dall’amministratore e ID per upstreammanaged: politiche di impostazioni gestite per gruppo IdPtelemetry: inoltro OTLP al vostro stack di osservabilitàaccess_control,limits,timeouts,rate_limits: IP allow/deny, limiti di dimensione delle richieste, time-to-first-byte upstream e limiti di accesso per IP
Espansione dei segreti
Non scrivete segreti comeclient_secret, jwt_secret o postgres_url direttamente in gateway.yaml. Fate riferimento ad essi con uno dei moduli sottostanti e il gateway risolve il valore all’avvio da una variabile di ambiente o da un file:
Sezioni obbligatorie
listen
Il blocco listen controlla dove il gateway serve: l’indirizzo di binding e la porta, l’origine visibile esternamente e la terminazione TLS facoltativa.
oidc
Il blocco oidc connette il gateway al vostro provider di identità e decide chi può accedere. Nomina l’emittente e il client OAuth, mappa i claim che portano email e gruppi e limita l’accesso per dominio email o gruppo.
OpenID Connect (OIDC) è il protocollo SSO che il gateway utilizza con il vostro provider di identità; vedere Configurazione del provider di identità per ciò che registrare sul lato IdP.
session
Il blocco session modella i token bearer che il gateway conia dopo l’accesso: il segreto che li firma e quanto a lungo vivono.
store
Il blocco store punta il gateway al suo database PostgreSQL, che contiene le concessioni dei dispositivi e i contatori dei limiti di velocità.
Per lo sviluppo locale, puntate
postgres_url a un contenitore Postgres usa e getta, ad esempio docker run --rm -p 5432:5432 -e POSTGRES_HOST_AUTH_METHOD=trust postgres.
upstreams
upstreams è un elenco ordinato. Il gateway inoltra l’inferenza al primo upstream che risolve il modello richiesto. Su 5xx, 429, 401, 403, 404 o timeout esegue il failover al successivo; altri 4xx no, perché questi errori sono attribuibili alla richiesta piuttosto che all’upstream. Un 401 o 403 significa che la credenziale del gateway stesso non ha funzionato contro quell’upstream, e un 404 significa che quell’upstream non serve il modello richiesto, quindi un upstream successivo nell’elenco può ancora servirlo.
Il failover su 404 richiede gateway v2.1.198 o successivo. Le versioni precedenti hanno restituito il primo 404 al client anche quando un upstream successivo nell’elenco serviva il modello.
Più upstream dello stesso provider devono impostare un name: distinto.
I client Amazon Bedrock, Claude Platform on AWS, Google Cloud Agent Platform e Microsoft Foundry sono costruiti una volta all’avvio e i loro SDK aggiornano le credenziali internamente, quindi la rotazione delle credenziali cloud non richiede un riavvio. Le chiavi API Anthropic statiche e i bearer sono letti all’avvio; vedere API Anthropic.
API Anthropic
L’upstream Anthropic minimo è una chiave API dalla Console Claude:api_key: inviax-api-key. Ruotatela nella Console Claude e aggiornate la variabile env.oauth_token: inviaAuthorization: Bearer. Usate la forma bearer quando la vostra organizzazione emette token a breve durata invece di chiavi API a lunga durata. Il bearer è letto una volta all’avvio, quindi aggiornate rimontando il segreto e riavviando.
Amazon Bedrock
Per la distribuzione Bedrock lato client che il gateway sostituisce o fronteggia, vedere Claude Code su Amazon Bedrock. L’upstream lato gateway:auth vuoto usa la catena di credenziali predefinita dell’AWS SDK: variabili env, ~/.aws/credentials, ruolo di attività ECS, metadati dell’istanza EC2 o IRSA su EKS. In produzione, date al pod del gateway un ruolo IAM invece di incorporare chiavi statiche in un’immagine del contenitore.
Le credenziali esplicite devono essere complete: il gateway non riesce all’avvio quando aws_access_key_id e aws_secret_access_key non sono impostati insieme, o quando aws_session_token è impostato senza di loro. Prima della v2.1.207, un blocco auth: parziale ha superato la convalida.
Claude Platform on AWS
Claude Platform on AWS serve l’API Anthropic di prima parte su infrastruttura AWS suaws-external-anthropic.<region>.api.aws. Utilizza ID modello di prima parte, onora gli header anthropic-beta come inviati e serve count_tokens, quindi nessuna della traduzione specifica di Bedrock si applica. Il provider anthropicAws richiede Claude Code v2.1.198 o successivo; le versioni precedenti del gateway lo rifiutano all’avvio.
Per la distribuzione lato client della stessa piattaforma, vedere Claude Code su Claude Platform on AWS. L’upstream lato gateway:
aws-external-anthropic, quindi un ruolo IAM limitato a Bedrock non lo autorizza. Una chiave API in auth.api_key ha la precedenza quando le credenziali SigV4 sono anche impostate. Un blocco auth vuoto usa la catena di credenziali predefinita dell’AWS SDK, la stessa catena che l’upstream Amazon Bedrock utilizza.
Poiché la piattaforma risolve ID modello di prima parte, il catalogo integrato instrada ad essa senza un blocco
models:. Quando curate un elenco models:, chiave l’entry anthropicAws: con l’ID di prima parte.
Google Cloud Agent Platform
Per la configurazione equivalente lato client, vedere Claude Code su Google Cloud. L’upstream lato gateway:auth vuoto usa Application Default Credentials: GOOGLE_APPLICATION_CREDENTIALS, metadati GCE o GKE Workload Identity. I file di chiave JSON dell’account di servizio sono supportati ma sconsigliati; usate Workload Identity o allegate un account di servizio all’istanza GCE o Cloud Run.
Impostate region: global per usare l’endpoint globale di Agent Platform invece di uno regionale. Google quindi instrada ogni richiesta a una regione disponibile, quindi non tracciate la disponibilità del modello per regione. L’impostazione di una regione specifica fissa ogni richiesta ad essa.
Microsoft Foundry
Per la distribuzione Foundry lato client, vedere Claude Code su Microsoft Foundry. L’upstream lato gateway:use_azure_ad: true si risolve tramite DefaultAzureCredential: Managed Identity su AKS, ACI o App Service; l’Azure CLI o le credenziali di ambiente. Le chiavi API funzionano ma sono a livello di progetto e non ruotano automaticamente. L’endpoint di Foundry è derivato da resource:; impostate l’base_url facoltativo per sovrascriverlo per cloud sovrani come Azure Government.
Più upstream
Lo stesso provider può apparire più di una volta con unname: distinto. Questo copre regioni diverse, account diversi tramite catene di credenziali diverse, throughput provisioned rispetto a on-demand e failover cross-provider.
Il gateway prova gli upstream in ordine. 5xx, 429, 401, 403, 404, timeout e endpoint mancante (501) eseguono il failover; altri 4xx no.
429 è capacità per upstream, quindi l’esaurimento del throughput provisioned (PT) esegue il failover a on-demand. 404 è disponibilità del modello per upstream, quindi un upstream che non ha abilitato un modello non blocca un upstream successivo che lo serve. Un upstream che non può risolvere il modello richiesto viene saltato senza un round-trip di rete.
Questo esempio instrada un’allocazione Bedrock di throughput provisioned per primo, trabocca a on-demand e un secondo account e ricade all’API Anthropic per ultimo:
Il failover tra provider cloud o all’API Anthropic diretto cambia quale accordo, geografia e altri termini governano la richiesta.
La CLI applica lo stesso feature gating ai gateway indipendentemente da quale upstream serve una data richiesta, quindi il failover non invia un campo del corpo che un upstream rifiuterebbe.
Sezioni facoltative
admin
Facoltativo. Abilita /v1/organizations/spend_limits, che rispecchia l’API Admin pubblica di Anthropic, e l’applicazione della spesa per sviluppatore su /v1/messages. Vedere Limiti di spesa per come i cap sono impostati e applicati; questa sezione copre le chiavi gateway.yaml che attivano la funzione e la sintonizzano.
enforcement
Il blocco enforcement controlla come i controlli dei limiti di spesa si comportano quando l’archivio non è disponibile.
models
Il blocco models è un elenco di modelli curato dall’amministratore facoltativo, servito su /v1/models e utilizzato per tradurre gli ID dei modelli per upstream. È obbligatorio per le regioni Bedrock non-US, gli ARN di throughput provisioned di Bedrock e i nomi di distribuzione di Foundry.
managed
Il blocco managed definisce le politiche di accesso basate sui ruoli chiave sui gruppi IdP o sul dominio email. Le politiche vengono valutate in ordine; la prima corrispondenza viene selezionata, quindi unita alla base catch-all match: {} descritta di seguito. Vengono servite per utente su GET /managed/settings con caching ETag/304.
match: {}, convenzionalmente elencato per ultimo, è trattato come uno strato di base. Ogni altra politica eredita qualsiasi chiave che non imposta dal catch-all, quindi le voci per ruolo hanno solo bisogno di elencare ciò che differisce dall’impostazione predefinita dell’organizzazione. Le regole di unione dipendono dal tipo di chiave:
- Allow-list:
availableModelsepermissions.allow. L’elenco di una politica specifica sostituisce completamente quello della base. - Deny-list e array di hook:
permissions.deny,permissions.ask,disabledMcpjsonServers,deniedMcpServers,blockedMarketplacese ogni array di tipo di eventohooks. Questi prendono l’unione di base e politica, quindi un hook di deny o audit a livello di organizzazione non può essere accidentalmente eliminato da un override per ruolo. - Chiavi di tipo record:
env,modelOverrideseskillOverrides. Questi shallow-merge, quindi un bloccoenvper ruolo sovrascrive le chiavi che imposta e eredita il resto dalla base.
availableModels è anche applicato lato server su /v1/messages, quindi un modello negato restituisce 400 indipendentemente da ciò che il client invia.
Un utente autenticato che non corrisponde a nessuna politica ottiene i valori predefiniti del gateway, il che significa ogni modello nel catalogo e nessuna impostazione gestita. Aggiungete un catch-all
match: {} per ultimo se desiderate una politica predefinita garantita.
Il gateway non mantiene alcuna directory utente propria. Autorizza ogni richiesta dal token IdP dell’utente, leggendo l’appartenenza al gruppo dal claim
groups del token e valutando le politiche rispetto ad esso. Non c’è roster da enumerare e nessun account da pre-creare, e quindi nessun endpoint SCIM, perché non c’è nulla per SCIM da sincronizzare.Eseguite la gestione del ciclo di vita dell’utente e del gruppo alla fonte della verità, che è il provisioning SCIM nativo del vostro IdP o una piattaforma di governance dell’identità dedicata. L’appartenenza e il deprovisioning governati lì fluiscono nel gateway automaticamente attraverso il token. Se desiderate il provisioning SCIM degli account Claude stessi, questa è una capacità di Claude for Enterprise.Due orologi di propagazione si applicano:- Contenuti della politica: modificare una politica e ridistribuire raggiunge i client connessi al loro prossimo sondaggio di impostazioni gestite, entro un’ora
- Appartenenza al gruppo: cambiare l’appartenenza al gruppo di un utente cambia quale politica li corrisponde. Questo ha effetto al prossimo re-mint della sessione, il che significa il prossimo aggiornamento silenzioso, limitato da
session.ttl_hours.
Cosa va in cli
Ogni valore cli è un documento managed-settings.json completo di Claude Code, lo stesso schema che distribuireste tramite MDM o /etc/claude-code/managed-settings.json, espresso qui come YAML. La CLI applica il documento consegnato al livello gestito, sopra le impostazioni dell’utente e del progetto.
Il gateway convalida ogni documento rispetto allo schema delle impostazioni della CLI all’avvio, quindi una chiave di primo livello non riconosciuta o una chiave riconosciuta con un valore malformato fallisce l’avvio con un errore che nomina ogni chiave offensiva. Le parti deliberatamente aperte dello schema accettano ancora valori arbitrari, perché i client più recenti possono riconoscere voci che lo schema del gateway non riconosce. Queste chiavi aperte sono env, pluginConfigs e chiavi annidate sotto permissions.
Poiché la convalida utilizza lo schema fornito con la versione installata del gateway, mettere una chiave di impostazioni di primo livello introdotta da una versione più recente di Claude Code nella configurazione gestita richiede l’aggiornamento del gateway per primo. Smoke-test una nuova politica su un client prima di distribuirla.
Il riferimento completo della chiave è in Impostazioni di Claude Code. Le chiavi che gli operatori raggiungono per primi:
Poiché queste impostazioni arrivano sulla rete, la CLI mostra a ogni sviluppatore una finestra di dialogo di approvazione della sicurezza una tantum prima di applicare qualsiasi cosa che possa eseguire un comando shell o alterare dove va il traffico. La finestra di dialogo copre:
hooks- Variabili
envche non sono nell’elenco sicuro integrato della CLI - Impostazioni di esecuzione shell come
apiKeyHelperestatusLine - Contenuto CLAUDE.md gestito
env si applicano senza approvazione:
- Nell’elenco sicuro: variabili di auto-update e nome del modello
- Non nell’elenco sicuro: variabili proxy, variabili base-URL e
OTEL_EXPORTER_OTLP_ENDPOINT
OTEL_EXPORTER_OTLP_ENDPOINT, quindi l’impostazione di telemetry.forward_to attiva la finestra di dialogo su ogni client interattivo. Le esecuzioni non interattive con il flag -p saltano la finestra di dialogo e applicano le impostazioni senza approvazione. La finestra di dialogo protegge la macchina dello sviluppatore da un gateway compromesso o ostile, non l’organizzazione dallo sviluppatore, quindi il salto -p è intenzionale piuttosto che un gap.
Se uno sviluppatore rifiuta, Claude Code esce piuttosto che applicare la politica. Spingere un nuovo hook o una variabile env non sicura a una politica ampia significa quindi un prompt di approvazione all’avvio successivo di ogni sviluppatore corrispondente.
La chiave cli era denominata settings nelle versioni precedenti. Questo spelling è ancora accettato come alias, ma le nuove distribuzioni dovrebbero usare cli.
Precedenza con altre fonti gestite
Se un dispositivo ha anche unmanaged-settings.json locale o una politica consegnata da MDM, le fonti gestite non si uniscono. La fonte con priorità più alta fornisce tutte le impostazioni della politica, classificate in questo ordine con priorità più alta per primo:
- L’helper della politica
- Impostazioni consegnate dal gateway
- MDM, tramite il registro HKLM su Windows o un plist su macOS
- Il file
managed-settings.json - Il registro HKCU, solo su Windows
managedSettings. Viene ignorata per impostazione predefinita e si applica solo quando una fonte gestita acconsente con parentSettingsBehavior: "merge", filtrata in modo che possa stringere la politica ma non allentarla.
L’eccezione è un piccolo insieme di chiavi cross-source, onorate quando qualsiasi fonte admin le imposta; il livello HKCU scrivibile dall’utente è escluso:
sandbox.network.allowManagedDomainsOnlyesandbox.filesystem.allowManagedReadPathsOnly: quando bloccate, gli allowlist corrispondenti vengono uniti tra le fontiallowAllClaudeAiMcps: override di allow-only per l’allowlist del server MCP claude.aisandbox.bwrapPathesandbox.socatPath: percorsi del file system ai binari helper sandboxforceRemoteSettingsRefresh: blocca l’avvio fino a quando le impostazioni gestite remote non vengono recuperate di recente, quindi una politica MDM o file che la imposta è onorata anche quando un payload remoto memorizzato nella cache che manca la chiave è la fonte con priorità più alta
allowManagedPermissionRulesOnly e disableBypassPermissionsMode, proviene solo dalla fonte con priorità più alta. Vedere Precedenza delle impostazioni per la stessa regola nella pagina delle impostazioni.
Le politiche del gateway si applicano a ogni invocazione di Claude Code sulla macchina, incluse le esecuzioni non interattive claude -p e le sessioni generate dall’Agent SDK. Se il gateway non è raggiungibile all’avvio, le sessioni firmate escono con un errore piuttosto che eseguire senza la loro politica.
telemetry
La CLI invia OpenTelemetry Protocol (OTLP) su metriche, log e, quando abilitato, tracce HTTP al gateway, che le inoltra verbatim a ogni destinazione configurata. Vedere Monitoraggio dell’utilizzo per le metriche e gli eventi che la CLI emette.
La CLI timbra ogni esportazione con l’identità dell’utente autenticato, letta dal JWT emesso dal gateway: gli attributi user.id, user.email e user.groups. L’attribuzione del costo e dell’utilizzo per sviluppatore funziona quindi senza alcuna configurazione lato sviluppatore.
telemetry.forward_to insieme a listen.public_url la attiva. Il gateway spinge cinque variabili env a ogni client connesso tramite /managed/settings:
CLAUDE_CODE_ENABLE_TELEMETRY=1OTEL_METRICS_EXPORTER=otlpOTEL_LOGS_EXPORTER=otlpOTEL_TRACES_EXPORTER=otlpOTEL_EXPORTER_OTLP_ENDPOINT=<public_url>
OTEL_* che uno sviluppatore imposta localmente.
Le tracce richiedono inoltre CLAUDE_CODE_ENHANCED_TELEMETRY_BETA=1 su ogni client. Il gateway non spinge quella variabile, quindi impostatela tramite il blocco env di una politica gestita. Non è nell’elenco sicuro della CLI, quindi consegnarla tramite una politica è coperto dalla stessa finestra di dialogo di approvazione della sicurezza che l’endpoint OTLP spinto già attiva.
Sia le codifiche OTLP protobuf che JSON vengono inoltrate e qualsiasi backend compatibile con OpenTelemetry funziona come destinazione.
Sintonizzazione HTTP
Quattro blocchi facoltativi di primo livello,access_control, limits, timeouts e rate_limits, sintonizzano la superficie HTTP. I valori predefiniti si adattano alla maggior parte delle distribuzioni.
Esempio completo
Questo config di riferimento completo esercita ogni sezione principale; i blocchi di sintonizzazione HTTP mantengono i loro valori predefiniti. Copiatelo, eliminate ciò che non vi serve e riempite i vostri valori. La configurazione nella Guida rapida è una versione minima di questa.gateway.yaml
Impostazioni gestite lato client
Tutto quanto sopra configura il server del gateway. Puntare le macchine degli sviluppatori ad esso è configurato separatamente, su ogni dispositivo, tramite le impostazioni gestite di Claude Code. Il gateway non può spingere queste chiavi stesso, perché sono ciò che dice al client dove si trova il gateway. Per la CLI, impostate entrambe le chiavi nelmanaged-settings.json per OS:
forceLoginGatewayUrl e il valore "gateway" di forceLoginMethod sono onorati solo dal livello gestito controllato dall’amministratore. Uno sviluppatore che li imposta nel suo ~/.claude/settings.json non ha effetto.
Correlati
- Panoramica del gateway delle app Claude: guida rapida e connessione dello sviluppatore
- Guida alla distribuzione: configurazione IdP, immagine del contenitore, Kubernetes e Cloud Run e operazioni
- Limiti di spesa: cap per sviluppatore e API Admin