Pular para o conteúdo principal
Uma implantação de gateway de aplicativos Claude é configurada por um arquivo YAML, convencionalmente gateway.yaml. O arquivo define tudo o que o gateway faz: onde ele escuta, como os desenvolvedores fazem login, para onde a inferência vai e quais políticas e telemetria se aplicam. Esta página é a referência para cada opção nesse arquivo. Para escrever o seu primeiro, comece pelo quickstart, que constrói uma configuração mínima funcional e a executa. Uma vez que você tenha uma configuração com a qual esteja satisfeito, o guia de implantação cobre a containerização e hospedagem no Kubernetes, Cloud Run ou sua própria plataforma. O gateway lê o arquivo uma vez, na inicialização, com claude gateway --config /path/to/gateway.yaml. Cada opção é validada contra um esquema na inicialização, portanto uma configuração malformada falha no início com um erro no nível do campo em vez de no primeiro uso. O exemplo completo no final desta página exercita cada seção.

Estrutura do arquivo

Cinco seções são obrigatórias. Todas as outras seções são opcionais, e uma seção omitida assume seus padrões. Chaves desconhecidas falham na inicialização, portanto um erro de digitação aparece como um erro nomeado em vez de uma configuração silenciosamente ignorada. Seções obrigatórias:
  • listen: endereço de vinculação, URL pública, terminação TLS
  • oidc: seu provedor de identidade (IdP), incluindo emissor, cliente, mapeamento de declarações e quem pode fazer login
  • session: os tokens de portador que o gateway emite, com segredo e tempo de vida
  • store: PostgreSQL, para concessões de dispositivo e contadores de limite de taxa
  • upstreams: para onde a inferência vai, seja Anthropic, Amazon Bedrock, Claude Platform na AWS, Agent Platform do Google Cloud ou Microsoft Foundry
Seções opcionais:
  • admin: autenticação da API de administração e retenção para limites de gastos
  • enforcement: comportamento de falha aberta ou fechada do limite de gastos
  • models e auto_include_builtin_models: lista de modelos curada pelo administrador e IDs por upstream
  • managed: políticas de configurações gerenciadas por grupo IdP
  • telemetry: encaminhamento OTLP para sua pilha de observabilidade
  • access_control, limits, timeouts, rate_limits: permitir/negar IP, limites de tamanho de solicitação, tempo até o primeiro byte upstream e limites de login por IP

Expansão de segredos

Não escreva segredos como client_secret, jwt_secret ou postgres_url diretamente em gateway.yaml. Faça referência a eles com um dos formulários abaixo, e o gateway resolve o valor na inicialização a partir de uma variável de ambiente ou um arquivo:

Seções obrigatórias

listen

O bloco listen controla onde o gateway serve: o endereço de vinculação e porta, a origem visível externamente e terminação TLS opcional.

oidc

O bloco oidc conecta o gateway ao seu provedor de identidade e decide quem pode fazer login. Ele nomeia o emissor e cliente OAuth, mapeia as declarações que carregam email e grupos e restringe o login por domínio de email ou grupo. OpenID Connect (OIDC) é o protocolo SSO que o gateway usa com seu provedor de identidade; consulte Configuração do provedor de identidade para saber o que registrar no lado do IdP.

session

O bloco session molda os tokens de portador que o gateway emite após o login: o segredo que os assina e quanto tempo eles vivem.

store

O bloco store aponta o gateway para seu banco de dados PostgreSQL, que contém concessões de dispositivo e contadores de limite de taxa. Para desenvolvimento local, aponte postgres_url para um contêiner Postgres descartável, por exemplo docker run --rm -p 5432:5432 -e POSTGRES_HOST_AUTH_METHOD=trust postgres.

upstreams

upstreams é uma lista ordenada. O gateway encaminha inferência para o primeiro upstream que resolve o modelo solicitado. Em 5xx, 429, 401, 403, 404 ou timeout, ele falha para o próximo; outro 4xx não, porque esses erros são atribuíveis à solicitação em vez do upstream. Um 401 ou 403 significa que a credencial do próprio gateway falhou contra esse upstream, e um 404 significa que esse upstream não serve o modelo solicitado, portanto um upstream posterior na lista ainda pode. Failover em 404 requer gateway v2.1.198 ou posterior. Versões anteriores retornavam o primeiro 404 ao cliente mesmo quando um upstream posterior na lista servia o modelo. Múltiplos upstreams do mesmo provedor devem definir um name: distinto. Clientes Bedrock, Claude Platform on AWS, Agent Platform e Foundry são construídos uma vez na inicialização, e seus SDKs atualizam credenciais internamente, portanto girar credenciais de nuvem não requer reinicialização. Chaves de API Anthropic estáticas e portadores são lidos na inicialização; consulte Anthropic API.

