SpyBara
Go Premium

claude-apps-gateway-config.md 2026-09-08 20:00 UTC to 2026-09-09 22:58 UTC

This page contains 267 additions and 81 deletions.

2026
Wed 9 22:58 Sat 12 03:02 Fri 18 23:58 Sat 19 23:57 Fri 25 23:58

Configuración de la puerta de enlace de aplicaciones Claude

Referencia para cada opción de gateway.yaml: listener y TLS, OIDC, sesión, almacén Postgres, upstream de Bedrock, Claude Platform en AWS, Agent Platform de Google Cloud y Microsoft Foundry, enrutamiento de modelos, políticas administradas y telemetría.

Una implementación de la puerta de enlace de aplicaciones Claude se configura mediante un archivo YAML, convencionalmente gateway.yaml. El archivo define todo lo que hace la puerta de enlace: dónde escucha, cómo inician sesión los desarrolladores, dónde va la inferencia y qué políticas y telemetría se aplican. Esta página es la referencia para cada opción en ese archivo.

Para escribir el primero, comience desde el inicio rápido, que construye una configuración mínima funcional y la ejecuta. Una vez que tenga una configuración con la que esté satisfecho, la guía de implementación cubre la containerización y el alojamiento en Kubernetes, Cloud Run o su propia plataforma.

La puerta de enlace lee el archivo una vez, al iniciar, con claude gateway --config /path/to/gateway.yaml. Cada opción se valida contra un esquema al arrancar, por lo que una configuración mal formada falla al iniciar con un error a nivel de campo en lugar de en el primer uso.

El ejemplo completo al final de esta página ejercita cada sección.

Estructura del archivo

Cinco secciones son requeridas. Todas las demás secciones son opcionales, y una sección omitida toma sus valores predeterminados. Las claves desconocidas fallan al arrancar, por lo que un error tipográfico aparece como un error nombrado en lugar de una configuración silenciosamente ignorada.

Secciones requeridas:

  • listen: dirección de enlace, URL pública, terminación TLS
  • oidc: su proveedor de identidad (IdP), incluido emisor, cliente, mapeo de reclamaciones y quién puede iniciar sesión
  • session: los tokens portadores que emite la puerta de enlace, con secreto y duración
  • store: PostgreSQL, para concesiones de dispositivos y contadores de límite de velocidad
  • upstreams: dónde va la inferencia, ya sea Anthropic, Amazon Bedrock, Claude Platform en AWS, Agent Platform de Google Cloud o Microsoft Foundry

Secciones opcionales:

  • admin: autenticación de API de administración y retención de límites de gasto
  • enforcement: comportamiento de límite de gasto de fallo abierto o fallo cerrado
  • pricing: tasas contratadas y un multiplicador de descuento para el medidor de gasto
  • models y auto_include_builtin_models: lista de modelos curada por administrador e IDs por upstream
  • managed: políticas de configuración administradas por grupo de IdP
  • telemetry: reenvío OTLP a su pila de observabilidad
  • access_control, limits, timeouts, rate_limits: permitir/denegar IP, límites de tamaño de solicitud, tiempo hasta el primer byte del upstream y límites de inicio de sesión por IP

Expansión de secretos

No escriba secretos como client_secret, jwt_secret o postgres_url directamente en gateway.yaml. Haga referencia a ellos con uno de los formularios a continuación, y la puerta de enlace resuelve el valor al arrancar desde una variable de entorno o un archivo:

Formulario Se resuelve a Usar para
${VAR} La variable de entorno VAR. El arranque falla si no está definida. Variables de entorno de contenedor, AWS Secrets Manager mediante inyección de env
${file:/path} Contenido del archivo en esa ruta absoluta, recortado. La referencia debe ser el valor completo del campo: a diferencia de ${VAR}, no se expande dentro de una cadena más larga, así que para una contraseña de base de datos establezca store.password en lugar de incrustarla en postgres_url. Montajes de volumen de secreto de Kubernetes, Vault Agent, SOPS

Secciones requeridas

`listen`

El bloque listen controla dónde sirve la puerta de enlace: la dirección de enlace y puerto, el origen visible externamente y la terminación TLS opcional.

Campo Requerido Descripción
host No Dirección de enlace. Predeterminado 0.0.0.0.
port No Puerto de enlace. Predeterminado 8080.
public_url A menos que host sea loopback El origen https:// visible externamente, utilizado para construir el redirect_uri de IdP y metadatos de descubrimiento. Requerido siempre que host no sea una dirección loopback, ya sea que TLS termine en un proxy como ALB, Ingress o Cloud Run o en la puerta de enlace misma a través de tls, porque la puerta de enlace nunca deriva su propio origen de encabezados X-Forwarded-*; son suplantables por el cliente. El arranque falla sin él. trusted_proxies a continuación rige solo la resolución de IP del cliente. También es necesario para habilitar telemetría, porque la puerta de enlace construye el punto final OTLP que envía a los clientes desde esta URL.
tls.cert / tls.key No Rutas PEM si la puerta de enlace termina TLS por sí misma
trusted_proxies No CIDR o IPs de equilibradores de carga frente a la puerta de enlace. Cuando se establece, la puerta de enlace confía en X-Forwarded-For solo desde estos pares y registra la IP del cliente real para límites de velocidad por IP y auditoría. Equivalente a nginx set_real_ip_from.

`oidc`

El bloque oidc conecta la puerta de enlace a su proveedor de identidad y decide quién puede iniciar sesión. Nombra el emisor y cliente OAuth, mapea las reclamaciones que llevan correo electrónico y grupos, y restringe el inicio de sesión por dominio de correo electrónico o grupo.

OpenID Connect (OIDC) es el protocolo SSO que la puerta de enlace utiliza con su proveedor de identidad; consulte Configuración del proveedor de identidad para saber qué registrar en el lado de IdP.

Campo Requerido Descripción
issuer Sí Base de descubrimiento OIDC. Debe servir descubrimiento en /.well-known/openid-configuration. Use HTTPS en producción; la puerta de enlace acepta un emisor http://. Un emisor de bucle local como http://localhost:8081 es rechazado por la protección SSRF a menos que CLAUDE_GATEWAY_ALLOW_LOOPBACK=1 esté establecido en el entorno de la puerta de enlace.
client_id / client_secret Sí De su registro de cliente OAuth
allowed_email_domains No Rechace id_tokens cuya reclamación email no esté en uno de estos dominios, sin distinción de mayúsculas y minúsculas. Defensa en profundidad contra configuración errónea de IdP multiinquilino. Independientemente de esta configuración, un id_token cuya reclamación email_verified es explícitamente false siempre se rechaza.
allowed_groups No Restrinja el inicio de sesión a miembros de estos grupos de IdP, comparados contra groups_claim. Un usuario en un dominio de correo electrónico permitido pero en ninguno de estos grupos es rechazado. Requiere que IdP emita la reclamación de grupos. La coincidencia es una comparación de cadena exacta y sensible a mayúsculas y minúsculas contra los valores en esa reclamación, y la puerta de enlace no expande grupos anidados: para admitir miembros de un subgrupo, enumere el subgrupo aquí o configure IdP para emitir membresía aplanada.
groups_claim No Qué reclamación de id_token lleva la membresía del grupo. Predeterminado groups. Microsoft Entra emite roles de aplicación bajo roles. Acepta una clave plana o un puntero JSON RFC 6901 como /resource_access/gateway/roles para reclamaciones anidadas.
google_groups No Busque los grupos del usuario que inició sesión a través de la API del Directorio del SDK de administración de Google Workspace, porque el id_token de Google no lleva reclamación de grupos. Establezca service_account_json_path en un archivo de clave de cuenta de servicio con delegación en todo el dominio en el alcance https://www.googleapis.com/auth/admin.directory.group.readonly, y admin_email en un administrador de Workspace que la cuenta de servicio suplanta; la API del Directorio requiere un asunto administrador real. Las direcciones de correo electrónico del grupo de cada usuario se convierten en su reclamación de grupos, por lo que allowed_groups y managed.policies.match.groups coinciden en correos electrónicos de grupo.
email_claim No Qué reclamación de id_token lleva el correo electrónico del usuario. Predeterminado email. Algunos IdP, como ADFS y Entra B2C, emiten upn o preferred_username en su lugar. Acepta una clave plana, un puntero JSON o una lista de claves de respaldo donde se utiliza la primera clave presente.
scopes No Anulación completa de los alcances OIDC que solicita la puerta de enlace. Predeterminado [openid, profile, email, offline_access]. Establezca cuando su IdP rechace alcances que no reconoce, o requiera un alcance personalizado para emitir grupos o correo electrónico. Debe incluir openid. Soltar offline_access desactiva los tokens de actualización, por lo que los desarrolladores vuelven a ejecutar el inicio de sesión del navegador cada session.ttl_hours. Consulte Configuración del proveedor de identidad para recetas de alcance por IdP como el flujo de token de actualización de Google.
extra_auth_params No Parámetros de consulta adicionales añadidos a la solicitud de autorización de IdP, textualmente. Este es el mecanismo de anulación para comportamiento específico de IdP, como access_type: offline para tokens de actualización de Google, domain_hint para algunos inquilinos de Entra, o acr_values para flujos de escalada. No puede anular los parámetros de protocolo administrados por la puerta de enlace: state, nonce, redirect_uri, PKCE, scope, response_type, response_mode y client_id.
userinfo_fallback No Cuando el id_token omite correo electrónico o grupos, búsquelos en /userinfo. Necesario para tokens de acceso ligeros de Keycloak, el servidor org de Okta y tokens mínimos de ADFS. El id_token sigue siendo autoritario; userinfo solo llena vacíos. Predeterminado false.
use_pkce No Envíe un desafío PKCE (S256) en la solicitud de autorización. Predeterminado true. Establezca false solo si su IdP rechaza PKCE para este cliente confidencial.
clock_skew_seconds No Tolere la desviación del reloj al validar reclamaciones de tiempo de id_token. Predeterminado 0, que es estricto. Aumente si ve errores "token expirado / aún no válido" justo después del inicio de sesión debido a desviación del reloj de host/IdP.
token_endpoint_auth_method No Anule el método de autenticación del punto final del token. Acepta client_secret_basic o client_secret_post. Negociado automáticamente de forma predeterminada.
id_token_signed_response_alg No Algoritmo de firma de id_token esperado. Predeterminado RS256. Establezca para IdP que firman con ES256, PS256 o EdDSA.
additional_authorized_parties No Valores azp adicionales para aceptar más allá de client_id, para flujos de intermediario de Keycloak e intercambio de tokens
discovery_url No Busque el documento de descubrimiento desde esta URL en lugar de derivarlo de issuer, para IdP detrás de un proxy que reescribe el host del emisor. La ruta debe contener /.well-known/.
use_proxy No Envíe las propias solicitudes de IdP de la puerta de enlace a través del proxy directo en HTTPS_PROXY o HTTP_PROXY, honrando NO_PROXY. Sin establecer o false, esas solicitudes van directas. Requiere v2.1.227 o posterior; consulte Solicitudes de IdP a través de un proxy directo a continuación.
form_action_origins No Orígenes adicionales para la directiva Content-Security-Policy: form-action de la página /device. La puerta de enlace ya permite 'self' y el origen authorization_endpoint descubierto, pero Chrome aplica form-action contra toda la cadena de redirección. Si su IdP redirige a través de un segundo host, como Azure AD federado a ADFS, Okta de concentrador y radio, o un interceptor SSO corporativo, enumere cada origen por el que la solicitud de autorización puede redirigir.
ca_cert_pem No El certificado CA codificado en PEM en sí, no una ruta a un archivo. Reemplaza el almacén de confianza del sistema solo para solicitudes de IdP. Para cargar un archivo montado, escriba ${file:/etc/gateway/idp-ca.pem}. Úselo para Keycloak o Dex detrás de PKI corporativa.

