Шлюз Claude apps для Amazon Bedrock, Claude Platform на AWS, Google Cloud и Microsoft Foundry

Запускайте Claude Code через Amazon Bedrock, Claude Platform на AWS, Google Cloud или Microsoft Foundry за самостоятельно размещаемым шлюзом с входом SSO, доступом к моделям по группам и телеметрией OTLP.

Claude apps gateway — это самостоятельно размещаемый сервис, который находится между клиентами Claude Code ваших разработчиков и вашим поставщиком модели. Разработчики входят с помощью вашего корпоративного поставщика удостоверений (IdP) вместо того, чтобы хранить ключи API или учетные данные облака. Шлюз хранит учетные данные вышестоящего уровня, обеспечивает доступ к модели и управляемые параметры по группам IdP и передает телеметрию использования в ваш собственный стек наблюдаемости.

Он включен в двоичный файл claude, поэтому тот же исполняемый файл, который запускает Claude Code на ноутбуке, запускает сервер шлюза с помощью claude gateway --config gateway.yaml.

На этой странице рассматривается:

• Почему Claude apps gateway, что он добавляет по сравнению с самостоятельным запуском и когда что-то другое подходит лучше
• Быстрый старт с предварительными требованиями, который переводит шлюз от нуля к вошедшему разработчику
• Подключение разработчиков, включая установку URL шлюза через управляемые параметры
• Доступность и ограничения, охватывающие какие функции Claude Code работают через шлюз и что поддерживает сервер

Дополнительные страницы углубляются в детали. Справочник по конфигурации охватывает каждый параметр в файле YAML, который пишет быстрый старт, а руководство по развертыванию охватывает настройку для каждого IdP, развертывание Kubernetes и Cloud Run, а также операции.

Почему Claude apps gateway

Обзор шлюза охватывает, что делает шлюз и почему вы бы его запустили. Claude apps gateway — это собственный шлюз Anthropic, встроенный в двоичный файл claude и протестированный вместе с каждым выпуском Claude Code, поэтому он пересылает заголовки и поля запроса, которые отправляет Claude Code, без того, чтобы операторы поддерживали отдельный список разрешений. После развёртывания он даёт вам:

• Учётные данные: ключ API вышестоящего уровня или учётные данные облака существуют только в вашей инфраструктуре. Разработчики аутентифицируются с помощью корпоративного SSO и получают краткосрочные токены-носители, поэтому отключение происходит в вашем IdP. Отключите пользователя, и его доступ к шлюзу истекает в течение времени жизни сеанса, по умолчанию один час.
• Контроль доступа: ваши группы IdP сопоставляются со списками разрешённых моделей и политиками управляемых параметров. Шлюз обеспечивает доступ к модели на стороне сервера, отклоняя запросы для неразрешённых моделей, и выбирает политику управляемых параметров каждой группы, которую CLI применяет на уровне управляемых параметров. Разные команды получают разные модели, инструменты и разрешения, и разработчик не может переопределить то, что его политика блокирует.
• Доставка параметров: шлюз доставляет управляемые параметры подписанным клиентам сам, занимая место параметров, управляемых сервером из консоли администратора claude.ai.
• Телеметрия: каждое настроенное назначение получает метрики OpenTelemetry Protocol (OTLP) с подсчётом токенов, моделью, идентификацией пользователя и задержкой по умолчанию, с журналами и трассировками как дополнительные параметры для каждого назначения.
• Маршрутизация вышестоящего уровня: клиенты говорят API Anthropic Messages с шлюзом, и шлюз переводит для каждого вышестоящего уровня, будь то Amazon Bedrock, Claude Platform on AWS, Agent Platform Google Cloud, Microsoft Foundry или API Anthropic, с отказоустойчивостью между ними. Вы можете менять регионы, поставщиков или порядок отказоустойчивости без того, чтобы разработчики замечали или переконфигурировали.

Для того, какие функции Claude Code работают через шлюз и что сам сервер поддерживает, см. Доступность и ограничения ниже. Для решений, таких как стоимость, обход, запуск нескольких шлюзов и бессерверные платформы, см. руководство по развёртыванию.

Другие реализации шлюза

Если вы уже запускаете шлюз LLM или шлюз API, который соответствует вашим потребностям, продолжайте его использовать; Другие шлюзы LLM охватывает конфигурирование Claude Code против него.