Anthropic API

O upstream Anthropic mínimo é uma chave de API do Claude Console:
As duas formas de credencial diferem no cabeçalho que enviam:
  • api_key: envia x-api-key. Gire-a no Claude Console e atualize a variável env.
  • oauth_token: envia Authorization: Bearer. Use a forma de portador quando sua organização emite tokens de curta duração em vez de chaves de API de longa duração. O portador é lido uma vez na inicialização, portanto atualize remontando o segredo e reiniciando.
Em vez de uma chave estática ou portador, você pode usar Workload Identity Federation. Crie uma regra de federação seguindo o guia de Workload Identity Federation, depois monte o JWT OIDC da sua carga de trabalho como um arquivo, como um token de conta de serviço projetado do Kubernetes ou um id-token de plataforma CI. O gateway troca o JWT por um portador de curta duração e o atualiza automaticamente. O arquivo de token é relido em cada troca, portanto tokens projetados girados são coletados sem reinicialização.

Amazon Bedrock

Para a implantação Bedrock do lado do cliente que o gateway substitui ou está na frente, consulte Claude Code on Amazon Bedrock. O upstream do lado do gateway:
Um bloco auth vazio usa a cadeia de credencial padrão do AWS SDK: variáveis env, ~/.aws/credentials, função de tarefa ECS, metadados de instância EC2 ou IRSA no EKS. Em produção, dê ao pod do gateway uma função IAM em vez de incorporar chaves estáticas em uma imagem de contêiner. Credenciais explícitas devem ser completas: o gateway falha na inicialização quando aws_access_key_id e aws_secret_access_key não estão definidos juntos, ou quando aws_session_token está definido sem eles. Antes da v2.1.207, um bloco auth: parcial passou na validação.

Claude Platform on AWS

Claude Platform on AWS serve a primeira API Anthropic em infraestrutura AWS em aws-external-anthropic.<region>.api.aws. Usa IDs de modelo de primeira parte, honra cabeçalhos anthropic-beta conforme enviados e serve count_tokens, portanto nenhuma tradução específica do Bedrock se aplica. O provedor anthropicAws requer Claude Code v2.1.198 ou posterior; versões anteriores do gateway o rejeitam na inicialização. Para a implantação do lado do cliente da mesma plataforma, consulte Claude Code on Claude Platform on AWS. O upstream do lado do gateway:
A plataforma é executada em uma conta AWS separada do Amazon Bedrock e assina solicitações SigV4 para seu próprio nome de serviço, aws-external-anthropic, portanto uma função IAM com escopo Bedrock não a autoriza. Uma chave de API em auth.api_key tem precedência quando credenciais SigV4 também estão definidas. Um bloco auth vazio usa a cadeia de credencial padrão do AWS SDK, a mesma cadeia que o upstream Amazon Bedrock usa. Como a plataforma resolve IDs de modelo de primeira parte, o catálogo integrado roteia para ela sem um bloco models:. Quando você cura uma lista models:, chave a entrada anthropicAws: com o ID de primeira parte.

Google Cloud Agent Platform

Para a configuração equivalente do lado do cliente, consulte Claude Code on Google Cloud. O upstream do lado do gateway:
Um bloco auth vazio usa Credenciais Padrão de Aplicativo: GOOGLE_APPLICATION_CREDENTIALS, metadados GCE ou Workload Identity do GKE. Arquivos de chave JSON de conta de serviço são suportados mas desencorajados; use Workload Identity ou anexe uma conta de serviço à instância GCE ou Cloud Run. Defina region: global para usar o endpoint global do Agent Platform em vez de um regional. O Google então roteia cada solicitação para uma região disponível, portanto você não rastreia disponibilidade de modelo por região. Definir uma região específica fixa cada solicitação a ela.

Microsoft Foundry

Para a implantação Foundry do lado do cliente, consulte Claude Code on Microsoft Foundry. O upstream do lado do gateway:
use_azure_ad: true resolve através de DefaultAzureCredential: Managed Identity no AKS, ACI ou App Service; a CLI do Azure; ou credenciais de ambiente. Chaves de API funcionam mas são em todo o projeto e não giram automaticamente. O endpoint do Foundry é derivado de resource:; defina o base_url opcional para substituí-lo para nuvens soberanas como Azure Government.