Solicitudes de IdP a través de un proxy directo

Los upstreams de inferencia honran HTTPS_PROXY e HTTP_PROXY en cada versión. Las propias solicitudes de la puerta de enlace al IdP, descubrimiento, JWKS, token y userinfo, van directas a menos que establezca oidc.use_proxy: true, que requiere v2.1.227 o posterior. Cuando se establece una variable de proxy, use_proxy no se establece, y el emisor no está cubierto por NO_PROXY, la puerta de enlace mantiene esas solicitudes directas y registra un aviso al arrancar pidiéndole que elija; use_proxy: false las mantiene directas y silencia el aviso.

Con use_proxy: true, la vaina resuelve el nombre de host de cada punto final de IdP por sí misma y pide al proxy que CONNECT a la dirección IP resuelta, por lo que el proxy debe aceptar CONNECT a la dirección IP de cada host que el documento de descubrimiento nombra, no solo el emisor. Use una URL de proxy http://. ca_cert_pem y la protección SSRF se aplican en la ruta proxificada también.

`session`

El bloque session forma los tokens portadores que emite la puerta de enlace después del inicio de sesión: el secreto que los firma y cuánto tiempo viven.

Campo Requerido Descripción
jwt_secret Sí Al menos 32 bytes de entropía, por ejemplo de openssl rand -base64 32. Firma los tokens portadores HS256 de la puerta de enlace. Acepta una cadena única o una matriz para rotación: el índice 0 firma y todas las entradas verifican. Para rotar, anteponga un nuevo secreto, espere ttl_hours, luego suelte el antiguo.
ttl_hours No Duración del token portador de la puerta de enlace. Predeterminado 1. El CLI se actualiza silenciosamente antes de la expiración cuando IdP emite tokens de actualización. Una duración más corta desactiva más rápido; una más larga hace menos viajes de IdP. Si su IdP no puede emitir tokens de actualización porque offline_access no está disponible, no hay actualización silenciosa, así que aumente esto a 8 o 12 para evitar enviar desarrolladores de vuelta al inicio de sesión del navegador cada hora.

`store`

El bloque store apunta la puerta de enlace a su base de datos PostgreSQL, que contiene concesiones de dispositivos y contadores de límite de velocidad.

Campo Requerido Descripción
postgres_url Sí URL postgres:// o postgresql://. Requerido: el encuentro de concesión de dispositivo, donde la devolución del navegador escribe y el CLI de sondeo lee, necesita estado entre réplicas. La puerta de enlace ejecuta sus propias migraciones de esquema al arrancar y al actualizar, por lo que el rol necesita derechos para crear y alterar tablas en el esquema de destino. Consulte Actualizaciones y Postgres.
username No Anula el usuario en postgres_url
password No Credencial de base de datos. Establézcalo aquí en lugar de en postgres_url para que la credencial se mantenga fuera de la URL. Acepta cualquier carácter y tiene prioridad sobre las credenciales de URL.
max_connections No Tamaño del grupo de conexiones de Postgres por réplica. Predeterminado 5, que es conservador y amigable con bases de datos compartidas. Con límites de gasto habilitados, la ruta activa realiza algunas operaciones por solicitud de inferencia, así que aumente para una base de datos dedicada bajo carga, y mantenga réplicas × esto por debajo de max_connections de la base de datos.

Para desarrollo local, apunte postgres_url a un contenedor Postgres desechable, por ejemplo docker run --rm -p 5432:5432 -e POSTGRES_HOST_AUTH_METHOD=trust postgres.

`upstreams`

upstreams es una lista ordenada. La puerta de enlace reenvía la inferencia al primer upstream que resuelve el modelo solicitado. En 5xx, 429, 401, 403, 404, o tiempo de espera, falla al siguiente; otros 4xx no, porque esos errores son atribuibles a la solicitud en lugar del upstream. Un 401 o 403 significa que la credencial propia de la puerta de enlace falló contra ese upstream, y un 404 significa que ese upstream no sirve el modelo solicitado, por lo que un upstream posterior en la lista aún puede.

La conmutación por error en 404 requiere gateway v2.1.198 o posterior. Las versiones anteriores devolvieron el primer 404 al cliente incluso cuando un upstream posterior en la lista sirvió el modelo.

Múltiples upstreams del mismo proveedor deben establecer un name: distinto.

Los clientes de Bedrock, Claude Platform en AWS, Agent Platform y Foundry se construyen una vez al iniciar, y sus SDK actualizan credenciales internamente, por lo que rotar credenciales en la nube no requiere un reinicio. Las claves API estáticas de Anthropic y los portadores se leen al iniciar; consulte API de Anthropic.

Mensajes de error de upstream

La puerta de enlace devuelve la respuesta de error de un upstream, o su propio 502, dependiendo de cómo respondieron los upstreams:

  • Un upstream devolvió un estado en el que la puerta de enlace no conmuta por error: esa respuesta del upstream. La puerta de enlace no intenta más upstreams.
  • Cada upstream que la puerta de enlace intentó falló de una manera en la que conmuta por error: el último 429. Cuando ninguno devolvió un 429, la puerta de enlace prefiere, en orden, el último 401 o 403, el último 404, y el último 501. Cuando ninguno devolvió ninguno de esos, el propio 502 de la puerta de enlace, all upstreams failed (N attempted), donde N cuenta cada entrada en upstreams, incluyendo entradas que la puerta de enlace omitió porque no sirven el modelo solicitado.

Cuando la puerta de enlace devuelve la respuesta de un upstream, mantiene el código de estado del upstream. Si mantiene el mensaje del upstream depende del proveedor. El cuerpo de error de un upstream de API de Anthropic llega al desarrollador sin cambios.

Los upstreams de Amazon Bedrock, Claude Platform en AWS, Agent Platform de Google Cloud y Microsoft Foundry pueden nombrar sus IDs de cuenta, ARN de rol e IDs de proyecto en su texto de error. La puerta de enlace registra ese texto completo en el registro operacional. Lo que el desarrollador ve de esos upstreams depende del rechazo:

  • 400 o 413 en el sobre de error estándar de Anthropic: el mensaje del upstream, como prompt is too long. Claude Platform en AWS, Agent Platform y Microsoft Foundry devuelven este sobre para rechazos de API de modelo.
  • 400 o 413 en la forma propia del proveedor: un token capability_rejected:. Cuando la puerta de enlace no puede clasificar el rechazo, upstream rejected the request en un 400 o request too large for this upstream en un 413.
  • Cualquier otro estado: copia genérica por estado, como upstream rate limit exceeded en un 429.