Справочник протокола шлюза документирует, что Claude Code ожидает от любого шлюза: конечные точки, которые он вызывает, заголовки и поля тела для пересылки, и что перестаёт работать, когда они удаляются. Работающий Claude apps gateway также служит собственной ссылкой на протокол в GET /protocol, которая описывает конечные точки, которые он предоставляет клиентам Claude Code: вход SSO, вывод, доставка управляемых параметров, обнаружение модели и телеметрия. Получите его с помощью curl https://claude-gateway.internal.example.com/protocol из любого развёрнутого шлюза, такого как тот, который производит быстрый старт ниже.

Критические изменения протокола объявляются заранее, но неопределённая обратная совместимость не гарантируется.

Быстрый старт

Этот быстрый старт проходит минимальный путь: зарегистрируйте клиент OAuth в вашем IdP, напишите gateway.yaml, запустите шлюз вместе с Postgres с помощью Docker Compose и проверьте вход от конца к концу. Он использует вышестоящий уровень Amazon Bedrock; Claude Platform on AWS, Agent Platform Google Cloud, Microsoft Foundry и API Anthropic одинаково поддерживаются путём замены блока upstreams, как показано в справочнике конфигурации. В конце у вас есть шлюз, к которому разработчик может выполнить /login.

Предварительные требования

Имейте это на месте перед началом:

Шаги

listen:
host: 0.0.0.0
port: 8080
# Требуется, если хост не является адресом loopback. Используется для IdP
# redirect_uri и документа обнаружения.
public_url: https://claude-gateway.internal.example.com

oidc:
issuer: https://login.example.com        # должен служить /.well-known/openid-configuration
client_id: 0oa1example2
client_secret: ${OIDC_CLIENT_SECRET}
allowed_email_domains: [example.com]        # отклонять id_tokens вне вашей организации
userinfo_fallback: true                  # для IdPs, чьи id_token опускают email/groups; безвредно в противном случае

session:
jwt_secret: ${GATEWAY_JWT_SECRET}        # openssl rand -base64 32
ttl_hours: 1                             # также ограничивает задержку отзыва при отключении IdP

store:
postgres_url: ${GATEWAY_POSTGRES_URL}    # добавьте ?sslmode=require для управляемого Postgres

upstreams:
- provider: bedrock
region: us-east-1
auth: {} # пусто: цепь учётных данных AWS по умолчанию
# (IRSA, роль задачи EC2/ECS, переменные окружения, ~/.aws)

# Модели переводятся для каждого вышестоящего уровня автоматически. Встроенный каталог
# сопоставляет claude-opus-4-8 с us.anthropic.claude-opus-4-8 и так далее для каждого
# поддерживаемого Bedrock модели Claude. Установите false и добавьте список `models:` для
# раскрытия только определённых моделей.
auto_include_builtin_models: true

services:
gateway:
image: registry.example.com/claude-gateway:2.1.198
ports: ["8080:8080"]
volumes: ["./gateway.yaml:/etc/claude/gateway.yaml:ro"]
environment:
OIDC_CLIENT_SECRET: ${OIDC_CLIENT_SECRET}
GATEWAY_JWT_SECRET: ${GATEWAY_JWT_SECRET}
GATEWAY_POSTGRES_URL: postgres://gw:pw@postgres/gateway
# Учётные данные AWS: в производстве опустите их и используйте роль экземпляра
# вместо этого. Для локального тестирования Compose передайте свои собственные:
AWS_ACCESS_KEY_ID: ${AWS_ACCESS_KEY_ID}
AWS_SECRET_ACCESS_KEY: ${AWS_SECRET_ACCESS_KEY}
AWS_SESSION_TOKEN: ${AWS_SESSION_TOKEN}
depends_on:
postgres:
condition: service_healthy
postgres:
image: postgres:16-alpine
environment: { POSTGRES_USER: gw, POSTGRES_PASSWORD: pw, POSTGRES_DB: gateway }
healthcheck:
test: ["CMD-SHELL", "pg_isready -U gw"]
interval: 5s
volumes: ["pgdata:/var/lib/postgresql/data"]
volumes: { pgdata: }

{"ts":"2026-06-10T17:03:21.114Z","evt":"config.load","path":"/etc/claude/gateway.yaml","sha256":"…"}
[gateway] 2026-06-10T17:03:21.395Z info waiting for migration lock (another replica may be migrating; check pg_locks for key 6775156 if this persists)
[gateway] 2026-06-10T17:03:21.408Z info migration 1 applied
…
[gateway] 2026-06-10T17:03:21.431Z info migration 6 applied
[gateway] 2026-06-10T17:03:21.512Z info claude gateway listening on http://0.0.0.0:8080