Múltiplos upstreams

O mesmo provedor pode aparecer mais de uma vez com um name: distinto. Isso cobre diferentes regiões, diferentes contas através de diferentes cadeias de credencial, throughput provisionado versus sob demanda e fallback entre provedores. O gateway tenta upstreams em ordem. 5xx, 429, 401, 403, 404, timeouts e endpoint ausente (501) falham; outro 4xx não. 429 é capacidade por upstream, portanto esgotamento de throughput provisionado (PT) falha para sob demanda. 404 é disponibilidade de modelo por upstream, portanto um upstream que não habilitou um modelo não bloqueia um upstream posterior que o serve. Um upstream que não pode resolver o modelo solicitado é pulado sem uma viagem de rede. Este exemplo roteia uma alocação de throughput provisionado Bedrock primeiro, transborda para sob demanda e uma segunda conta, e volta para a API Anthropic por último:
Falhar entre provedores de nuvem ou para a API Anthropic direta muda qual acordo, geografia e outros termos governam a solicitação. O CLI aplica o mesmo feature gating a gateways independentemente de qual upstream serve uma determinada solicitação, portanto o failover não envia um campo de corpo que um upstream rejeitaria.

Seções opcionais

admin

Opcional. Habilita /v1/organizations/spend_limits, que espelha a API de Administração Pública da Anthropic, e aplicação de gastos por desenvolvedor em /v1/messages. Consulte Limites de gastos para saber como os limites são definidos e aplicados; esta seção cobre as chaves gateway.yaml que ativam o recurso e o ajustam.

enforcement

O bloco enforcement controla como as verificações de limite de gastos se comportam quando o armazenamento está indisponível.

models

O bloco models é uma lista de modelos curada pelo administrador opcional, servida em /v1/models e usada para traduzir IDs de modelo por upstream. É obrigatório para regiões Bedrock fora dos EUA, ARNs de throughput provisionado Bedrock e nomes de implantação Foundry.

managed

O bloco managed define políticas de acesso baseadas em função codificadas em grupos IdP ou domínio de email. As políticas são avaliadas em ordem; a primeira correspondência é selecionada, depois mesclada na base match: {} catch-all descrita abaixo. Elas são servidas por usuário em GET /managed/settings com cache ETag/304.
Um catch-all match: {}, convencionalmente listado por último, é tratado como uma camada base. Cada outra política herda qualquer chave que não defina do catch-all, portanto entradas por função apenas precisam listar o que difere do padrão da organização. As regras de mesclagem dependem do tipo de chave:
  • Listas de permissão: availableModels e permissions.allow. A lista de uma política específica substitui completamente a da base.
  • Listas de negação e arrays de hook: permissions.deny, permissions.ask, disabledMcpjsonServers, deniedMcpServers, blockedMarketplaces e cada array de tipo de evento hooks. Estes tomam a união de base e política, portanto uma negação em toda a organização ou hook de auditoria não pode ser acidentalmente descartada por uma substituição por função.
  • Chaves do tipo registro: env, modelOverrides e skillOverrides. Estes mesclam superficialmente, portanto um bloco env por função substitui as chaves que define e herda o resto da base.
availableModels também é aplicado no servidor em /v1/messages, portanto um modelo negado retorna 400 independentemente do que o cliente envia. Um usuário autenticado que não corresponde a nenhuma política obtém os padrões do gateway, o que significa cada modelo no catálogo e nenhuma configuração gerenciada. Adicione um catch-all match: {} por último se quiser uma política padrão garantida.
O gateway não mantém seu próprio diretório de usuários. Ele autoriza cada solicitação do token IdP do usuário, lendo associação de grupo da declaração groups do token e avaliando políticas contra ela. Não há lista para enumerar e nenhuma conta para pré-criar, e portanto nenhum endpoint SCIM, porque não há nada para SCIM sincronizar.Execute gerenciamento de ciclo de vida de usuário e grupo na fonte de verdade, que é o provisionamento SCIM nativo do seu IdP ou uma plataforma dedicada de governança de identidade. Associação e desprovisionamento governados lá fluem para o gateway automaticamente através do token. Se você quiser provisionamento SCIM de contas Claude em si, essa é uma capacidade Claude for Enterprise.Dois relógios de propagação se aplicam:
  • Conteúdo da política: editar uma política e reimplantar alcança clientes conectados em sua próxima sondagem de configurações gerenciadas, dentro de uma hora
  • Associação de grupo: mudar a associação de grupo de um usuário muda qual política os corresponde. Isso entra em vigor na próxima re-cunhagem de sessão, significando a próxima atualização silenciosa, limitada por session.ttl_hours.