Por ejemplo, la puerta de enlace reemplaza Input is too long for requested model. de Amazon Bedrock con capability_rejected: prompt_too_long. Claude Code compacta automáticamente en ese token, como lo hace en prompt is too long.

Mantener el mensaje 400 o 413 de un upstream en la nube, o reemplazarlo con un token capability_rejected:, requiere gateway v2.1.233 o posterior.

API de Anthropic

El upstream mínimo de Anthropic es una clave API de la Consola Claude:

upstreams:
  - provider: anthropic
    auth:
      api_key: ${ANTHROPIC_API_KEY}
    # O un portador OAuth (p. ej., un token intercambiado por Workload-Identity-Federation):
    #   oauth_token: ${file:/var/run/secrets/anthropic-oauth-token}
    # base_url: https://api.anthropic.com   # predeterminado; anule para un proxy directo

Las dos formas de credencial difieren en el encabezado que envían:

  • api_key: envía x-api-key. Rótelo en la Consola Claude y actualice la variable env.
  • oauth_token: envía Authorization: Bearer. Use la forma de portador cuando su organización emita tokens de corta duración en lugar de claves API de larga duración. El portador se lee una vez al iniciar, así que actualice remontando el secreto e reiniciando.

En lugar de una clave estática o portador, puede usar Workload Identity Federation. Cree una regla de federación siguiendo la guía de Workload Identity Federation, luego monte el JWT de OIDC de su carga de trabajo como un archivo, como un token de cuenta de servicio proyectado de Kubernetes o un id-token de plataforma de CI. La puerta de enlace intercambia el JWT por un portador de corta duración y lo actualiza automáticamente. El archivo de token se relee en cada intercambio, por lo que los tokens proyectados rotados se recogen sin un reinicio.

upstreams:
  - provider: anthropic
    auth:
      federation_rule_id: ${ANTHROPIC_FEDERATION_RULE_ID}
      organization_id: ${ANTHROPIC_ORGANIZATION_ID}
      identity_token_file: /var/run/secrets/anthropic/id-token
      # workspace_id: wrkspc_...       # requerido si la regla cubre >1 espacio de trabajo
      # service_account_id: svac_...   # verificación de destino esperado opcional
Encabezados de identidad por usuario para un proxy que usted ejecuta

Puede apuntar el base_url de un upstream provider: anthropic a un proxy que usted ejecuta en lugar de a la API de Anthropic. Para decirle a ese proxy qué desarrollador envió cada solicitud, establezca forward_user_identity: true en ese upstream. El proxy puede entonces atribuir gasto por desarrollador. Requiere una puerta de enlace ejecutando Claude Code v2.1.233 o posterior.

Por ejemplo, para un proxy en upstream-gateway.internal.example.com:

upstreams:
  - provider: anthropic
    base_url: https://upstream-gateway.internal.example.com
    auth:
      api_key: ${PROXY_KEY}
    forward_user_identity: true        # predeterminado false

La puerta de enlace añade estos encabezados a cada solicitud que reenvía a ese upstream.

Encabezado Valor
x-litellm-end-user-id El correo electrónico del desarrollador, cuando IdP lo proporcionó.
x-claude-gateway-user-id El asunto de IdP del desarrollador, de la reclamación sub del token.
x-claude-gateway-user-email El correo electrónico del desarrollador, cuando IdP lo proporcionó.

Cuando el token de IdP no lleva correo electrónico, la puerta de enlace envía solo x-claude-gateway-user-id y omite los dos encabezados de correo electrónico. Si su IdP pone el correo electrónico en una reclamación diferente, establezca oidc.email_claim en esa reclamación.

Establezca forward_user_identity solo en un upstream cuyo base_url sea un proxy que usted opera. La puerta de enlace envía correos electrónicos de desarrollador a cualquier servidor que ese base_url nombre. Si el base_url es la API de Anthropic, que es el predeterminado, la puerta de enlace se niega a iniciar.

Amazon Bedrock

Para la implementación de Bedrock del lado del cliente que la puerta de enlace reemplaza o enfrenta, consulte Claude Code en Amazon Bedrock. El upstream del lado de la puerta de enlace:

upstreams:
  - provider: bedrock
    region: us-east-1
    auth: {}                           # preferido: cadena de credenciales predeterminada de AWS
    # O credenciales explícitas:
    # auth:
    #   aws_access_key_id: ${AWS_AKID}
    #   aws_secret_access_key: ${AWS_SK}
    #   aws_session_token: ${AWS_ST}
    # O un token portador de API de Bedrock:
    # auth:
    #   aws_bearer_token: ${AWS_BEARER_TOKEN}
    # Anule el punto final de bedrock-runtime para implementaciones FIPS o de punto final de VPC:
    # base_url: https://bedrock-runtime-fips.us-east-1.amazonaws.com

Un bloque auth vacío utiliza la cadena de credenciales predeterminada del SDK de AWS: variables env, ~/.aws/credentials, rol de tarea de ECS, metadatos de instancia de EC2 o IRSA en EKS. En producción, otorgue a la vaina de la puerta de enlace un rol de IAM en lugar de incrustar claves estáticas en una imagen de contenedor.

Las credenciales explícitas deben ser completas: la puerta de enlace falla al arrancar cuando aws_access_key_id y aws_secret_access_key no se establecen juntos, o cuando aws_session_token se establece sin ellos. Antes de v2.1.207, un bloque auth: parcial pasó la validación.

Configuración Cómo
Permisos de IAM Otorgue al principal de la puerta de enlace bedrock:InvokeModel y bedrock:InvokeModelWithResponseStream tanto en los ARN de perfil de inferencia como en los ARN de modelo de fundación subyacentes. Para el catálogo integrado en regiones de EE.UU.: arn:aws:bedrock:<region>:<account>:inference-profile/us.anthropic.* y arn:aws:bedrock:*::foundation-model/anthropic.*.
Acceso a modelos Amazon Bedrock habilita el acceso a modelos de forma predeterminada en regiones comerciales. La puerta de enlace de nivel de cuenta restante es la de Anthropic: si nadie en su cuenta de AWS la ha enviado, abra la consola de Amazon Bedrock, seleccione un modelo de Anthropic del catálogo de modelos y complete el formulario. Consulte Enviar detalles de caso de uso para el formulario de AWS Organizations y los permisos que el remitente necesita.
EKS (IRSA) Cree un rol de IAM con la política anterior y una política de confianza para el proveedor OIDC de su clúster limitado a la cuenta de servicio de la puerta de enlace. Anote la cuenta de servicio con eks.amazonaws.com/role-arn: arn:aws:iam::<acct>:role/claude-gateway. auth: {} la recoge.
ECS / EC2 Adjunte el rol de IAM a la definición de tarea o perfil de instancia. auth: {} la recoge.
En cualquier otro lugar Pase credenciales a través de las variables env AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY y AWS_SESSION_TOKEN, o establézcalas explícitamente en auth: con expansión ${VAR}
Región region: es la región del punto final de API. Los perfiles de inferencia entre regiones enrutan a través de la geografía (EE.UU., UE, APAC) independientemente de cuál elija. Para regiones no estadounidenses o ARN de rendimiento aprovisionado, agregue un bloque models: con los IDs correctos por upstream.

Claude Platform en AWS

Claude Platform en AWS sirve la API de Anthropic de primera parte en infraestructura de AWS en aws-external-anthropic.<region>.api.aws. Utiliza IDs de modelo de primera parte, honra encabezados anthropic-beta tal como se envían, y sirve count_tokens, por lo que ninguna de la traducción específica de Bedrock se aplica. El proveedor anthropicAws requiere Claude Code v2.1.198 o posterior; las versiones anteriores de gateway lo rechazan al arrancar.

Para la implementación del lado del cliente de la misma plataforma, consulte Claude Code en Claude Platform en AWS. El upstream del lado de la puerta de enlace:

upstreams:
  - provider: anthropicAws
    region: us-east-1
    workspace_id: wrkspc_...
    auth:
      api_key: ${ANTHROPIC_AWS_API_KEY}   # enviado como x-api-key
    # O SigV4 a través de la cadena de credenciales predeterminada de AWS:
    # auth: {}
    # O credenciales SigV4 explícitas:
    # auth:
    #   aws_access_key_id: ${AWS_ACCESS_KEY_ID}
    #   aws_secret_access_key: ${AWS_SECRET_ACCESS_KEY}
    # Anule el punto final derivado:
    # base_url: https://aws-external-anthropic.us-east-1.api.aws

La plataforma se ejecuta en una cuenta de AWS separada de Amazon Bedrock y firma solicitudes SigV4 para su propio nombre de servicio, aws-external-anthropic, por lo que un rol de IAM limitado a Bedrock no lo autoriza. Una clave API en auth.api_key tiene prioridad cuando también se establecen credenciales SigV4. Un bloque auth vacío utiliza la cadena de credenciales predeterminada del SDK de AWS, la misma cadena que usa el upstream Amazon Bedrock.