curl -s https://claude-gateway.internal.example.com/.well-known/oauth-authorization-server | jq

{
"issuer": "https://claude-gateway.internal.example.com",
"device_authorization_endpoint": "…/oauth/device_authorization",
"token_endpoint": "…/oauth/token",
"grant_types_supported": ["urn:ietf:params:oauth:grant-type:device_code", "refresh_token"]
}

curl -s -X POST https://claude-gateway.internal.example.com/oauth/device_authorization | jq

{
"device_code": "…",
"user_code": "WDJB-MJHT",
"verification_uri": "https://claude-gateway.internal.example.com/device",
"verification_uri_complete": "https://claude-gateway.internal.example.com/device?user_code=WDJB-MJHT",
"expires_in": 600,
"interval": 5
}

Подключение разработчиков

Разработчики подключаются со своих собственных ноутбуков с одним входом в браузер, используя свою корпоративную рабочую учётную запись. Им не нужна учётная запись claude.ai, ключ API или подписка, потому что запросы к модели идут через шлюз, используя учётные данные вышестоящего уровня организации. Подключение управляется управляемыми параметрами на стороне клиента, которые вы отправляете через MDM, поэтому нет ручной настройки на стороне разработчика; этот раздел охватывает то, что настраивает администратор.

CLI отпечатывает сертификат TLS листа шлюза при первом подключении и закрепляет его для каждого имени хоста. Он проверяет этот отпечаток снова при входе, при молчаливом обновлении сеанса и при получении управляемых параметров, в то время как запросы вывода используют стандартную проверку TLS без отпечатка. Запросы, маршрутизируемые через прокси HTTPS, пропускают проверку отпечатка, поэтому добавьте хост шлюза в NO_PROXY, чтобы сохранить их прямыми.

Опубликуйте ожидаемый отпечаток SHA-256 вместе с URL шлюза, чтобы разработчики имели что-то для сравнения. Подсказка /login показывает первые 16 символов отпечатка как строчные шестнадцатеричные без двоеточий. Чтобы вывести полный отпечаток в этой форме из файла сертификата, выполните:

openssl x509 -noout -fingerprint -sha256 -in cert.pem | cut -d= -f2 | tr -d : | tr 'A-F' 'a-f'

Когда сертификат ротируется, каждый разработчик видит подсказку доверия снова, поэтому рассматривайте ротации как запланированное событие и переопубликуйте отпечаток. Если политика вашего шлюза включает параметры, требующие одобрения, разработчик также видит диалог одобрения снова после принятия нового сертификата, потому что Claude Code привязывает память об одобрении к закреплённому сертификату.

Шлюз может возвращать необязательное поле email в своём ответе токена для обозначения учётной записи, которую использовал вход. Когда это происходит, разработчик подтверждает учётную запись перед тем, как Claude Code сохранит учётные данные. После подтверждённого входа /status показывает учётную запись.

Подтверждение требует Claude Code v2.1.275 или позже на машине разработчика; клиент ниже этой версии игнорирует поле. Сервер шлюза в двоичном файле claude не возвращает поле, поэтому его входы завершаются без подтверждения.

После входа разработчика средство выбора модели показывает модели в списке разрешённых availableModels разработчика. Управляемые параметры применяются при запуске и обновляются ежечасно, и телеметрия маршрутизируется в ваш сборщик.

Сеансы молча обновляются перед истечением ttl_hours. Когда обновление не удаётся после отключения IdP, Claude Code запрашивает у разработчика повторный вход.

Установка URL шлюза

Три ключа идут в файл управляемых параметров для каждой ОС, который вы развёртываете через MDM или непосредственно на диск. forceLoginMethod и forceLoginGatewayUrl открывают /login прямо на экране Cloud gateway с заполненным URL, и parentSettingsBehavior: "merge" позволяет Claude Desktop доставлять список разрешённых исходящих соединений шлюза в сеансы Claude Code, которые он запускает, как объяснено в Доставка политики в сеансы Claude Desktop:

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

