gateway.yaml. Файл определяет всё, что делает gateway: где он слушает, как разработчики входят в систему, куда идёт вывод, и какие политики и телеметрия применяются. Эта страница — справочник по каждому параметру в этом файле.
Чтобы написать свой первый файл, начните с quickstart, который создаёт минимальную рабочую конфигурацию и запускает её. Когда у вас будет конфигурация, которой вы довольны, руководство по развёртыванию охватывает контейнеризацию и размещение на Kubernetes, Cloud Run или вашей собственной платформе.
Gateway читает файл один раз при запуске с помощью claude gateway --config /path/to/gateway.yaml. Каждый параметр проверяется по схеме при загрузке, поэтому неправильная конфигурация не запускается с ошибкой на уровне поля, а не при первом использовании.
Полный пример в конце этой страницы охватывает каждый раздел.
Структура файла
Пять разделов обязательны. Все остальные разделы опциональны, и пропущенный раздел принимает значения по умолчанию. Неизвестные ключи приводят к сбою при загрузке, поэтому опечатка выявляется как именованная ошибка, а не как молча игнорируемый параметр. Обязательные разделы:listen: адрес привязки, публичный URL, завершение TLSoidc: ваш поставщик идентификации (IdP), включая издателя, клиента, сопоставление утверждений и кто может входитьsession: токены-носители, которые выпускает gateway, с секретом и временем жизниstore: PostgreSQL для грантов устройств и счётчиков ограничения скоростиupstreams: куда идёт вывод, будь то Anthropic, Amazon Bedrock, Claude Platform на AWS, Agent Platform Google Cloud или Microsoft Foundry
admin: аутентификация Admin API и сохранение лимитов расходовenforcement: поведение лимитов расходов при отказе или разрешенииmodelsиauto_include_builtin_models: кураторский список моделей администратором и ID для каждого upstreammanaged: управляемые политики параметров по группам IdPtelemetry: пересылка OTLP на ваш стек наблюдаемостиaccess_control,limits,timeouts,rate_limits: разрешение/запрет IP, ограничения размера запроса, время до первого байта upstream и лимиты входа по IP
Расширение секретов
Не пишите секреты, такие какclient_secret, jwt_secret или postgres_url, прямо в gateway.yaml. Ссылайтесь на них одной из форм ниже, и gateway разрешит значение при загрузке из переменной окружения или файла:
Обязательные разделы
listen
Блок listen управляет тем, где служит gateway: адрес привязки и порт, видимое снаружи происхождение и опциональное завершение TLS.
oidc
Блок oidc подключает gateway к вашему поставщику идентификации и решает, кто может входить. Он называет издателя и клиента OAuth, сопоставляет утверждения, которые несут электронную почту и группы, и ограничивает вход по домену электронной почты или группе.
OpenID Connect (OIDC) — это протокол SSO, который gateway использует с вашим поставщиком идентификации; см. Настройка поставщика идентификации для того, что нужно зарегистрировать на стороне IdP.
session
Блок session формирует токены-носители, которые выпускает gateway после входа: секрет, который их подписывает, и как долго они живут.
store
Блок store указывает gateway на его базу данных PostgreSQL, которая содержит гранты устройств и счётчики ограничения скорости.
Для локальной разработки укажите
postgres_url на одноразовый контейнер Postgres, например docker run --rm -p 5432:5432 -e POSTGRES_HOST_AUTH_METHOD=trust postgres.
upstreams
upstreams — это упорядоченный список. Gateway пересылает вывод на первый upstream, который разрешает запрошенную модель. На 5xx, 429, 401, 403, 404 или timeout он переходит на следующий; другие 4xx не переходят, потому что эти ошибки относятся к запросу, а не к upstream. 401 или 403 означает, что собственные учётные данные gateway не прошли проверку на этом upstream, а 404 означает, что этот upstream не служит запрошенной модели, поэтому более поздний upstream в списке всё ещё может.
Переход при 404 требует gateway v2.1.198 или позже. Более ранние выпуски возвращали первый 404 клиенту даже когда более поздний upstream в списке служил модели.
Несколько upstream одного поставщика должны установить отличный name:.
Клиенты Bedrock, Claude Platform on AWS, Agent Platform и Foundry создаются один раз при запуске, и их SDK обновляют учётные данные внутри, поэтому ротация облачных учётных данных не требует перезагрузки. Статические ключи API Anthropic и носители читаются при запуске; см. Anthropic API.
Anthropic API
Минимальный upstream Anthropic — это ключ API из Claude Console:api_key: отправляетx-api-key. Ротируйте его в Claude Console и обновите переменную env.oauth_token: отправляетAuthorization: Bearer. Используйте форму носителя, когда ваша организация выпускает короткоживущие токены вместо долгоживущих ключей API. Носитель читается один раз при запуске, поэтому обновите, переподключив секрет и перезагрузив.
Amazon Bedrock
Для развёртывания Bedrock на стороне клиента, которое gateway заменяет или находится перед ним, см. Claude Code на Amazon Bedrock. Upstream на стороне gateway:auth использует цепочку учётных данных AWS SDK по умолчанию: переменные env, ~/.aws/credentials, роль задачи ECS, метаданные экземпляра EC2 или IRSA на EKS. В production дайте поду gateway роль IAM вместо встраивания статических ключей в образ контейнера.
Явные учётные данные должны быть полными: gateway не запускается, когда aws_access_key_id и aws_secret_access_key не установлены вместе, или когда aws_session_token установлен без них. До v2.1.207 частичный блок auth: прошёл проверку.
Claude Platform on AWS
Claude Platform on AWS служит первоклассный Anthropic API на инфраструктуре AWS вaws-external-anthropic.<region>.api.aws. Он использует первоклассные ID моделей, соблюдает заголовки anthropic-beta в том виде, в котором они отправлены, и служит count_tokens, поэтому никакой перевод, специфичный для Bedrock, не применяется. Поставщик anthropicAws требует Claude Code v2.1.198 или позже; более ранние выпуски gateway отклоняют его при загрузке.
Для развёртывания на стороне клиента той же платформы см. Claude Code на Claude Platform on AWS. Upstream на стороне gateway:
aws-external-anthropic, поэтому роль IAM, ограниченная Bedrock, не авторизует её. Ключ API в auth.api_key имеет приоритет, когда также установлены учётные данные SigV4. Пустой блок auth использует цепочку учётных данных AWS SDK по умолчанию, ту же цепочку, которую использует upstream Amazon Bedrock.
Поскольку платформа разрешает первоклассные ID моделей, встроенный каталог маршрутизирует на неё без блока
models:. Когда вы курируете список models:, ключируйте запись anthropicAws: с первоклассным ID.
Google Cloud Agent Platform
Для эквивалентной настройки на стороне клиента см. Claude Code на Google Cloud. Upstream на стороне gateway:auth использует Application Default Credentials: GOOGLE_APPLICATION_CREDENTIALS, метаданные GCE или Workload Identity GKE. Файлы ключей JSON сервис-аккаунта поддерживаются, но не рекомендуются; используйте Workload Identity или присоедините сервис-аккаунт к экземпляру GCE или Cloud Run.
Установите region: global для использования глобальной конечной точки Agent Platform вместо региональной. Google затем маршрутизирует каждый запрос в доступный регион, поэтому вы не отслеживаете доступность модели для каждого региона. Установка конкретного региона закрепляет каждый запрос на нём.
Microsoft Foundry
Для развёртывания Foundry на стороне клиента см. Claude Code на Microsoft Foundry. Upstream на стороне gateway:use_azure_ad: true разрешается через DefaultAzureCredential: Managed Identity на AKS, ACI или App Service; Azure CLI; или учётные данные окружения. Ключи API работают, но являются проектными и не ротируются автоматически. Конечная точка Foundry получена из resource:; установите опциональный base_url для переопределения для суверенных облаков, таких как Azure Government.
Несколько upstream
Один и тот же поставщик может появляться более одного раза с отличнымname:. Это охватывает разные регионы, разные учётные записи через разные цепочки учётных данных, выделенную пропускную способность в сравнении с по требованию и кросс-провайдерный fallback.
Gateway пробует upstream по порядку. 5xx, 429, 401, 403, 404, timeout и отсутствие конечной точки (501) переходят; другие 4xx не переходят.
429 — это пропускная способность для каждого upstream, поэтому истощение выделенной пропускной способности (PT) переходит на по требованию. 404 — это доступность модели для каждого upstream, поэтому upstream, который не включил модель, не блокирует более поздний upstream, который её служит. Upstream, который не может разрешить запрошенную модель, пропускается без сетевого раундтрипа.
Этот пример маршрутизирует выделенное выделение пропускной способности Bedrock в первую очередь, переполнение на по требованию и вторую учётную запись, и переходит на Anthropic API в последнюю очередь:
Переход между облачными провайдерами или на прямой Anthropic API изменяет, какое соглашение, география и другие условия управляют запросом.
CLI применяет одинаковое управление функциями к gateway независимо от того, какой upstream служит данному запросу, поэтому переход не отправляет поле тела, которое upstream отклонил бы.
Опциональные разделы
admin
Опциональный. Включает /v1/organizations/spend_limits, который отражает публичный Admin API Anthropic, и применение расходов для каждого разработчика на /v1/messages. См. Лимиты расходов для того, как устанавливаются и применяются ограничения; этот раздел охватывает ключи gateway.yaml, которые включают функцию и настраивают её.
enforcement
Блок enforcement управляет тем, как проверки лимитов расходов ведут себя, когда хранилище недоступно.
models
Блок models — это опциональный кураторский список моделей администратором, обслуживаемый в /v1/models и используемый для перевода ID моделей для каждого upstream. Требуется для регионов Bedrock, не входящих в США, ARN выделенной пропускной способности Amazon Bedrock и имён развёртываний Microsoft Foundry.
managed
Блок managed определяет политики доступа на основе ролей, ключённые на группы IdP или домен электронной почты. Политики оцениваются по порядку; первое совпадение выбирается, затем объединяется на базу match: {} catch-all, описанную ниже. Они обслуживаются для каждого пользователя в GET /managed/settings с кешированием ETag/304.
match: {}, обычно указываемый в последнюю очередь, рассматривается как базовый слой. Каждая другая политика наследует любой ключ, который она не устанавливает, из catch-all, поэтому записи для каждой роли должны только перечислять то, что отличается от организационного значения по умолчанию. Правила слияния зависят от типа ключа:
- Списки разрешений:
availableModelsиpermissions.allow. Список конкретной политики полностью заменяет базовый. - Списки запретов и массивы hooks:
permissions.deny,permissions.ask,disabledMcpjsonServers,deniedMcpServers,blockedMarketplacesи каждый массив типа событияhooks. Они берут объединение базового и политики, поэтому организационный запрет или hook аудита не может быть случайно удалён переопределением для каждой роли. - Ключи типа Record:
env,modelOverridesиskillOverrides. Эти поверхностные слияния, поэтому блокenvдля каждой роли переопределяет ключи, которые он устанавливает, и наследует остальное из базового.
availableModels также применяется на стороне сервера в /v1/messages, поэтому запрещённая модель возвращает 400 независимо от того, что отправляет клиент.
Аутентифицированный пользователь, который не соответствует ни одной политике, получает значения по умолчанию gateway, что означает каждую модель в каталоге и никаких управляемых параметров. Добавьте catch-all
match: {} в последнюю очередь, если вы хотите гарантированную политику по умолчанию.
Gateway не ведёт собственный каталог пользователей. Он авторизует каждый запрос из токена IdP пользователя, читая членство в группе из утверждения
groups токена и оценивая политики против него. Нет реестра для перечисления и нет учётных записей для предварительного создания, и поэтому нет конечной точки SCIM, потому что нечего синхронизировать в SCIM.Запустите управление жизненным циклом пользователя и группы в источнике истины, который является собственной подготовкой SCIM вашего IdP или выделенной платформой управления идентификацией. Членство и отзыв, управляемые там, автоматически поступают в gateway через токен. Если вы хотите подготовку SCIM самих учётных записей Claude, это возможность Claude for Enterprise.Применяются два часов распространения:- Содержимое политики: редактирование политики и переразвёртывание достигает подключённых клиентов при их следующем опросе управляемых параметров, в течение часа
- Членство в группе: изменение членства пользователя в группе изменяет, какая политика соответствует им. Это вступает в силу при следующем переминте сеанса, означая следующее молчаливое обновление, ограниченное
session.ttl_hours.
Что входит в cli
Каждое значение cli — это полный документ Claude Code managed-settings.json, та же схема, которую вы развернули бы через MDM или /etc/claude-code/managed-settings.json, выраженная здесь как YAML. CLI применяет доставленный документ на управляемом уровне, выше параметров пользователя и проекта.
Gateway проверяет каждый документ по схеме параметров CLI при загрузке, поэтому неузнанный ключ верхнего уровня или узнанный ключ с неправильным значением не запускается с ошибкой, называющей каждый нарушающий ключ. Намеренно открытые части схемы всё ещё принимают произвольные значения, потому что более новые клиенты могут распознавать записи, которые схема gateway не распознаёт. Эти открытые ключи — env, pluginConfigs и ключи, вложенные под permissions.
Поскольку проверка использует схему, поставляемую с установленной версией gateway, размещение ключа параметров верхнего уровня, введённого более новым выпуском Claude Code, в управляемую конфигурацию требует сначала обновления gateway. Дымовой тест новой политики на одном клиенте перед развёртыванием.
Полный справочник ключей находится в Параметры Claude Code. Ключи, которые операторы достают в первую очередь:
Поскольку эти параметры поступают по сети, CLI показывает каждому разработчику диалог одобрения безопасности один раз перед применением чего-либо, что может запустить команду оболочки или изменить, куда идёт трафик. Диалог охватывает:
hooks- переменные
env, которые не находятся в встроенном списке безопасности CLI - параметры выполнения оболочки, такие как
apiKeyHelperиstatusLine - управляемое содержимое CLAUDE.md
env применяются без одобрения:
- В списке безопасности: переменные автообновления и имён моделей
- Не в списке безопасности: переменные прокси, переменные базового URL и
OTEL_EXPORTER_OTLP_ENDPOINT
OTEL_EXPORTER_OTLP_ENDPOINT, поэтому установка telemetry.forward_to запускает диалог на каждом интерактивном клиенте. Диалог защищает машину разработчика от скомпрометированного или враждебного gateway, а не организацию от разработчика.
Неинтерактивный запуск с флагом -p не может показать диалог. Он применяет отправленные параметры только для этого запуска и не записывает их как одобренные, поэтому следующий интерактивный сеанс разработчика всё ещё показывает диалог. До версии 2.1.207 неинтерактивный запуск сохранял параметры как одобренные и ни один последующий интерактивный сеанс не показывал диалог для них.
Если разработчик отклоняет, Claude Code выходит, а не применяет политику. Отправка нового hook или переменной env, не входящей в список безопасности, в широкую политику означает диалог одобрения при каждом запуске каждого соответствующего разработчика.
Ключ cli был назван settings в более ранних выпусках. Это написание всё ещё принимается как псевдоним, но новые развёртывания должны использовать cli.
Приоритет с другими управляемыми источниками
Если устройство также имеет локальныйmanaged-settings.json или политику, доставленную MDM, управляемые источники не объединяются. Источник с наивысшим приоритетом предоставляет все параметры политики, ранжированные в этом порядке с наивысшим приоритетом в первую очередь:
- Помощник политики
- Параметры, доставленные gateway
- MDM, через реестр HKLM на Windows или plist на macOS
- Файл
managed-settings.json - Реестр HKCU, только на Windows
managedSettings. Она игнорируется по умолчанию и применяется только, когда управляемый источник выбирает с parentSettingsBehavior: "merge", отфильтрованный так, чтобы он мог ужесточить политику, но не ослабить её.
Исключением является небольшой набор кросс-источниковых ключей, соблюдаемых, когда любой источник администратора их устанавливает; пользовательский уровень HKCU исключён:
sandbox.network.allowManagedDomainsOnlyиsandbox.filesystem.allowManagedReadPathsOnly: когда заблокированы, соответствующие списки разрешений объединяются между источникамиallowAllClaudeAiMcps: переопределение разрешения только для списка разрешений MCP claude.aisandbox.bwrapPathиsandbox.socatPath: пути файловой системы к вспомогательным двоичным файлам sandboxforceRemoteSettingsRefresh: блокирует запуск до тех пор, пока удалённые управляемые параметры не будут свежо получены, поэтому политика MDM или файла, которая её устанавливает, соблюдается даже когда кэшированный удалённый payload, в котором отсутствует ключ, является источником с наивысшим приоритетом
allowManagedPermissionRulesOnly и disableBypassPermissionsMode, поступает только из источника с наивысшим приоритетом. См. Приоритет параметров для того же правила на странице параметров.
Политики gateway применяются к каждому вызову Claude Code на машине, включая неинтерактивные запуски claude -p и сеансы, порождённые Agent SDK. Если gateway недоступен при запуске, подписанные сеансы выходят с ошибкой, а не запускаются без своей политики.
telemetry
CLI отправляет OpenTelemetry Protocol (OTLP) по HTTP метрики, логи и, когда включено, трассировки на gateway, который передаёт их дословно каждому настроенному назначению. См. Мониторинг использования для метрик и событий, которые выпускает CLI.
CLI штампует каждый экспорт идентификацией аутентифицированного пользователя, прочитанной из JWT, выданного gateway: атрибуты user.id, user.email и user.groups. Атрибуция затрат и использования для каждого разработчика поэтому работает без конфигурации на стороне разработчика.
telemetry.forward_to вместе с listen.public_url включает её. Gateway отправляет пять переменных env каждому подключённому клиенту через /managed/settings:
CLAUDE_CODE_ENABLE_TELEMETRY=1OTEL_METRICS_EXPORTER=otlpOTEL_LOGS_EXPORTER=otlpOTEL_TRACES_EXPORTER=otlpOTEL_EXPORTER_OTLP_ENDPOINT=<public_url>
OTEL_*, которые разработчик устанавливает локально.
Трассировки дополнительно требуют CLAUDE_CODE_ENHANCED_TELEMETRY_BETA=1 на каждом клиенте. Gateway не отправляет эту переменную, поэтому установите её через блок env управляемой политики. Она не находится в списке безопасности CLI, поэтому доставка её через политику охватывается тем же диалогом одобрения безопасности, который отправленная конечная точка OTLP уже запускает.
Оба кодирования OTLP protobuf и JSON передаются, и любой совместимый с OpenTelemetry backend работает как назначение.
HTTP tuning
Четыре опциональных блока верхнего уровня,access_control, limits, timeouts и rate_limits, настраивают HTTP поверхность. Значения по умолчанию подходят для большинства развёртываний.
Полный пример
Эта полная справочная конфигурация охватывает каждый основной раздел; блоки HTTP tuning сохраняют свои значения по умолчанию. Скопируйте её, удалите то, что вам не нужно, и заполните свои значения. Конфигурация в Quickstart — это минимальная версия этого.gateway.yaml
Управляемые параметры на стороне клиента
Всё выше настраивает сервер gateway. Указание машин разработчиков на него настраивается отдельно, на каждом устройстве, через управляемые параметры Claude Code. Gateway не может отправлять эти ключи сам, потому что они говорят клиенту, где находится gateway. Для CLI установите оба ключа вmanaged-settings.json для каждой ОС:
forceLoginGatewayUrl и значение "gateway" forceLoginMethod соблюдаются только из управляемого уровня, управляемого администратором. Разработчик, устанавливающий их в своём собственном ~/.claude/settings.json, не имеет эффекта.
Связанное
- Обзор Claude apps gateway: quickstart и подключение разработчика
- Руководство по развёртыванию: настройка IdP, образ контейнера, Kubernetes и Cloud Run, и операции
- Лимиты расходов: ограничения для каждого разработчика и Admin API