Campo Requerido Descripción
region Sí Región de AWS, letras minúsculas, dígitos e guiones. La puerta de enlace deriva el punto final de él como https://aws-external-anthropic.<region>.api.aws.
workspace_id Sí Enviado como encabezado en cada solicitud; la plataforma lo requiere
auth.api_key No Clave API para la plataforma, enviada como x-api-key. No es un token portador: los dos modos de autenticación son una clave API o SigV4.
auth.aws_access_key_id / auth.aws_secret_access_key No Credenciales SigV4 explícitas. Establecer uno sin el otro falla al arrancar. auth.aws_session_token se acepta junto a ellos.
base_url No Anule el punto final derivado

Debido a que la plataforma resuelve IDs de modelo de primera parte, el catálogo integrado enruta a ella sin un bloque models:. Cuando cura una lista models:, clave la entrada anthropicAws: con el ID de primera parte.

Plataforma de agentes de Google Cloud

Para la configuración equivalente del lado del cliente, consulte Claude Code en Google Cloud. El upstream del lado de la puerta de enlace:

upstreams:
  - provider: vertex
    region: us-east5
    project_id: example-prod
    auth: {}                           # preferido: Credenciales predeterminadas de aplicación
    # O un archivo de clave de cuenta de servicio:
    # auth: { service_account_json: /secrets/sa.json }
    # Anule el punto final de aiplatform para Private Service Connect:
    # base_url: https://us-east5-aiplatform.p.googleapis.com

Un bloque auth vacío utiliza Credenciales predeterminadas de aplicación: GOOGLE_APPLICATION_CREDENTIALS, metadatos de GCE o Workload Identity de GKE. Los archivos de clave JSON de cuenta de servicio son compatibles pero desaconsejados; use Workload Identity o adjunte una cuenta de servicio a la instancia de GCE o Cloud Run.

Establezca region: global para usar el punto final global de Agent Platform en lugar de uno regional. Google luego enruta cada solicitud a una región disponible, por lo que no rastrea la disponibilidad de modelos por región. Establecer una región específica fija cada solicitud a ella.

Configuración Cómo
Permisos de IAM Otorgue a la cuenta de servicio de la puerta de enlace roles/aiplatform.user en el proyecto, o un rol personalizado con aiplatform.endpoints.predict. Habilite la API de Agent Platform (aiplatform.googleapis.com).
Acceso a modelos En Model Garden, habilite los modelos Claude para su proyecto. Se publican en regiones específicas; consulte la tarjeta del modelo para regiones compatibles.
GKE (Workload Identity) Vincule una cuenta de servicio de GCP a la cuenta de servicio de Kubernetes de la puerta de enlace y anote la KSA con iam.gke.io/gcp-service-account: claude-gateway@<proj>.iam.gserviceaccount.com. auth: {} la recoge.
Cloud Run / GCE Establezca la cuenta de servicio del servicio en una con roles/aiplatform.user. auth: {} la recoge.
En cualquier otro lugar auth: { service_account_json: /secrets/sa.json }, la ruta a un archivo de clave JSON montado como secreto. El campo toma una ruta de archivo, no el contenido de la clave, por lo que no hay expansión ${file:…} involucrada.

Microsoft Foundry

Para la implementación de Foundry del lado del cliente, consulte Claude Code en Microsoft Foundry. El upstream del lado de la puerta de enlace:

upstreams:
  - provider: foundry
    resource: example-foundry              # https://example-foundry.services.ai.azure.com
    auth: { use_azure_ad: true }        # preferido: DefaultAzureCredential / Managed Identity
    # O una clave API:
    # auth:
    #   api_key: ${FOUNDRY_API_KEY}

use_azure_ad: true se resuelve a través de DefaultAzureCredential: Managed Identity en AKS, ACI o App Service; la CLI de Azure; o credenciales de entorno. Las claves API funcionan pero son amplias del proyecto y no se rotan automáticamente. El punto final de Foundry se deriva de resource:; establezca el base_url opcional para anularlo para nubes soberanas como Azure Government.

Configuración Cómo
RBAC Otorgue a la identidad de la puerta de enlace Azure AI User o Cognitive Services User en el recurso de Foundry
Implementaciones Foundry utiliza nombres de implementación elegidos por administrador, no IDs de modelo canónicos. Agregue un bloque models: que asigne cada ID canónico a su nombre de implementación.
AKS (workload identity) Federe una Managed Identity asignada por el usuario con el emisor OIDC del clúster y vincúlela a la cuenta de servicio de la puerta de enlace. use_azure_ad: true la recoge a través de WorkloadIdentityCredential.
ACI / App Service Habilite la identidad administrada asignada por el sistema o por el usuario en el recurso. use_azure_ad: true la recoge.
En cualquier otro lugar auth: { api_key: "${FOUNDRY_API_KEY}" }. Entrecomille ${…} dentro de { }.

Múltiples upstreams

El mismo proveedor puede aparecer más de una vez con un name: distinto. Esto cubre diferentes regiones, diferentes cuentas a través de diferentes cadenas de credenciales, rendimiento aprovisionado versus bajo demanda, y conmutación por error entre proveedores.

La puerta de enlace intenta upstreams en orden. 5xx, 429, 401, 403, 404, tiempos de espera y punto final faltante (501) conmutan por error; otros 4xx no.

429 es capacidad por upstream, por lo que el agotamiento de rendimiento aprovisionado (PT) conmuta por error a bajo demanda. 404 es disponibilidad de modelo por upstream, por lo que un upstream que no ha habilitado un modelo no bloquea un upstream posterior que lo sirve. Un upstream que no puede resolver el modelo solicitado se omite sin un viaje de red.

Este ejemplo enruta una asignación de rendimiento aprovisionado de Bedrock primero, desborda a bajo demanda y una segunda cuenta, y vuelve a la API de Anthropic al final:

upstreams:
  # Primario: rendimiento aprovisionado en su región de inicio.
  - name: bedrock-pt
    provider: bedrock
    region: us-east-1
    auth: {}
  # Desbordamiento: bajo demanda entre regiones.
  - name: bedrock-od
    provider: bedrock
    region: us-west-2
    auth: {}
  # Cuenta diferente: una asignación de Bedrock separada a través de credenciales de rol asumido.
  - name: bedrock-acct2
    provider: bedrock
    region: us-east-1
    auth:
      aws_access_key_id: ${ACCT2_AKID}
      aws_secret_access_key: ${ACCT2_SK}
  # Último recurso: API de Anthropic directo.
  - name: anthropic-fallback
    provider: anthropic
    auth:
      api_key: ${ANTHROPIC_API_KEY}

# Los IDs de modelo por upstream se clave en el `name:` del upstream.
models:
  - id: claude-opus-4-8
    label: Claude Opus 4.8
    upstream_model:
      bedrock-pt: arn:aws:bedrock:us-east-1:111111111111:provisioned-model/abcdef
      bedrock-od: us.anthropic.claude-opus-4-8
      bedrock-acct2: us.anthropic.claude-opus-4-8
      anthropic-fallback: claude-opus-4-8
Palanca Cómo
Diferentes regiones Un upstream de Bedrock por región, cada uno con su propio region:. Con auto_include_builtin_models: true los perfiles de inferencia entre regiones enrutan automáticamente; para implementaciones fijas de región use un bloque models:.
Diferentes cuentas Un upstream de Bedrock por cuenta, cada uno con sus propias credenciales en auth:. La cadena predeterminada (auth: {}) utiliza la identidad de la vaina; para una segunda cuenta, establezca credenciales explícitas o un token portador.
Rendimiento aprovisionado Asigne el modelo al ARN de rendimiento aprovisionado en models: para el nombre de ese upstream. Otros upstreams mantienen el ID bajo demanda, por lo que la capacidad de PT se agota antes de conmutar por error.
Puntos finales de VPC / FIPS Establezca base_url: en el upstream a su URL de punto final de VPC o FIPS
Enrutamiento limitado a modelo Solo un modelo id personalizado, uno que no sea un modelo Claude integrado, omite los upstreams ausentes de su mapa upstream_model:. La puerta de enlace intenta modelos integrados en cada upstream en orden y utiliza el ID predeterminado del proveedor donde el mapa no tiene entrada, por lo que para modelos integrados el mapa cambia qué ID recibe un upstream en lugar de si se intenta; un upstream que rechaza el ID sigue las mismas reglas de conmutación por error que cualquier otro error de upstream.

La conmutación por error entre proveedores en la nube, o a la API de Anthropic directo, cambia qué acuerdo, geografía y otros términos rigen la solicitud.

El CLI aplica el mismo control de características a puertas de enlace independientemente de cuál upstream sirva una solicitud dada, por lo que la conmutación por error no envía un campo de cuerpo que un upstream rechazaría.

Secciones opcionales

`admin`

Opcional. Habilita /v1/organizations/spend_limits, que refleja la API de administración pública de Anthropic, y cumplimiento de gasto por desarrollador en /v1/messages. Consulte Límites de gasto para saber cómo se establecen y aplican los límites; esta sección cubre las claves gateway.yaml que activan la función y la ajustan.