Разработчик нажимает Enter для подключения. Подсказка отпечатка TLS при первом подключении всё ещё появляется. После того как файл находится на машине, разработчик, который не завершил вход в шлюз, видит одно из сообщений, описанных в Политика администратора требует входа в Cloud gateway. Разработчики, которые выбирают поставщика облака через переменную окружения, такую как CLAUDE_CODE_USE_BEDROCK, не нуждаются во входе в шлюз.

Разработчик не может настроить это вручную. В средстве выбора входа нет опции шлюза, и forceLoginGatewayUrl игнорируется в собственных файлах параметров разработчика. forceLoginMethod один, без URL, оставляет разработчика с сообщением "Свяжитесь с администратором IT". Ключи входа принадлежат файлу, который вы отправляете на машины, а не в блок managed.policies[].cli шлюза, который достигает только уже подключённых клиентов.

Разрешение шлюза на адресном пространстве, которым вы владеете

Некоторые организации нумеруют свою внутреннюю сеть из блока публичного IPv4, которым они владеют, например из собственного адресного пространства оператора или устаревшего /8, поэтому их шлюз не может иметь приватный адрес. Перечислите эти блоки в управляемом параметре gatewayInternalNetworks. /login затем принимает шлюз внутри перечисленного блока, когда машина разработчика подключается к нему с адреса внутри того же блока. Это требует Claude Code v2.1.268 или позже на машине разработчика; более ранние версии игнорируют ключ и применяют правило приватного адреса.

Добавьте ключ в тот же источник управляемых параметров, что и ключи входа: файл управляемых параметров, профиль MDM или политика реестра. Claude Code игнорирует его в пользовательских, проектных и управляемых на сервере параметрах.

Этот пример объявляет один блок. Замените 203.0.113.0/24 на ваш собственный блок. Это диапазон документации, и Claude Code отказывает в нём.

{
  "gatewayInternalNetworks": ["203.0.113.0/24"]
}

Claude Code проверяет список в /login перед тем, как он контактирует с каким-либо шлюзом:

• Каждая запись — это блок IPv4, написанный как его первый адрес и префикс от /8 до /32.
• Список содержит максимум четыре блока, и никакие два не перекрываются.
• Никакой блок не перекрывает приватное адресное пространство: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 127.0.0.0/8, 169.254.0.0/16 и 100.64.0.0/10. /login уже принимает шлюз там без этого ключа.
• Никакой блок не перекрывает пространство, которое никогда не является сетью организации: 198.18.0.0/15 и 192.0.0.0/24, которые VPN и NAT64 клиенты держат как локальные адреса; диапазоны документации 192.0.2.0/24, 198.51.100.0/24 и 203.0.113.0/24; и зарезервированные диапазоны 0.0.0.0/8, 192.88.99.0/24 и мультикаст 224.0.0.0/4. Вы можете объявлять блоки внутри 240.0.0.0/4, которые некоторые крупные сети используют как внутреннее одноадресное пространство.

Блоки из managed-settings.json и его файлов drop-in managed-settings.d/ объединяются в один список, и эти ограничения применяются к объединённому списку. Чтобы сузить блок, замените его запись, а не добавляйте вторую, перекрывающуюся в drop-in; /login отказывает в перекрытии.

Если запись нарушает правило или значение не является списком строк, Claude Code отказывает в каждом новом входе в шлюз на этой машине и называет проблему в сообщении. Вход в шлюз на приватном адресе также не удаётся, и существующие входы продолжают работать. Попробуйте значение на одной машине перед развёртыванием. Claude Code также перечисляет неправильно типизированное значение среди неправильных управляемых параметров, которые он сообщает.

С правильным списком /login применяет три проверки к шлюзу, чей адрес находится внутри перечисленного блока:

• Каждый адрес, на который разрешается имя хоста шлюза, находится внутри того же блока. Claude Code отказывает имени, которое также имеет записи вне него, включая приватные и IPv6 адреса.
• Машина разработчика подключается изнутри того же блока. Claude Code отказывает машине за NAT, внутри контейнера или WSL2, или на VPN, чей пул адресов находится вне блока, и называет адрес, с которого машина подключилась.
• Подключение прямое. Если HTTPS_PROXY применяется к хосту шлюза, /login отказывает и называет запись NO_PROXY для добавления.

Когда все три проходят, подсказка доверия добавляет строку, называющую адрес машины, адрес шлюза и объявленный блок, который содержит оба.

Ключ ничего не меняет для других шлюзов: вход в один на приватном адресе работает как раньше, и вход в один на публичном адресе вне каждого перечисленного блока отказывается как раньше.

