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

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

​

Почему Claude apps gateway

• Учётные данные: ключ 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, с отказоустойчивостью между ними. Вы можете менять регионы, поставщиков или порядок отказоустойчивости без того, чтобы разработчики замечали или переконфигурировали.

​

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

​

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

​

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

​

Шаги

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
}

​

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

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

​

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

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

​

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

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

• Каждая запись — это блок 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, которые некоторые крупные сети используют как внутреннее одноадресное пространство.

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

​

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

​

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

​

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

​

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

• Записи 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 подавленным.

​

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

{
  "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"]
    }
  }
}

​

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

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

​

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

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

​

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

​

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

​

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

• Доступ к модели: запросы для моделей, которые политика не предоставляет, возвращают 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.

​

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

​

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

​

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

• Расширьте 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.