admin:
  # Claves API estáticas nombradas para los puntos finales de administración, enviadas como x-api-key.
  # El id aparece en el registro de auditoría como admin-key:<id> para que cada clave sea
  # atribuible. Matriz para rotación: agregue la nueva clave, despliegue clientes,
  # elimine la antigua.
  write_keys:
    - { id: terraform, key: "${GATEWAY_ADMIN_WRITE_KEY_TF}" }
    - { id: ci,        key: "${GATEWAY_ADMIN_WRITE_KEY_CI}" }
  read_keys:
    - { id: reporting, key: "${GATEWAY_ADMIN_READ_KEY}" }
  # Grupos de IdP otorgados acceso de administrador completo a través del JWT de puerta de enlace normal (sin clave API).
  admin_groups: [platform-finops]
  blocked_message: request an increase at https://go.example.com/claude-limits
Campo Requerido Descripción
write_keys No Matriz de {id, key}. Un x-api-key que coincida con uno de estos puede listar, establecer y eliminar límites de gasto. Los valores de clave deben tener al menos 32 caracteres; los ids deben ser únicos en read_keys y write_keys.
read_keys No Matriz de {id, key}. Solo lectura: cada punto final GET, incluida la enumeración de límites, la obtención de uno por ID y la lectura de /effective y /audit.
admin_groups No Nombres de grupos de IdP. Un JWT de puerta de enlace cuya reclamación groups incluye uno de estos tiene acceso de administrador completo, lectura y escritura, y audita como oidc:<sub>. Úselo para administradores humanos; use claves API para máquinas. Una entrada vacía en esta lista detiene la puerta de enlace al arrancar. Consulte Valores de coincidencia que detienen la puerta de enlace al arrancar.
blocked_message No Añadido textualmente al 429 billing_error que ve un desarrollador bloqueado. Escriba la instrucción completa, como una URL o un canal de Slack. Sin establecer, la puerta de enlace envía solo el mensaje predeterminado. Consulte Cómo funciona el cumplimiento.
audit_retention_days No Predeterminado 365. Las filas admin_audit más antiguas se barren.
spend_retention_months No Predeterminado 13. Las filas del contador spend más antiguas que esto se barren. El predeterminado mantiene un año completo más el mes parcial actual para informes año a año.
identity_retention_days No Predeterminado 90. TTL de última visualización para filas principal_emails, que contienen el correo electrónico, nombre para mostrar y grupos de cada desarrollador (PII). Deliberadamente más corto que la retención de gasto para que una identidad desaprovisionada envejezca mientras sus contadores de gasto anónimos permanecen.
group_limit_mode No min (predeterminado) o max. Cuando un desarrollador está en varios grupos con límites, min aplica el más restrictivo y max el menos. Utilizado tanto por cumplimiento como por /effective.

`enforcement`

El bloque enforcement controla cómo se comportan las verificaciones de límite de gasto cuando el almacén no está disponible.

Campo Requerido Descripción
fail_closed_on_error No Predeterminado false. El cumplimiento de gasto falla abierto en una interrupción de Postgres, por lo que la inferencia permanece activa. Establezca true para fallar cerrado: los desarrolladores sobre el límite se bloquean, pero también todos si el almacén es inaccesible. Requiere un bloque admin:: el cumplimiento de gasto solo se ejecuta cuando admin está configurado, y la puerta de enlace se niega a iniciar si establece esto en true sin uno.

`pricing`

El bloque pricing le dice al medidor de gasto qué cobrar en lugar del precio de lista en USD, por lo que los límites y /effective reflejan sus tasas contratadas. Los montos permanecen en USD y siguen siendo una estimación, no una factura. Dos requisitos previos:

  • Claude Code v2.1.227 o posterior en el servidor de puerta de enlace. Las versiones anteriores rechazan la clave desconocida al arrancar.
  • Un bloque admin:, porque solo el medidor de gasto lee pricing. La puerta de enlace se niega a iniciar con pricing establecido y sin admin.
pricing:
  multiplier: 0.85
  overrides:
    - upstream: bedrock-eu
      model: claude-sonnet-4-6
      input: 3.30
      output: 16.50
      cache_read: 0.33
      cache_write: 4.125
Campo Requerido Descripción
multiplier No Predeterminado 1. El medidor multiplica cada cantidad medida por esto, ya sea con precio de lista o anulada, por lo que 0.85 factura el 85% del precio. Debe ser mayor que 0 y como máximo 1.
overrides No Filas de {upstream, model, input, output, cache_read, cache_write} en USD por millón de tokens. Las cuatro tasas son obligatorias y deben ser positivas.

Cómo el medidor coincide con una fila de anulación:

  • Una fila reemplaza el precio de lista para solicitudes que upstream, un upstreams[].name, sirve para model. Eso incluye la tasa de modo rápido más alta, por lo que las solicitudes de modo rápido y estándar se miden con las mismas cuatro tasas.
  • Un ID integrado como claude-sonnet-4-6, coincidido como models[].id, cubre cada forma fechada, forma regional de Amazon Bedrock, o forma de Plataforma de Agentes de Google Cloud que el medidor precifica como ese modelo. Cualquier otra cadena, como un alias o un ARN de perfil de inferencia, coincide con el ID que envió el cliente o la cadena enviada upstream, sin distinción de mayúsculas y minúsculas.
  • Donde las filas se superponen, el medidor elige la fila más específica en lugar de la primera fila: una fila cuyo model es la cadena de modelo exacta enviada upstream, luego una fila que coincide con el ID exacto que envió el cliente, luego una fila que nombra el modelo integrado.
  • Un nombre de upstream desconocido falla al arrancar, al igual que dos filas para un upstream que nombran el mismo modelo, incluidas dos ortografías de un modelo integrado. La puerta de enlace advierte al arrancar sobre una fila que ningún modelo solicitable puede usar.
  • Las solicitudes de búsqueda web permanecen en el precio de lista de $0.01; el multiplicador aún se aplica a ellas.

Para tasas por región, proporcione a cada región su propio upstream nombrado y una fila por upstream.

`models`

El bloque models es una lista de modelos curada por administrador opcional, servida en /v1/models y utilizada para traducir IDs de modelo por upstream. Es necesario para regiones de Bedrock no estadounidenses, ARN de rendimiento aprovisionado de Bedrock y nombres de implementación de Foundry.

auto_include_builtin_models: true   # false: exponga solo la lista a continuación
models:
  - id: claude-opus-4-8
    label: Claude Opus 4.8
    # description: texto opcional mostrado en clientes que lo muestren
    upstream_model:
      anthropic: claude-opus-4-8
      bedrock: us.anthropic.claude-opus-4-8   # o un ARN de perfil de inferencia
      foundry: your-opus-deployment-name

Cada clave bajo upstream_model debe coincidir con el name de un upstream configurado, que por defecto es el nombre del proveedor. Una clave que no coincida con ningún upstream falla al arrancar, así que omita las líneas para proveedores que no usa.

`managed`

El bloque managed define políticas de acceso basadas en roles clave en grupos de IdP o dominio de correo electrónico. Las políticas se evalúan en orden; se selecciona la primera coincidencia, luego se fusiona en la base de captura match: {} descrita a continuación. Se sirven por usuario en GET /managed/settings con almacenamiento en caché de ETag/304.

managed:
  policies:
    # Grupos específicos primero.
    - match: { groups: [eng-contractors] }
      cli:
        availableModels: [claude-sonnet-4-6]
        permissions: { deny: ["WebFetch", "WebSearch"] }
    # Captura predeterminada al final: coincide con todos los que se autenticaron.
    - match: {}
      cli:
        availableModels: [claude-opus-4-8, claude-sonnet-4-6, claude-haiku-4-5]

Una captura match: {}, convencionalmente listada al final, se trata como una capa base. Cada otra política hereda cualquier clave que no establezca de la captura, por lo que las entradas por rol solo necesitan listar lo que difiere del predeterminado de la organización. Las reglas de fusión dependen del tipo de clave:

  • Listas de permitidos: availableModels y permissions.allow. La lista de una política específica reemplaza completamente la de la base.
  • Listas de denegación y matrices de hooks: permissions.deny, permissions.ask, disabledMcpjsonServers, deniedMcpServers, blockedMarketplaces y cada matriz de tipo de evento hooks. Estos toman la unión de base y política, por lo que un gancho de denegación o auditoría en toda la organización no puede ser accidentalmente eliminado por una anulación por rol.
  • Claves de tipo registro: env, modelOverrides y skillOverrides. Estos se fusionan superficialmente, por lo que un bloque env por rol anula las claves que establece y hereda el resto de la base.

availableModels también se aplica del lado del servidor en /v1/messages, por lo que un modelo denegado devuelve 400 independientemente de lo que envíe el cliente.

La puerta de enlace valida el valor model en sí antes de retransmitir una solicitud, por lo que un valor mal formado nunca llega a un upstream. Rechaza la solicitud con un 400 en dos casos:

  • Cuando el valor falta o está vacío, la puerta de enlace rechaza la solicitud con el mensaje model is required. Esa verificación requiere una puerta de enlace que ejecute Claude Code v2.1.228 o posterior.
  • Cuando el valor está presente pero no es una cadena, la puerta de enlace rechaza la solicitud con el mensaje model must be a string. Requiere una puerta de enlace que ejecute Claude Code v2.1.221 o posterior.