Объявленный блок сужает, кто может войти, но не доказывает, где находится машина, поэтому объявляйте только адресное пространство, которым управляет ваша организация. Блок, общий с другими арендаторами, такой как публичный диапазон поставщика облака, позволяет любому в нём пройти ту же проверку.

Доставка политики в сеансы Claude Desktop

Claude Desktop запускает свои вкладки Cowork и Code, а также вкладку Chat, когда вы её включаете, на встроенных сеансах Claude Code и отправляет их запросы модели через шлюз. Он передаёт политику каждому из этих сеансов, построенную из конфигурации, которую шлюз ему предоставляет в /user/bootstrap: список разрешённых моделей, отключённые инструменты и список разрешённых исходящих соединений, полученный из блока cli согласованной политики, плюс наложение desktop.

Другие ключи cli, такие как hooks, env и правила разрешений с областью действия, такие как Bash(npm *), достигают только клиентов, которые входят через /login. Claude Desktop читает URL шлюза из своей собственной управляемой конфигурации и входит со своим собственным потоком, отдельно от ключей forceLoginMethod и forceLoginGatewayUrl в Установка URL шлюза.

Параметры, переданные запускающим процессом, являются родительскими параметрами. Claude Code игнорирует родительские параметры на любой машине, которая имеет развёрнутый администратором управляемый источник, если только источник, который доставляет политику, не устанавливает parentSettingsBehavior: "merge".

Какие машины нуждаются в согласии

Машины, которые только запускают Claude Desktop, нуждаются в нём. Claude Desktop применяет список моделей и список отключённых инструментов к встроенным сеансам сам, но список разрешённых исходящих соединений достигает их только как родительские параметры, в форме правил доменов WebFetch и правил сетевой изоляции. Без согласия эти сеансы работают без ограничения исходящих соединений, и ничто вас не предупредит. Шлюз по-прежнему отклоняет запросы вывода для моделей, которые политика не предоставляет.

Машины, где разработчики входят через /login, не нуждаются в нём; каждый сеанс Claude Code получает свою политику из шлюза.

Флоты, чьи policyHelper предоставляют управляемые параметры, не могут использовать это: Claude Code никогда не объединяет родительские параметры на этих флотах, потому что он читает управляемые параметры только из выходных данных помощника.

Установка согласия

Развёртывайте фрагмент управляемых параметров из Установка URL шлюза, отразите его в любом источнике на стороне клиента, который превосходит файл, затем проверьте.

Ограничение родительских параметров

После развёртывания parentSettingsBehavior: "merge" любой хост-процесс, который запускает Claude Code, может предоставлять родительские параметры, не только Claude Desktop, но также приложение Agent SDK или расширение IDE.

Claude Code фильтрует родительские параметры против списка разрешённых ограничивающих ключей, но некоторые разрешённые ключи могут предоставлять доступ, а не ограничивать его. Если вы не установите блокировки allowManaged*Only, правила разрешения доступа и списки разрешённых изоляции, предоставленные хостом, по-прежнему применяются. Правила отказа и запроса вашей политики остаются в силе в любом случае; они оцениваются перед любым правилом разрешения.

Claude Code пересылает записи sandbox.credentials, предоставленные родителем, в упрощённой форме:

• Записи deny: пересылаются только с их path или name и режимом.
• Записи файлов с mode: mask: пересылаются только как дозорные, как маска всего файла, чей injectHosts является пустым списком, поэтому прокси никогда не подставляет реальное значение для записи, предоставленной родителем, на любой платформе. Все поля структурированного маскирования также отбрасываются, поэтому шаблон извлечения, предоставленный родителем, не может заменить более строгую маску, которую устанавливает другой источник для того же пути.
• Записи envVars с mode: mask: не пересылаются. deny — это единственное ограничение, которое канал родителя может выразить через записи envVars.
• awsPairs и sigv4: пересылаются только ограничения. Из sigv4 сохраняются только значения deny, и родитель, который определяет блок sigv4 вообще, закрепляет все три формы запроса, streaming, presigned и sigv4a, на deny. Пара awsPairs никогда не пересылается в форме, которая может переподписать; пара, которая называет одну из обычных переменных AWS, заменяется инертной записью, которая сохраняет автоматическое спаривание AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY и AWS_SESSION_TOKEN подавленным.

Развёртывание блокировок