O que vai em cli

Cada valor cli é um documento managed-settings.json completo do Claude Code, o mesmo esquema que você implantaria via MDM ou /etc/claude-code/managed-settings.json, expresso aqui como YAML. O CLI aplica o documento entregue na camada gerenciada, acima das configurações de usuário e projeto. O gateway valida cada documento contra o esquema de configurações do CLI na inicialização, portanto uma chave de nível superior não reconhecida ou uma chave reconhecida com um valor malformado falha na inicialização com um erro nomeando cada chave ofensiva. Partes deliberadamente abertas do esquema ainda aceitam valores arbitrários, porque clientes mais novos podem reconhecer entradas que o esquema do gateway não reconhece. Essas chaves abertas são env, pluginConfigs e chaves aninhadas sob permissions. Como a validação usa o esquema agrupado com a versão instalada do gateway, colocar uma chave de configurações de nível superior introduzida por uma versão mais nova do Claude Code na configuração gerenciada requer atualizar o gateway primeiro. Teste uma nova política em um cliente antes de implantá-la. A referência de chave completa está em Configurações do Claude Code. As chaves que os operadores mais procuram primeiro:
Como essas configurações chegam pela rede, o CLI mostra a cada desenvolvedor um diálogo de aprovação de segurança única antes de aplicar qualquer coisa que possa executar um comando shell ou alterar para onde o tráfego vai. O diálogo cobre:
  • hooks
  • Variáveis env que não estão na lista segura integrada do CLI
  • Configurações de execução de shell como apiKeyHelper e statusLine
  • Conteúdo CLAUDE.md gerenciado
A lista segura determina quais variáveis env se aplicam sem aprovação:
  • Na lista segura: variáveis de atualização automática e nome de modelo
  • Não na lista segura: variáveis de proxy, variáveis de URL base e OTEL_EXPORTER_OTLP_ENDPOINT
A configuração de telemetria do gateway empurra OTEL_EXPORTER_OTLP_ENDPOINT, portanto definir telemetry.forward_to dispara o diálogo em cada cliente interativo. Uma execução não interativa com a flag -p não pode mostrar o diálogo. Ela aplica as configurações empurradas apenas para essa execução e não as registra como aprovadas, portanto a próxima sessão interativa do desenvolvedor ainda mostra o diálogo. Antes da v2.1.207, uma execução não interativa salvava as configurações como aprovadas e nenhuma sessão interativa posterior mostrava o diálogo para elas. Se um desenvolvedor recusar, Claude Code sai em vez de aplicar a política. Empurrar um novo hook ou variável env não segura para uma política ampla portanto significa um prompt de aprovação em cada inicialização do desenvolvedor correspondente. A chave cli foi nomeada settings em versões anteriores. Essa ortografia ainda é aceita como um alias, mas novas implantações devem usar cli.

Precedência com outras fontes gerenciadas

Se um dispositivo também tiver um managed-settings.json local ou política entregue por MDM, as fontes gerenciadas não mesclam. A fonte de maior prioridade fornece todas as configurações de política, classificadas nesta ordem com maior prioridade primeiro:
  1. O auxiliar de política
  2. Configurações entregues pelo gateway
  3. MDM, via registro HKLM no Windows ou plist no macOS
  4. O arquivo managed-settings.json
  5. O registro HKCU, apenas no Windows
Hosts de incorporação podem fornecer política através da opção SDK managedSettings. É ignorado por padrão e se aplica apenas quando uma fonte gerenciada opta por parentSettingsBehavior: "merge", filtrado para que possa apertar a política mas não afrouxá-la. A exceção é um pequeno conjunto de chaves entre fontes, honradas quando qualquer fonte de administrador as define; a camada HKCU gravável pelo usuário é excluída:
  • sandbox.network.allowManagedDomainsOnly e sandbox.filesystem.allowManagedReadPathsOnly: quando bloqueadas, as listas de permissão correspondentes são unidas entre fontes
  • allowAllClaudeAiMcps: substituição de permissão apenas para a lista de permissão do servidor MCP claude.ai
  • sandbox.bwrapPath e sandbox.socatPath: caminhos do sistema de arquivos para os binários auxiliares sandbox
  • forceRemoteSettingsRefresh: bloqueia a inicialização até que as configurações gerenciadas remotas sejam buscadas recentemente, portanto uma política MDM ou arquivo que a define é honrada mesmo quando um payload remoto em cache que carece da chave é a fonte de maior prioridade