Coincidencia Comportamiento
match: {} Coincide con cada usuario autenticado. Comience con uno de estos y agregue políticas limitadas a grupo más tarde.
match: { groups: [a, b] } Coincide si la reclamación groups del JWT contiene cualquiera de los grupos listados. Sensible a mayúsculas y minúsculas: los grupos deben coincidir con el uso exacto de mayúsculas y minúsculas de IdP.
match: { email_domain: example.com } Coincide con la parte después de la última @ en la reclamación email del JWT, sin distinción de mayúsculas y minúsculas. Acepta un dominio por política.
match: { groups: [a], email_domain: example.com } Ambas condiciones deben coincidir

Un usuario autenticado que no coincida con ninguna política obtiene los valores predeterminados de la puerta de enlace, lo que significa cada modelo en el catálogo y sin configuración administrada. Agregue una captura match: {} al final si desea una política predeterminada garantizada.

Valores de coincidencia que detienen la puerta de enlace al arrancar

Al arrancar, la puerta de enlace verifica el bloque match de cada política y la lista admin_groups. Cualquiera de estos valores detiene la puerta de enlace con un error que nombra el campo:

  • Una lista groups vacía
  • Una entrada vacía en groups o en admin_groups
  • Un email_domain vacío
  • Un email_domain que contiene @, espacios en blanco o una coma. La puerta de enlace recorta el valor y elimina un @ inicial antes de esta verificación. Escriba un dominio desnudo, como example.com.

Antes de v2.1.232, la puerta de enlace se iniciaba con estos valores. Cada valor tenía este efecto:

  • Un email_domain vacío: la puerta de enlace omitía la verificación de dominio, por lo que una política con un email_domain vacío y sin lista groups coincidía con cada usuario autenticado
  • Una lista groups vacía: la política no coincidía con nadie
  • Un email_domain que contiene @, espacios en blanco o una coma: la política no coincidía con nadie
  • Una entrada vacía en groups o en admin_groups: la entrada coincidía con un usuario solo cuando la reclamación groups de IdP de ese usuario también contenía una entrada vacía. En admin_groups, esa coincidencia otorgaba acceso de administrador. Si su lista admin_groups nunca contenía una entrada vacía, nadie obtenía acceso de administrador de esta manera.

Qué va en `cli`

Cada valor cli es un documento completo de managed-settings.json de Claude Code, el mismo esquema que implementaría a través de MDM o /etc/claude-code/managed-settings.json, expresado aquí como YAML. El CLI aplica el documento entregado en el nivel administrado, por encima de la configuración de usuario y proyecto, en lugar de la configuración administrada por servidor. Por lo tanto, ignora la configuración restringida a fuentes de política a nivel de SO, como policyHelper y wslInheritsWindowsSettings.

La puerta de enlace valida cada documento contra el esquema de configuración del CLI al arrancar, por lo que una clave de nivel superior no reconocida falla al arrancar con un error que nombra cada clave ofensiva. Las partes deliberadamente abiertas del esquema aún aceptan valores arbitrarios, porque clientes más nuevos pueden reconocer entradas que el esquema de la puerta de enlace no. Estas claves abiertas son env, pluginConfigs y claves anidadas bajo permissions.

Debido a que la validación utiliza el esquema incluido con la versión instalada de la puerta de enlace, poner una clave de configuración de nivel superior introducida por una versión más nueva de Claude Code en la configuración administrada requiere actualizar primero la puerta de enlace. Pruebe una nueva política en un cliente antes de implementarla ampliamente.

La referencia de clave completa está en Configuración de Claude Code. Las claves que los operadores alcanzan primero:

managed:
  policies:
    - match: {}
      cli:
        # Acceso a modelos (también aplicado del lado del servidor en /v1/messages)
        availableModels: [claude-opus-4-8, claude-sonnet-4-6, claude-haiku-4-5]

        # Política de permisos
        permissions:
          deny:
            - "WebFetch"
            - "Read(./.env)"
            - "Read(./secrets/**)"
          disableBypassPermissionsMode: disable   # bloquea --dangerously-skip-permissions
        allowManagedPermissionRulesOnly: true     # ignora reglas de permisos de usuario/proyecto

        # Entorno empujado al proceso CLI. DISABLE_UPDATES bloquea
        # actualizaciones de fondo y manuales; DISABLE_AUTOUPDATER detiene solo
        # actualizaciones de fondo.
        env:
          DISABLE_UPDATES: "1"                    # versiones de pin a través de su propia distribución

        # Hooks en toda la organización. Los comandos de gancho se ejecutan en máquinas de desarrollador, no en la
        # puerta de enlace, por lo que la ruta debe existir en cada SO de cliente en la política.
        hooks:
          PostToolUse:
            - matcher: "Edit|Write"
              hooks:
                - { type: command, command: /usr/local/bin/audit-edit.sh }
Clave Aplicada por Efecto
availableModels Puerta de enlace + CLI Lista de permitidos de modelos. También se verifica en /v1/messages, por lo que un cliente parcheado no puede omitirlo.
permissions.allow / .deny CLI Reglas de herramientas y comandos. Consulte Permisos.
permissions.disableBypassPermissionsMode CLI Establezca en disable para bloquear bypassPermissions, el modo que aprueba automáticamente cada llamada de herramienta, y la bandera --dangerously-skip-permissions
allowManagedPermissionRulesOnly CLI Cuando es true, las reglas de permisos de usuario y proyecto se ignoran; solo se aplican las reglas de este documento. La entrada allowManagedPermissionRulesOnly enumera cada fuente que Claude Code luego ignora.
env CLI Variables de entorno fusionadas en el proceso CLI. Úselo para telemetría, actualización automática y anulaciones de nombres de modelos.
hooks CLI Hooks en toda la organización

Debido a que estas configuraciones llegan a través de la red, el CLI muestra a cada desarrollador un diálogo de aprobación de seguridad antes de aplicar la configuración listada a continuación:

  • hooks
  • Variables env que requieren la aprobación del desarrollador, como variables de proxy y URL base
  • configuración de ejecución de shell como apiKeyHelper y statusLine
  • la configuración de binarios de sandbox sandbox.bwrapPath, sandbox.socatPath y sandbox.ripgrep
  • Configuración de Sandbox que intercepta tráfico, inyecta credenciales o debilita el aislamiento, como sandbox.network.tlsTerminate y la configuración del puerto proxy. Diálogos de aprobación de seguridad los enumera todos.

Memoria de aprobación cubre cuánto tiempo dura una aprobación y cuándo aparece el diálogo nuevamente.

Claude Code aplica algunas variables env entregadas sin mostrar al desarrollador el diálogo de aprobación de seguridad, como configuración de selección de modelos y límites numéricos. Otras variables entregadas pueden requerir la aprobación del desarrollador antes de que surtan efecto; un valor de proxy, URL base u OTEL_EXPORTER_OTLP_ENDPOINT no vacío siempre lo hace. Cuando una variable entregada necesita aprobación, el diálogo la nombra.

Variables de entorno y el diálogo de aprobación tiene los detalles, incluidos cuatro alteradores de privacidad cuyo valor entregado decide si necesitan aprobación. Antes de v2.1.218, Claude Code aplicaba menos variables sin preguntar al desarrollador, por lo que más variables entregadas desencadenaban el diálogo.

La configuración de telemetría de la puerta de enlace empuja OTEL_EXPORTER_OTLP_ENDPOINT, por lo que establecer telemetry.forward_to desencadena el diálogo en cada cliente interactivo. El diálogo protege la máquina del desarrollador de una puerta de enlace comprometida u hostil, no la organización del desarrollador.

Una ejecución no interactiva con la bandera -p no puede mostrar el diálogo. Aplica la configuración empujada solo para esa ejecución y no la registra como aprobada, por lo que la siguiente sesión interactiva del desarrollador aún muestra el diálogo. Antes de v2.1.207, una ejecución no interactiva guardaba la configuración como aprobada y ninguna sesión interactiva posterior mostraba el diálogo para ellas.

Si un desarrollador rechaza, Claude Code sale de esa sesión en lugar de aplicar la política. Cuando empuja un nuevo gancho, o cualquier variable env que desencadene el diálogo, a una política amplia, Claude Code por lo tanto muestra el diálogo a cada desarrollador coincidente. Muestra el diálogo en una sesión en ejecución en la próxima encuesta por hora, y de lo contrario en el próximo inicio del desarrollador.

La clave cli se nombró settings en versiones anteriores. Ese deletreo aún se acepta como alias, pero las nuevas implementaciones deben usar cli.

Superposición de Claude Desktop

Si su organización también implementa Claude Desktop, la misma puerta de enlace sirve a ambos clientes. Apunte bootstrapUrl, en la configuración administrada de Claude Desktop, a <listen.public_url>/user/bootstrap. Claude Desktop deriva el emisor de OAuth de esa URL, ejecuta el mismo inicio de sesión de código de dispositivo contra esta puerta de enlace, y obtiene su configuración de la respuesta.

