Перейти к основному содержанию
Развёртывание Claude apps gateway настраивается одним файлом YAML, обычно gateway.yaml. Файл определяет всё, что делает gateway: где он слушает, как разработчики входят в систему, куда идёт вывод, и какие политики и телеметрия применяются. Эта страница — справочник по каждому параметру в этом файле. Чтобы написать свой первый файл, начните с quickstart, который создаёт минимальную рабочую конфигурацию и запускает её. Когда у вас будет конфигурация, которой вы довольны, руководство по развёртыванию охватывает контейнеризацию и размещение на Kubernetes, Cloud Run или вашей собственной платформе. Gateway читает файл один раз при запуске с помощью claude gateway --config /path/to/gateway.yaml. Каждый параметр проверяется по схеме при загрузке, поэтому неправильная конфигурация не запускается с ошибкой на уровне поля, а не при первом использовании. Полный пример в конце этой страницы охватывает каждый раздел.

Структура файла

Пять разделов обязательны. Все остальные разделы опциональны, и пропущенный раздел принимает значения по умолчанию. Неизвестные ключи приводят к сбою при загрузке, поэтому опечатка выявляется как именованная ошибка, а не как молча игнорируемый параметр. Обязательные разделы:
  • listen: адрес привязки, публичный URL, завершение TLS
  • oidc: ваш поставщик идентификации (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 для каждого upstream
  • managed: управляемые политики параметров по группам IdP
  • telemetry: пересылка 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. Носитель читается один раз при запуске, поэтому обновите, переподключив секрет и перезагрузив.
Вместо статического ключа или носителя вы можете использовать Workload Identity Federation. Создайте правило федерации, следуя руководству Workload Identity Federation, затем смонтируйте JWT OIDC вашей рабочей нагрузки как файл, такой как проецируемый токен сервис-аккаунта Kubernetes или id-token платформы CI. Gateway обменивает JWT на короткоживущий носитель и автоматически его обновляет. Файл токена перечитывается при каждом обмене, поэтому ротированные проецируемые токены подхватываются без перезагрузки.

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 от Amazon Bedrock и подписывает запросы SigV4 для собственного имени сервиса, 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.
Catch-all 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
Телеметрия gateway отправляет OTEL_EXPORTER_OTLP_ENDPOINT, поэтому установка telemetry.forward_to запускает диалог на каждом интерактивном клиенте. Диалог защищает машину разработчика от скомпрометированного или враждебного gateway, а не организацию от разработчика. Неинтерактивный запуск с флагом -p не может показать диалог. Он применяет отправленные параметры только для этого запуска и не записывает их как одобренные, поэтому следующий интерактивный сеанс разработчика всё ещё показывает диалог. До версии 2.1.207 неинтерактивный запуск сохранял параметры как одобренные и ни один последующий интерактивный сеанс не показывал диалог для них. Если разработчик отклоняет, Claude Code выходит, а не применяет политику. Отправка нового hook или переменной env, не входящей в список безопасности, в широкую политику означает диалог одобрения при каждом запуске каждого соответствующего разработчика. Ключ cli был назван settings в более ранних выпусках. Это написание всё ещё принимается как псевдоним, но новые развёртывания должны использовать cli.

Приоритет с другими управляемыми источниками

Если устройство также имеет локальный managed-settings.json или политику, доставленную MDM, управляемые источники не объединяются. Источник с наивысшим приоритетом предоставляет все параметры политики, ранжированные в этом порядке с наивысшим приоритетом в первую очередь:
  1. Помощник политики
  2. Параметры, доставленные gateway
  3. MDM, через реестр HKLM на Windows или plist на macOS
  4. Файл managed-settings.json
  5. Реестр HKCU, только на Windows
Встраивающие хосты могут предоставлять политику через опцию SDK managedSettings. Она игнорируется по умолчанию и применяется только, когда управляемый источник выбирает с parentSettingsBehavior: "merge", отфильтрованный так, чтобы он мог ужесточить политику, но не ослабить её. Исключением является небольшой набор кросс-источниковых ключей, соблюдаемых, когда любой источник администратора их устанавливает; пользовательский уровень HKCU исключён:
  • sandbox.network.allowManagedDomainsOnly и sandbox.filesystem.allowManagedReadPathsOnly: когда заблокированы, соответствующие списки разрешений объединяются между источниками
  • allowAllClaudeAiMcps: переопределение разрешения только для списка разрешений MCP claude.ai
  • sandbox.bwrapPath и sandbox.socatPath: пути файловой системы к вспомогательным двоичным файлам sandbox
  • forceRemoteSettingsRefresh: блокирует запуск до тех пор, пока удалённые управляемые параметры не будут свежо получены, поэтому политика MDM или файла, которая её устанавливает, соблюдается даже когда кэшированный удалённый payload, в котором отсутствует ключ, является источником с наивысшим приоритетом
Каждый другой ключ, включая allowManagedPermissionRulesOnly и disableBypassPermissionsMode, поступает только из источника с наивысшим приоритетом. См. Приоритет параметров для того же правила на странице параметров. Политики gateway применяются к каждому вызову Claude Code на машине, включая неинтерактивные запуски claude -p и сеансы, порождённые Agent SDK. Если gateway недоступен при запуске, подписанные сеансы выходят с ошибкой, а не запускаются без своей политики.
mcpServers внутри блока cli политики отклоняется при загрузке gateway. Распределение MCP для каждой группы недоступно; развёртывайте MCP серверы через файловый managed-mcp.json на каждом устройстве или позвольте разработчикам добавлять их локально.

telemetry

CLI отправляет OpenTelemetry Protocol (OTLP) по HTTP метрики, логи и, когда включено, трассировки на gateway, который передаёт их дословно каждому настроенному назначению. См. Мониторинг использования для метрик и событий, которые выпускает CLI. CLI штампует каждый экспорт идентификацией аутентифицированного пользователя, прочитанной из JWT, выданного gateway: атрибуты user.id, user.email и user.groups. Атрибуция затрат и использования для каждого разработчика поэтому работает без конфигурации на стороне разработчика.
Каждое назначение выбирает metrics, logs и traces независимо, и по умолчанию только метрики. Сигналы отличаются по чувствительности:
  • Метрики: агрегированные счётчики, такие как количество токенов, количество запросов и задержка
  • Логи и трассировки: могут нести полные команды bash, входные данные инструментов и пути файлов, охватывая всё, что Claude Code делает на машине разработчика
Включайте логи и трассировки только на назначениях с управлением доступом и политикой сохранения, которые данные гарантируют.
Телеметрия отключена в CLI по умолчанию. Конфигурирование telemetry.forward_to вместе с listen.public_url включает её. Gateway отправляет пять переменных env каждому подключённому клиенту через /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>
Отправленная конечная точка строится из публичного URL, поэтому метрики и логи не нуждаются в конфигурации OTEL от разработчиков или политик. Отправленная конфигурация применяется на управляемом уровне, переопределяя переменные 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 для каждой ОС:
Развёртывайте этот файл на каждое устройство, обычно через вашу платформу MDM. Путь файла отличается по платформе: forceLoginGatewayUrl и значение "gateway" forceLoginMethod соблюдаются только из управляемого уровня, управляемого администратором. Разработчик, устанавливающий их в своём собственном ~/.claude/settings.json, не имеет эффекта.