Чтобы сохранить родительские параметры как можно ближе к ограничению, как поддерживает фильтр, добавьте все пять блокировок allowManaged*Only и списки разрешённых, которые они управляют, в те же источники, что и согласие на объединение:

{
  "forceLoginMethod": "gateway",
  "forceLoginGatewayUrl": "https://claude-gateway.internal.example.com",
  "parentSettingsBehavior": "merge",
  "allowManagedPermissionRulesOnly": true,
  "allowManagedMcpServersOnly": true,
  "allowManagedHooksOnly": true,
  "allowedMcpServers": [{ "serverUrl": "https://mcp.internal.example.com/*" }],
  "sandbox": {
    "network": {
      "allowManagedDomainsOnly": true,
      "allowedDomains": ["github.com", "*.npmjs.org"]
    },
    "filesystem": {
      "allowManagedReadPathsOnly": true,
      "denyRead": ["~/"],
      "allowRead": ["~/projects"]
    }
  }
}

Политика ОС, такая как политика реестра HKLM или plist управляемых предпочтений, превосходит этот файл, поэтому доставляйте весь фрагмент через неё вместо файла. Удалённые управляемые параметры шлюза превосходят политику ОС и источники файлов, но достигают только подключённых клиентов. Отразите блокировки, списки разрешённых и согласие на объединение в блок cli политики и сохраняйте этот файл развёрнутым, потому что машины, которые никогда не подключаются, включая те, которые только запускают Claude Desktop, получают свою политику только из файла.

Поведение блокировки между источниками

Установка одной блокировки не ограничивает другие; каждый ключ задокументирован в справочнике параметров.

Из источника администратора ниже победителя две блокировки изоляции по-прежнему применяются, и allowManagedPermissionRulesOnly по-прежнему блокирует правила разрешения, предоставленные родителем, и additionalDirectories. На Claude Code v2.1.273 или позже блокировка MCP сервера также применяется из источника ниже победителя, и пока она включена, управляемый список allowedMcpServers поступает из источника администратора с наивысшим приоритетом, который устанавливает один.

Блокировка hooks и эффект allowManagedPermissionRulesOnly на собственные правила разработчика нуждаются в выигрывающем источнике по умолчанию; в соответствии с согласием на объединение managedSourcesBehavior в как Claude Code объединяет управляемые источники, Claude Code применяет самое строгое значение, которое любой источник устанавливает для каждой блокировки. На флотах policyHelper блокировки читаются только из выходных данных помощника.

Каждая блокировка заставляет Claude Code игнорировать собственные записи разработчика для этого параметра, поэтому включите списки разрешённых вашей организации рядом с блокировками:

• Сетевые домены: блокировка с пустым списком управляемых доменов блокирует весь исходящий трафик в изоляции.
• MCP серверы: блокировка без allowedMcpServers в любом источнике администратора или в параметрах, предоставленных родителем, загружает каждый сервер, который deniedMcpServers не блокирует.
• Пути чтения: записи allowRead только повторно разрешают пути внутри регионов denyRead, поэтому спаривайте их с управляемым denyRead.

Параметры, которые блокировки не охватывают

Шесть параметров, предоставленных родителем, проходят фильтр даже со всеми пятью установленными блокировками. В соответствии с параметром первого выигрыша по умолчанию, значение администратора, которое блокирует родителя, находится в источнике администратора с наивысшим приоритетом, кроме allowedMcpServers пока блокировка MCP сервера включена. В соответствии с согласием на объединение managedSourcesBehavior, как Claude Code объединяет управляемые источники говорит, какое значение источника применяется вместо этого.