La puerta de enlace deriva gran parte de la respuesta del bloque cli de la política coincidente y de la configuración de puerta de enlace de nivel superior:

  • La lista de modelos, de availableModels
  • Herramientas deshabilitadas, de entradas permissions.deny de nombre de herramienta desnudo. Si establece disabledBuiltinTools en el bloque desktop de la política, la puerta de enlace sirve la unión de su valor y la lista derivada, por lo que puede deshabilitar más herramientas de esta manera pero no puede volver a habilitar una que deshabilitó a través de permissions.deny
  • La lista de permitidos de salida, de sandbox.network.allowedDomains. Si establece coworkEgressAllowedHosts en el bloque desktop de la política, la puerta de enlace usa ese valor en lugar de la lista derivada
  • Un punto final OTLP que apunta a la puerta de enlace en sí, que se distribuye a sus destinos, incluido cuando se configura el reenvío de telemetry

Para establecer disabledBuiltinTools o coworkEgressAllowedHosts en el bloque desktop de una política, necesita Claude Code v2.1.232 o posterior en el servidor de puerta de enlace.

La puerta de enlace omite claves sin equivalente de Claude Desktop, como hooks y reglas de permisos limitadas como Bash(npm *), de la respuesta de bootstrap.

Agregue el bloque desktop opcional junto a cli para establecer la configuración de Claude Desktop directamente. Escriba la configuración de la referencia de configuración administrada de Claude Desktop como nombres de clave planos. Deje fuera las claves que Claude Desktop lee solo de MDM o archivos locales, como bootstrapUrl; la puerta de enlace las rechaza al arrancar. Antes de v2.1.232, la puerta de enlace aceptaba una lista fija de 11 claves de puerta de características, como chatTabEnabled y disableAutoUpdates, y rechazaba todas las demás claves al arrancar. Antes de v2.1.227, la puerta de enlace también rechazaba chatTabEnabled y chatAdvancedFileAnalysisEnabled al arrancar.

managed:
  policies:
    - match: { groups: [eng-contractors] }
      cli:
        availableModels: [claude-sonnet-4-6]
      desktop:
        isLocalDevMcpEnabled: false
        disableAutoUpdates: true
        banner: { text: "Contractor build: internal use only" }

Cada clave es opcional; Claude Desktop aplica su propio predeterminado para cualquier clave que omita. La puerta de enlace valida cada bloque desktop al arrancar contra el esquema de configuración que Claude Desktop en sí usa, por lo que un error aparece al inicio de la puerta de enlace como un error que nombra la clave en lugar de llegar a cada escritorio conectado. La puerta de enlace falla al arrancar cuando un bloque contiene:

  • Una clave desconocida
  • Una clave reconocida cuyo valor Claude Desktop rechazaría o silenciosamente descartaría, como un valor vacío o una subclave mal escrita dentro de una entrada anidada
  • Una clave que la puerta de enlace calcula en sí: la conexión de inferencia, la lista de modelos y el relé OTLP. Configure esos a través de upstreams, models y la sección telemetry de forward_to.
  • Un alias heredado de una clave actual. En el error de arranque, la puerta de enlace nombra la clave canónica a escribir.

Como con el bloque cli, la puerta de enlace valida contra el esquema incluido con su versión instalada. Para entregar una configuración introducida por una versión más nueva de Claude Desktop, actualice primero la puerta de enlace.

La puerta de enlace rellena las claves que el bloque desktop de una política no establece desde el bloque desktop de la captura match: {}, de la misma manera que rellena el bloque cli de una política desde la base. Si establece disabledBuiltinTools o builtinToolPolicy en la base y una política de rol, la puerta de enlace mantiene la restricción de la base:

  • disabledBuiltinTools: la puerta de enlace usa la unión de la lista de la base y la lista de la política
  • builtinToolPolicy: si establece una herramienta en un valor distinto de allow en la base, la puerta de enlace mantiene ese valor incluso si establece allow para la misma herramienta en una política de rol

Para todas las demás claves, si la establece en la política de rol, la puerta de enlace usa el valor de la política de rol. La puerta de enlace reemplaza una matriz o un objeto anidado como banner completo, por lo que si establece banner.text en una política de rol, la puerta de enlace descarta el banner.backgroundColor de la base.

Si no implementa Claude Desktop, deje desktop completamente fuera de sus políticas; la puerta de enlace luego devuelve 404 desde /user/bootstrap para cada usuario.

Precedencia con otras fuentes administradas

Si un dispositivo también tiene una política entregada por MDM o un managed-settings.json local, la configuración entregada por puerta de enlace tiene rango primero. Precedencia dentro del nivel administrado en la página de configuración administrada dice cuándo se aplican las fuentes locales, y tiene las claves que Claude Code lee de cada fuente de administrador independientemente de cuál fuente seleccione, como las claves de bloqueo de sandbox, forceRemoteSettingsRefresh y la fusión env por variable. Un policyHelper configurado en un perfil MDM o el archivo de configuración administrada se ejecuta solo cuando la puerta de enlace no entrega configuración; la entrada dice qué reemplaza su salida.

Los hosts de incrustación como Claude Desktop pueden suministrar política a través de la opción managedSettings del SDK. Configuración de padres de hosts de incrustación dice cuándo Claude Code la aplica, y Restringir configuración de padres enumera qué configuración de dirección de permitir aún se aplica sin los bloqueos allowManaged*Only.

Las políticas de puerta de enlace se aplican a cada invocación de Claude Code en la máquina, incluidas ejecuciones no interactivas claude -p y sesiones generadas por el SDK del agente. Si la puerta de enlace es inaccesible al iniciar, las sesiones firmadas salen con un error en lugar de ejecutarse sin su política.

`telemetry`

El CLI envía métricas, registros y, cuando está habilitado, trazas del Protocolo OpenTelemetry (OTLP) sobre HTTP a la puerta de enlace, que las retransmite textualmente a cada destino configurado. Consulte Monitoreo de uso para las métricas y eventos que emite el CLI.

El CLI marca cada exportación con la identidad del usuario autenticado, leída del JWT emitido por la puerta de enlace: los atributos user.id, user.email y user.groups. La atribución de costo y uso por desarrollador funciona sin configuración del lado del desarrollador.

telemetry:
  forward_to:
    - url: https://otel-collector.internal.example.com
      headers:
        Authorization: ${OTLP_TOKEN}
      # Opt-in por señal. Predeterminado: solo métricas.
      metrics: true
      logs: false
      traces: false
    - url: https://api.datadoghq.com/api/v2/otlp
      headers:
        DD-API-KEY: ${DD_API_KEY}

Cada URL forward_to debe usar https://, con una excepción para un recopilador en la interfaz de bucle de retorno de la puerta de enlace:

  • http://localhost:<port> pasa la validación de configuración, pero la protección SSRF bloquea cada exportación con ECONNREFUSED_SSRF a menos que establezca CLAUDE_GATEWAY_ALLOW_LOOPBACK=1 en el entorno de la puerta de enlace
  • http://127.0.0.1:<port> o http://[::1]:<port> falla al arrancar a menos que esa variable esté establecida

Para un recopilador en clúster, expóngalo sobre HTTPS en su propia dirección interna, o ejecútelo como un sidecar con la variable establecida.

La telemetría está desactivada en el CLI de forma predeterminada. Configurar telemetry.forward_to junto con listen.public_url la activa. La puerta de enlace empuja seis variables env a cada cliente conectado a travé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>
  • OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf

El punto final empujado se construye a partir de la URL pública, por lo que las métricas y registros no necesitan configuración OTEL de desarrolladores o políticas. La configuración empujada se aplica en el nivel administrado, anulando variables OTEL_* que un desarrollador establece localmente. Ya sea que la puerta de enlace empuje estas variables o no, un CLI firmado a través de /login que tenga la exportación OTLP/HTTP habilitada envía sus exportaciones a la puerta de enlace en lugar de a un punto final configurado localmente, y sin un destino forward_to para una señal la puerta de enlace acepta y descarta; si ya recopila telemetría de Claude Code directamente, agregue su recopilador como destino forward_to.

Las trazas además requieren CLAUDE_CODE_ENHANCED_TELEMETRY_BETA=1 en cada cliente. La puerta de enlace no empuja esa variable, así que establézcala a través del bloque env de una política administrada. No está entre las variables que Claude Code aplica sin la aprobación del desarrollador, por lo que entregarla a través de una política está cubierta por el mismo diálogo de aprobación de seguridad que el punto final OTLP empujado ya desencadena.

Tanto las codificaciones OTLP de protobuf como JSON se retransmiten, y cualquier backend compatible con OpenTelemetry funciona como destino.

Ajuste de HTTP

Cuatro bloques opcionales de nivel superior, access_control, limits, timeouts y rate_limits, ajustan la superficie HTTP. Los valores predeterminados se adaptan a la mayoría de implementaciones.