Cada outra chave, incluindo allowManagedPermissionRulesOnly e disableBypassPermissionsMode, vem apenas da fonte de maior prioridade. Consulte Precedência de configurações para a mesma regra na página de configurações. As políticas do gateway se aplicam a cada invocação do Claude Code na máquina, incluindo execuções não interativas claude -p e sessões geradas pelo Agent SDK. Se o gateway estiver inacessível na inicialização, sessões assinadas saem com um erro em vez de executar sem sua política.
mcpServers dentro de um bloco cli de política é rejeitado na inicialização do gateway. Distribuição de MCP por grupo não está disponível; implante servidores MCP via managed-mcp.json baseado em arquivo em cada dispositivo ou deixe desenvolvedores adicioná-los localmente.

telemetry

O CLI envia métricas, logs e, quando habilitado, rastreamentos do OpenTelemetry Protocol (OTLP) sobre HTTP para o gateway, que os retransmite literalmente para cada destino configurado. Consulte Monitoramento de uso para as métricas e eventos que o CLI emite. O CLI carimba cada exportação com a identidade do usuário autenticado, lida do JWT emitido pelo gateway: os atributos user.id, user.email e user.groups. A atribuição de custo e uso por desenvolvedor portanto funciona sem nenhuma configuração do lado do desenvolvedor.
Cada destino opta por metrics, logs e traces independentemente, e o padrão é apenas métricas. Os sinais diferem em sensibilidade:
  • Métricas: contadores agregados como contagens de token, contagens de solicitação e latência
  • Logs e rastreamentos: podem carregar comandos bash completos, entradas de ferramenta e caminhos de arquivo, cobrindo qualquer coisa que Claude Code faz na máquina de um desenvolvedor
Habilite logs e rastreamentos apenas em destinos com os controles de acesso e política de retenção que os dados justificam.
A telemetria está desativada no CLI por padrão. Configurar telemetry.forward_to junto com listen.public_url a ativa. O gateway empurra cinco variáveis env para cada cliente conectado através de /managed/settings:
  • CLAUDE_CODE_ENABLE_TELEMETRY=1
  • OTEL_METRICS_EXPORTER=otlp
  • OTEL_LOGS_EXPORTER=otlp
  • OTEL_TRACES_EXPORTER=otlp
  • OTEL_EXPORTER_OTLP_ENDPOINT=<public_url>
O endpoint empurrado é construído a partir da URL pública, portanto métricas e logs não precisam de nenhuma configuração OTEL de desenvolvedores ou políticas. A configuração empurrada é aplicada na camada gerenciada, substituindo variáveis OTEL_* que um desenvolvedor define localmente. Rastreamentos adicionalmente requerem CLAUDE_CODE_ENHANCED_TELEMETRY_BETA=1 em cada cliente. O gateway não empurra essa variável, portanto defina-a através do bloco env de uma política gerenciada. Não está na lista segura do CLI, portanto entregá-la através de uma política é coberta pelo mesmo diálogo de aprovação de segurança que o endpoint OTLP empurrado já dispara. Ambas as codificações OTLP protobuf e JSON são retransmitidas, e qualquer backend compatível com OpenTelemetry funciona como destino.

Ajuste HTTP

Quatro blocos opcionais de nível superior, access_control, limits, timeouts e rate_limits, ajustam a superfície HTTP. Os padrões se adequam à maioria das implantações.

Exemplo completo

Esta configuração de referência completa exercita cada seção principal; os blocos ajuste HTTP mantêm seus padrões. Copie-a, delete o que você não precisa e preencha seus valores. A configuração no Quickstart é uma versão mínima disso.
gateway.yaml

Configurações gerenciadas do lado do cliente

Tudo acima configura o servidor gateway. Apontar máquinas de desenvolvedor para ele é configurado separadamente, em cada dispositivo, através das configurações gerenciadas do Claude Code. O gateway não pode empurrar essas chaves em si, porque são o que dizem ao cliente onde o gateway está. Para o CLI, defina ambas as chaves no managed-settings.json por SO:
Implante esse arquivo em cada dispositivo, tipicamente via sua plataforma MDM. O caminho do arquivo difere por plataforma: forceLoginGatewayUrl e o valor "gateway" de forceLoginMethod são honrados apenas da camada gerenciada controlada pelo administrador. Um desenvolvedor definindo-os em seu próprio ~/.claude/settings.json não tem efeito.