• forceLoginOrgUUID: Claude Code соблюдает значение, предоставленное родителем, когда источник администратора с наивысшим приоритетом не устанавливает UUID организации. Вход в шлюз не проверяет этот ключ, поэтому он имеет значение только для флотов, которые также используют входы Anthropic первой стороны. UUID организации в источнике администратора с наивысшим приоритетом блокирует значение родителя и является тем, который Claude Code применяет, поэтому установите forceLoginOrgUUID там.
• allowedMcpServers: Claude Code соблюдает список разрешённых, предоставленный родителем, когда источник администратора с наивысшим приоритетом не устанавливает один. allowManagedMcpServersOnly не блокирует его, потому что блокировка применяет список, который выигрывает, как управляемое значение, включая список, предоставленный родителем, когда источник администратора с наивысшим приоритетом не устанавливает один. Список в источнике администратора с наивысшим приоритетом блокирует список родителя и является списком, который Claude Code применяет, поэтому установите allowedMcpServers там, рядом с блокировкой. До v2.1.223 значение для любого ключа в любом источнике администратора блокировало значение родителя.
• availableModels: Claude Code соблюдает список моделей, предоставленный родителем, когда выигрывающий управляемый источник не устанавливает один. Если ваш флот ограничивает модели, установите availableModels в выигрывающем источнике.
• strictKnownMarketplaces: Claude Code соблюдает список разрешённых маркетплейсов плагинов, предоставленный родителем, когда выигрывающий управляемый источник не устанавливает один. Если ваш флот ограничивает маркетплейсы, установите strictKnownMarketplaces в выигрывающем источнике. Требует Claude Code v2.1.282 или позже.
• blockedMarketplaces: список блокировки маркетплейсов, предоставленный родителем, проходит и добавляется к любому списку блокировки, который устанавливает управляемый источник, так как список блокировки может только дополнительно ограничить. Требует Claude Code v2.1.282 или позже.
• strictPluginOnlyCustomization: этот ключ проходит фильтр независимо от любой блокировки, и он заставляет Claude Code игнорировать собственную настройку разработчика, включая защитные hooks. Никакая блокировка не блокирует его.

Подключение Claude Desktop

Claude Desktop подключается к тому же шлюзу через другой ключ MDM: установите bootstrapUrl в управляемой конфигурации Claude Desktop на <listen.public_url>/user/bootstrap, и согласьте политику пользователя с ключом desktop. Наложение Claude Desktop охватывает обе части. Требует Claude Code v2.1.203 или позже на сервере шлюза.

Claude Desktop подписывает разработчика через поставщика идентификации шлюза с тем же шагом SSO браузера, затем получает свою конфигурацию из шлюза вместо Anthropic. Доступ к модели и политика следуют тем же правилам для каждой группы, что и CLI. Разработчик, который использует как CLI, так и Claude Desktop, входит в каждый отдельно; сеанс шлюза не является общим между ними.

После подключения Claude Desktop отправляет запросы модели из каждой включённой вкладки через шлюз. Он показывает вкладки Cowork и Code по умолчанию. Чтобы включить вкладку Chat также, установите chatTabEnabled на true в управляемой конфигурации Claude Desktop, или в блоке desktop политики на шлюзе, работающем Claude Code v2.1.227 или позже.

Конвейеры CI и удалённые машины

Нет потока токена сервиса для автоматических конвейеров. Вход шлюза всегда запускает поток устройства браузера, поэтому задача CI без разработчика для одобрения входа не может аутентифицироваться; настройте их непосредственно против вашего поставщика.

После входа разработчика каждый сеанс Claude Code на этой машине использует сеанс шлюза, включая неинтерактивные запуски claude -p и сеансы, запущенные Agent SDK. Claude Code применяет политику шлюза к каждому из них.

Поток устройства отделяет опрашивающий CLI от одобряющего браузера, поэтому удалённый ящик разработки без дисплея всё ещё работает: разработчик запускает /login по SSH на удалённой машине и открывает ссылку проверки в браузере на своём ноутбуке.

Что применяется к разработчикам

Эти гарантии применяются к каждому сеансу, подписанному через /login. Встроенные сеансы, которые запускает Claude Desktop, получают свою политику, как описано в Доставка политики в сеансы Claude Desktop, и пункт телеметрии говорит, куда идут их экспорты.

• Доступ к модели: запросы для моделей, которые политика не предоставляет, возвращают 400, и средство выбора /model фильтруется в список разрешённых availableModels политики. Установите enforceAvailableModels: true в политике, чтобы опция Default разрешалась в модель внутри availableModels вместо встроенного значения по умолчанию Claude Code; без неё Default остаётся выбираемым и отклоняется во время запроса, если эта модель не предоставлена.
• Назначение телеметрии: в сеансах, подписанных через /login, CLI отправляет свои экспорты OTLP/HTTP в шлюз, а не в локально установленный OTEL_EXPORTER_OTLP_ENDPOINT, если политика не называет ваш сборщик как конечную точку. Шлюз пересылает экспорты, которые он получает, в назначения в telemetry.forward_to.
  • Во встроенных сеансах которые запускает Claude Desktop, CLI отправляет свои экспорты в настроенный OTEL_EXPORTER_OTLP_ENDPOINT. CLI прикрепляет токен сеанса шлюза к этим экспортам только когда эта конечная точка указывает на сам шлюз.
  • Без настроенного назначения для сигнала шлюз принимает и отбрасывает его.
  • Если вы уже собираете телеметрию Claude Code напрямую, добавьте ваш сборщик как назначение forward_to, или назовите его в политике, чтобы пропустить ретрансляцию.