Bloque Clave Predeterminado Descripción
access_control allow_cidrs / deny_cidrs vacío Permitir/denegar IP de entrada por dirección de cliente, después de la resolución de trusted_proxies. deny_cidrs se verifica primero; un cliente que coincida se rechaza incluso si allow_cidrs también coincide. Si allow_cidrs no está vacío, la puerta de enlace es predeterminada denegada. /healthz y /readyz están exentos de allow_cidrs.
limits max_request_bytes 32 MiB Cuerpo de solicitud de entrada máximo; las solicitudes de tamaño excesivo obtienen 413 antes de que el cuerpo se almacene en búfer. Aumente para solicitudes de archivo o imagen grandes.
limits max_request_header_bytes sin establecer Cuando se establece, los encabezados de tamaño excesivo devuelven 431
limits max_url_length sin establecer Cuando se establece, una URL demasiado larga devuelve 414
timeouts upstream_ttfb_ms 120000 Espera máxima para los encabezados de respuesta del upstream (tiempo hasta el primer byte). El cuerpo de respuesta luego se transmite sin límite de reloj de pared. Se aplica a la ruta de upstream de Anthropic directo; cada otro proveedor está limitado por el tiempo de espera propio del SDK del proveedor.
rate_limits device_authorization.max / .window_seconds 30 / 600 Límite de velocidad por IP en el punto final de autorización de dispositivo no autenticado. Aumente para una organización grande detrás de una IP de salida compartida o NAT. Estos límites se aplican solo al flujo de inicio de sesión de concesión de dispositivo, no a la inferencia /v1/messages. Consulte Resistencia de fuerza bruta de código de usuario.
rate_limits device_verify.max / .window_seconds 10 / 600 Límite de velocidad por IP en envíos de user_code en /device

Ejemplo completo

Esta configuración de referencia completa ejercita cada sección principal; los bloques ajuste de HTTP mantienen sus valores predeterminados. Cópiela, elimine lo que no necesite y complete sus valores. La configuración en el Inicio rápido es una versión mínima de esta.

# Ejecutar con:
#   claude gateway --config gateway.yaml
#
# La verbosidad del registro operativo se controla mediante la variable de entorno
# CLAUDE_GATEWAY_LOG_LEVEL (debug | info | warn | error; predeterminado info). debug
# también registra los nombres de reclamación en cada id_token, para diagnóstico de groups_claim.
# No afecta eventos de auditoría, que siempre se emiten.

listen:
  host: 0.0.0.0
  port: 8080
  public_url: https://claude-gateway.internal.example.com
  # Omita el bloque tls cuando se ejecute detrás de una entrada que termine TLS.
  # tls:
  #   cert: /certs/gateway.crt
  #   key: /certs/gateway.key
  # trusted_proxies:
  #   - 10.0.0.0/8

oidc:
  issuer: https://example.okta.com
  client_id: 0oa1example2
  client_secret: ${OIDC_CLIENT_SECRET}
  allowed_email_domains:
    - example.com
  # Requerido cuando el emisor es el servidor org de Okta, cuyos id_tokens
  # pueden omitir correo electrónico y grupos; la puerta de enlace los completa desde /userinfo.
  userinfo_fallback: true
  # allowed_groups: [claude-code-users]
  # Okta emite grupos solo cuando se solicita el alcance `groups` y el
  # filtro de reclamación de grupos de la aplicación los permite. La política de contratistas a continuación
  # coincide en grupos, por lo que el alcance se solicita aquí.
  scopes: [openid, profile, email, offline_access, groups]
  # extra_auth_params: { access_type: offline, prompt: consent }  # Google
  # groups_claim: groups          # Roles de aplicación de Entra: use `roles`
  # email_claim: email

session:
  jwt_secret: ${GATEWAY_JWT_SECRET}   # openssl rand -base64 32
  # ttl_hours: 1

store:
  postgres_url: ${GATEWAY_POSTGRES_URL}
  # max_connections: 5

# Habilita /v1/organizations/spend_limits (refleja la API de administración de Anthropic)
# y cumplimiento de gasto por desarrollador en /v1/messages. Omita para desactivar.
# Los límites en sí se establecen a través de la API de administración, no aquí.
# admin:
#   write_keys:
#     - { id: terraform, key: "${GATEWAY_ADMIN_WRITE_KEY_TF}" }
#   read_keys:
#     - { id: reporting, key: "${GATEWAY_ADMIN_READ_KEY}" }
#   admin_groups: [platform-finops]
#   blocked_message: request an increase at https://go.example.com/claude-limits
#   # audit_retention_days: 365
#   # spend_retention_months: 13
#   # identity_retention_days: 90
#   # group_limit_mode: min

# enforcement:
#   fail_closed_on_error: false

# Medir a tasas contratadas en lugar del precio de lista USD. Requiere admin:.
# Las tasas a continuación son marcadores de posición, no precios de contrato reales.
# pricing:
#   multiplier: 0.85
#   overrides:
#     - { upstream: anthropic, model: claude-sonnet-4-6, input: 3.30, output: 16.50, cache_read: 0.33, cache_write: 4.125 }

upstreams:
  - provider: anthropic
    auth:
      api_key: ${ANTHROPIC_API_KEY}

  # - provider: bedrock
  #   region: us-east-1
  #   auth: {}

  # - provider: anthropicAws
  #   region: us-east-1
  #   workspace_id: wrkspc_...
  #   auth:
  #     api_key: ${ANTHROPIC_AWS_API_KEY}

  # - provider: vertex
  #   region: us-east5
  #   project_id: example-prod
  #   auth: {}

  # - provider: foundry
  #   resource: example-foundry
  #   auth: { use_azure_ad: true }

auto_include_builtin_models: true
models:
  - id: claude-opus-4-8
    label: Claude Opus 4.8
    upstream_model:
      anthropic: claude-opus-4-8
      # bedrock: us.anthropic.claude-opus-4-8
      # anthropicAws: claude-opus-4-8
      # vertex: claude-opus-4-8
      # foundry: <your-opus-deployment-name>
  - id: claude-sonnet-4-6
    label: Claude Sonnet 4.6
    upstream_model:
      anthropic: claude-sonnet-4-6
  - id: claude-haiku-4-5
    label: Claude Haiku 4.5
    upstream_model:
      anthropic: claude-haiku-4-5

managed:
  policies:
    - match: { groups: [contractors] }
      cli:
        availableModels: [claude-haiku-4-5]
        # Restrinja la opción del selector predeterminado a availableModels en lugar de
        # el predeterminado de nivel, para que los contratistas no obtengan un 400 en el predeterminado.
        enforceAvailableModels: true
        # allow aprueba automáticamente estas herramientas; no bloquea el resto.
        # Agregue reglas de denegación para restringir herramientas.
        permissions: { allow: [Read, Grep] }
    - match: {}
      cli:
        availableModels: [claude-opus-4-8, claude-sonnet-4-6, claude-haiku-4-5]
        permissions:
          allow: [Read, Grep, Bash, Edit]
          deny: ["WebFetch"]
        env: { HTTP_PROXY: http://proxy.example.com:8080 }

telemetry:
  forward_to:
    - url: https://otel.internal.example.com:4318
      headers:
        Authorization: Bearer ${OTEL_TOKEN}

Configuración administrada del lado del cliente

Todo lo anterior configura el servidor de puerta de enlace. Apuntar máquinas de desarrollador a la puerta de enlace se configura por separado, en cada dispositivo, a través de la configuración administrada de Claude Code. La puerta de enlace no puede empujar las claves de inicio de sesión por sí misma, porque son lo que le dice al cliente dónde está la puerta de enlace.

Para el CLI, establezca estas claves en el managed-settings.json por SO. Las dos claves de inicio de sesión enrutan el /login de cada desarrollador a su puerta de enlace:

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

parentSettingsBehavior: "merge" mantiene el funcionamiento de la entrega de Claude Desktop de la lista de permitidos de salida a sus sesiones de Claude Code integradas; Entregar política a sesiones de Claude Desktop explica el mecanismo y dónde debe estar la aceptación.

Implemente el archivo managed-settings.json en cada dispositivo, típicamente a través de su plataforma MDM. La ruta del archivo difiere por plataforma:

Plataforma Ruta
macOS /Library/Application Support/ClaudeCode/managed-settings.json, o el dominio de preferencias administradas com.anthropic.claudecode
Linux y WSL /etc/claude-code/managed-settings.json
Windows C:\Program Files\ClaudeCode\managed-settings.json, o Política de grupo a través del registro HKLM

De forma predeterminada, una política de registro en Windows o una plist de preferencias administradas en macOS reemplaza el archivo managed-settings.json en lugar de fusionarse con él, aparte de las claves de excepción y verificaciones entre fuentes anteriores. Las tres claves en este fragmento siguen la regla de fuente de prioridad más alta, por lo que las flotas que entregan política a través de Política de grupo o perfiles de configuración deben poner las tres en ese mecanismo en su lugar.

Para Claude Desktop, establezca la clave bootstrapUrl en la propia configuración administrada de Claude Desktop en <listen.public_url>/user/bootstrap. El flujo de inicio de sesión y la política por grupo coinciden entonces con los del CLI una vez que una política se acepta del lado del servidor con una clave desktop; sin la aceptación, /user/bootstrap devuelve 404. Consulte Superposición de Claude Desktop para la mitad del lado del servidor.

forceLoginGatewayUrl, y el valor "gateway" de forceLoginMethod, se honran solo desde una fuente administrada en la máquina: managed-settings.json, la plist de macOS o el registro HKLM de Windows, o un asistente de política. Un desarrollador que los establezca en su propio ~/.claude/settings.json no tiene efecto, y tampoco lo hace establecerlos en la carga útil de la puerta de enlace.