• Учётные данные: токен шлюза — это единственное учётное данные сеанса. Профили Anthropic и любой более ранний вход claude.ai игнорируются при входе, поэтому разработчикам не нужно сначала выходить из claude.ai. Для настроенного ANTHROPIC_API_KEY, ANTHROPIC_AUTH_TOKEN или apiKeyHelper учётного данного см. Политика администратора требует входа в Cloud gateway.
• Управляемые параметры: заблокированные ключи не могут быть переопределены локально. CLI применяет политику при запуске и применяет изменения при каждом ежечасном опросе, кроме изменений, которые применяются только при следующем запуске.
• Запуск с недоступным шлюзом: подписанные сеансы выходят при запуске с ошибкой примерно через 10 секунд, а не запускаются без своих параметров.
• Запуск после завершения сеанса шлюзом: см. Применение отказа при закрытом запуске для запусков, которые открываются без входа в шлюз, и для тех, которые выходят, когда шлюз отвечает с 401.
• Отключение: сеанс, чей пользователь отключён в IdP, истекает в течение ttl_hours, когда следующее обновление не удаётся.
• Выход: /logout удаляет учётные данные шлюза с машины разработчика.
  • Когда документ обнаружения шлюза объявляет revocation_endpoint на собственной схеме, хосте и порту URL шлюза, /logout также отправляет сохранённые токены на эту конечную точку, чтобы шлюз мог завершить сеанс на своей стороне. Запрос является лучшим усилием, поэтому выход завершается на машине разработчика независимо от того, отвечает ли конечная точка. Отзыв требует Claude Code v2.1.275 или позже на машине разработчика.
  • Сервер шлюза в двоичном файле claude не объявляет ни один, поэтому выход из него завершает сеанс на машине разработчика только. Чтобы принудительно завершить сеансы на стороне сервера, см. Ротация секрета JWT.

Что может видеть организация

Телеметрия использования несёт идентификацию разработчика, подсчёт токенов, модель и задержку в сборщик организации. Шлюз не регистрирует и не хранит содержимое подсказки или завершения. Собирается ли более богатая телеметрия, такая как журналы и трассировки, которые могут включать команды и пути файлов, — это выбор организации для каждого назначения.

Доступность и ограничения

Таблица охватывает, какие функции Claude Code работают, когда разработчики подключаются через шлюз, и что сам сервер шлюза поддерживает. Где что-то не поддерживается, столбец Notes даёт альтернативу.

Шлюз доставляет значения anthropic-beta, которые CLI отправляет каждому вышестоящему уровню, поэтому операторы не поддерживают список разрешений бета. Для Amazon Bedrock, который игнорирует заголовок, шлюз перемещает значения в поле anthropic_beta тела запроса; другие вышестоящие уровни получают заголовок как отправленный.

Следующие шаги

Быстрый старт оставляет вас с минимальной конфигурацией, работающей под Docker Compose. Чтобы пойти дальше:

• Расширьте gateway.yaml за пределы минимальной конфигурации, например, чтобы добавить RBAC для каждой группы, многоуровневую отказоустойчивость или назначения телеметрии. Справочник конфигурации охватывает каждый параметр.
• Перейдите от Compose к развёртыванию в производстве на Kubernetes или Cloud Run, правильно настройте ваш IdP и проверьте модель безопасности. Руководство по развёртыванию и операциям охватывает настройку для каждого IdP, требования к образу контейнера, зонды здоровья и устранение неполадок.
• Установите ограничения расходов для отдельных разработчиков или групп, чтобы неконтролируемая рабочая нагрузка не могла потребить всё ваше обязательство. Ограничения расходов охватывает API администратора и как работает применение.
• Для полного отработанного примера на AWS с ECS Fargate или EKS, Amazon RDS и Secrets Manager см. Развёртывание на AWS.
• Для полного отработанного примера на Google Cloud с Cloud Run, Cloud SQL и Secret Manager см. Развёртывание на Google Cloud.