SpyBara
Go Premium

claude-apps-gateway.md 2026-10-03 23:57 UTC to 2026-10-04 21:58 UTC

This page contains 109 additions and 106 deletions.

2026
Sun 4 22:58

Шлюз 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.

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

Дополнительные страницы углубляются в детали. Справочник по конфигурации охватывает каждый параметр в файле 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 и вкладки Chat, Cowork и Code Claude Desktop, подключающихся по HTTPS с токенами-носителями к самостоятельно размещённому Claude apps gateway внутри вашей инфраструктуры, который входит пользователей в ваш IdP, хранит состояние аутентификации в PostgreSQL, передаёт телеметрию вашему сборщику OTLP и пересылает вывод в Amazon Bedrock, Claude Platform on AWS, 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.

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

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

Вам нужно Детали
Claude Code v2.1.195 или позже Подкоманда claude gateway и поток входа шлюза поставляются в v2.1.195. Более ранние общедоступные сборки их не включают. Как машина, запускающая сервер шлюза, так и машина каждого разработчика должны быть на v2.1.195 или позже; запустите claude update, чтобы получить последний выпуск. Claude Platform on AWS upstream требует Claude Code v2.1.198 или позже на сервере шлюза.
Поставщик удостоверений OpenID Connect (OIDC) Okta, Microsoft Entra ID, Google Workspace, Keycloak или Dex, или любой другой совместимый с OIDC IdP, такой как PingFederate. Шлюз запускает стандартное обнаружение OIDC и поток кода авторизации против него. SAML и LDAP не поддерживаются.
PostgreSQL 14 или позже Поддерживает поток входа устройства, где обратный вызов браузера пишет, а опрашивающий CLI читает, плюс счётчики ограничения скорости. Любой управляемый Postgres работает, включая самый маленький уровень. Без настроенных ограничений расходов шлюз хранит несколько КБ краткосрочного состояния аутентификации; с ограничениями расходов он также содержит долговечные таблицы расходов, аудита и идентификации, которые должны быть скопированы. TLS через ?sslmode=require рекомендуется.
Вышестоящий уровень модели Учётные данные Amazon Bedrock, учётные данные Claude Platform on AWS, учётные данные Google Cloud, ресурс Microsoft Foundry или ключ API Anthropic. Поддерживаются несколько вышестоящих уровней с отказоустойчивостью.
HTTPS Шлюз должен быть доступен по https:// с ноутбуков разработчиков и из любого браузера, используемого для входа; шлюз служит страницей проверки устройства на том же слушателе. Либо предоставьте сертификат TLS через listen.tls, либо запустите позади завершающего TLS входа, и установите listen.public_url на внешнее происхождение в обоих случаях. При /login Claude Code принимает простое происхождение http:// только когда хост шлюза является loopback: localhost, 127.0.0.1 или ::1.
Адрес частной сети При /login Claude Code требует, чтобы имя хоста или IP-адрес шлюза разрешались только в частные адреса: RFC 1918, link-local, CGNAT 100.64.0.0/10, IPv6 ULA fc00::/7 или loopback. Для шлюза, который вы размещаете, любой общедоступный адрес вне блока, который вы объявляете, отклоняется; см. модель угроз в руководстве развёртывания. Если машины разработчиков маршрутизируют HTTPS через корпоративный прокси, вход также требует, чтобы хост прокси разрешался в частные адреса; если это не так, добавьте хост шлюза в NO_PROXY, чтобы CLI подключался напрямую. Если ваша внутренняя сеть пронумерована из общедоступного пространства IPv4, которым владеет ваша организация, объявите эти блоки, чтобы /login принял шлюз там.
Среда выполнения Linux Сервер шлюза работает только на собственном двоичном файле Linux. macOS работает для локальной разработки. Windows не поддерживается как платформа сервера.

Шаги

1

Зарегистрируйте клиент OAuth в вашем IdP

Сначала решите имя хоста шлюза, потому что URI перенаправления должен ему соответствовать. Создайте новое веб-приложение OIDC и установите URI перенаправления на https://claude-gateway.<your-domain>/oauth/callback, где хост — это то же значение, которое вы установили как listen.public_url на шаге 3. Запишите client_id и client_secret. Инструкции для каждого IdP находятся в Настройка поставщика удостоверений.

2

Подготовьте базу данных PostgreSQL

Любой Postgres 14 или позже работает, включая самый маленький управляемый уровень. Шлюз запускает свои собственные миграции схемы при загрузке, поэтому пользователю базы данных нужны права для создания и изменения таблиц; см. store.

3

Напишите gateway.yaml

Секреты читаются через расширение ${ENV_VAR}, поэтому сам файл может находиться в системе управления версиями. Используйте имя хоста public_url, которое разрешается в частный IP в вашей сети, потому что /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

Эта конфигурация достаточна для работающего цикла входа с каталогом моделей Bedrock по умолчанию. После того как она запущена, добавьте RBAC для каждой группы и управляемые параметры через managed.policies, телеметрию fan-out через telemetry, и многоуровневую отказоустойчивость, ARN подготовленной пропускной способности или не-US регионы через models.

4

Запустите его

Создайте образ контейнера вокруг двоичного файла claude, который соответствует требованиям образа, затем запустите его вместе с Postgres. Файл Compose ссылается на образ как registry.example.com/claude-gateway:2.1.198; замените свой собственный реестр и тег образа:

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: }

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

Загрузка закрывается для конфигурации, подключения Postgres, обнаружения OIDC и конструкции клиента вышестоящего уровня. Если какой-либо из них недоступен или неправильно настроен, шлюз выходит с ошибкой, а не служит трафику в деградированном состоянии.

Успешная загрузка не проверяет путь вывода, потому что учётные данные экземпляра Bedrock и Agent Platform разрешаются при первом запросе, а не при загрузке.

Смотрите stderr для последовательности загрузки. Строки журнала используют формат [gateway] <timestamp> <level> <message>, события аудита — это однострочный JSON с полем evt, и баннер запуска, опущенный ниже, печатается между строками миграции и прослушивания. Свежая база данных печатает одну строку migration N applied на каждую миграцию схемы; уже перенесённая база данных не печатает ничего. Вы должны увидеть, по порядку:

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

Шлюз также регистрирует предупреждение, что access_control.allow_cidrs пусто. Это ожидается здесь, потому что ничто не ограничивает, какие адреса клиентов обслуживает шлюз, пока вы не установите список разрешений. Справочник access_control содержит рекомендуемые диапазоны.

Если загрузка выходит перед строкой claude gateway listening on, последняя строка stderr называет проблему:

  • недоступный Postgres
  • роль Postgres без разрешения DDL
  • недоступный или недействительный документ обнаружения OIDC
  • нарушение схемы конфигурации с путём нарушающего поля

Исправьте это и перезагрузитесь.

Если у вас уже есть завершающий TLS вход, пропустите Compose и запустите двоичный файл напрямую с помощью claude gateway --config gateway.yaml. Установите public_url на происхождение входа и привяжите listen к адресу loopback или внутри кластера.

5

Проверьте поверхность аутентификации

Три проверки подтверждают, что шлюз может аутентифицировать реального пользователя перед тем, как вы передадите его разработчику.

Примеры используют общедоступный URL шлюза; для локальной установки Compose без входа замените http://localhost:8080 в первых двух проверках. Третья проверка открывает verification_uri_complete, который построен из public_url, поэтому для локального Compose установите public_url: http://localhost:8080 в gateway.yaml и добавьте http://localhost:8080/oauth/callback как второй URI перенаправления на клиент OAuth из шага 1, потому что шлюз строит IdP redirect_uri из public_url. Ссылка проверки затем открывается в вашем локальном браузере.

В Windows PowerShell запустите curl.exe; голый curl — это псевдоним для Invoke-WebRequest и отклоняет эти флаги.

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

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

Ответ включает дополнительные поля, такие как response_types_supported и scopes_supported.

Во-вторых, запросите авторизацию устройства, которая подтверждает, что поток входа устройства работает и Postgres доступен и доступен для записи:

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
}

В-третьих, протестируйте ветку браузера, открыв verification_uri_complete в браузере и подтвердив код. Вы должны быть перенаправлены на страницу входа вашего IdP и после входа приземлиться обратно на шлюз с подтверждением входа.

Используйте первую неудачную проверку для определения проблемы:

  • Первая проверка не удаётся: загрузка не завершена; проверьте stderr
  • Вторая проверка не удаётся: Postgres недоступен из шлюза или роль не может писать; проверьте строку подключения и разрешения
  • Третья проверка не достигает IdP: проверьте, что URI перенаправления IdP точно соответствует https://<gateway>/oauth/callback
  • Третья проверка достигает IdP, но отскакивает с ошибкой: прочитайте журнал аудита шлюза, который записывает каждый отказ в аутентификации с причиной, такой как email domain not allowed
6

Войдите разработчик

Этот последний шаг происходит на машине разработчика, а не на сервере. Установите forceLoginMethod на "gateway" и forceLoginGatewayUrl на public_url вашего шлюза в файле управляемых параметров этой машины, затем запустите /login, нажмите Enter на экране Cloud gateway и завершите вход в браузер. Установка URL шлюза ниже охватывает распределение обоих ключей в масштабе.

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

Разработчики подключаются со своих собственных ноутбуков с помощью одного входа в браузере, используя свою корпоративную рабочую учётную запись. Им не нужна учётная запись 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 при первом подключении по-прежнему появляется. Как только файл оказывается на машине, разработчик, не завершивший вход в шлюз, видит одно из сообщений, описанных в разделе Administrator policy requires a Cloud gateway sign-in. Разработчикам, которые выбирают облачного провайдера через переменную окружения, например CLAUDE_CODE_USE_BEDROCK, вход в шлюз не нужен.

Разработчик не может настроить это вручную. В средстве выбора способа входа нет варианта шлюза, а forceLoginGatewayUrl игнорируется в собственных файлах настроек разработчика. Один forceLoginMethod без URL оставляет разработчика с сообщением "Contact your IT administrator". Ключи входа должны находиться в файле, который вы распространяете на машины, а не в блоке 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 и его дополнительных файлов managed-settings.d/ объединяются в один список, и эти ограничения применяются к объединённому списку. Чтобы сузить блок, замените его запись, а не добавляйте вторую, перекрывающуюся, в дополнительный файл; /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, такие как хуки, env и правила разрешений с ограниченной областью действия вроде Bash(npm *), доходят только до клиентов, которые входят через /login. Claude Desktop читает URL шлюза из своей собственной управляемой конфигурации и выполняет вход по собственной схеме, независимо от ключей forceLoginMethod и forceLoginGatewayUrl из раздела Задание URL шлюза.

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

Каким машинам нужно явное включение

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

Список разрешённых маркетплейсов плагинов также доходит до встроенных сессий только как родительские настройки. Когда вы отключаете добавляемые пользователями маркетплейсы плагинов в управляемой конфигурации Claude Desktop, Claude Desktop 2.16120.0 или новее скрывает маркетплейсы, которые ваша организация не предоставила, и отклоняет установку из них. Чтобы встроенные сессии не загружали плагины, уже установленные из этих маркетплейсов, он отправляет им список strictKnownMarketplaces как родительские настройки. Без явного включения Claude Code игнорирует этот список, и эти плагины продолжают загружаться.

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

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

Явное включение

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

1

Разверните явное включение в файле управляемых настроек

Фрагмент выше уже содержит parentSettingsBehavior: "merge", поэтому файл, который вы распространяете на машины, включает его.

2

Продублируйте фрагмент в любом источнике с приоритетом выше файла

Claude Code читает parentSettingsBehavior только из выбранного источника. Добавление любого ключа политики в источник может сделать этот источник выбранным, поэтому в клиентском источнике дублируйте весь фрагмент, а не только parentSettingsBehavior. Раздел Управляемые настройки на стороне клиента описывает парки машин, которые доставляют политику через Group Policy или профили конфигурации. Plist управляемых предпочтений в macOS или политика HKLM в Windows имеют приоритет над файлом managed-settings.json, а удалённые управляемые настройки самого шлюза имеют приоритет над обоими, поэтому на машинах, которые входят в шлюз, также задайте parentSettingsBehavior в блоке cli политики шлюза.

3

Проверьте, какой источник выбран

На машине, где запускается только Claude Desktop, вызовите resolveSettings() из Agent SDK и прочитайте policyOrigin в записи managed его списка sources. Значение указывает выбранный клиентский источник — plist, hklm или file, — именно он должен содержать фрагмент. Встроенные сессии Claude Desktop не получают политику шлюза, поэтому блок cli шлюза для них никогда не считается выбранным источником.

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

После развёртывания 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 берётся из административного источника с наивысшим приоритетом, в котором он задан.

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

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

  • Сетевые домены: блокировка с пустым управляемым списком доменов блокирует весь исходящий трафик из песочницы.
  • 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 в выигравшем источнике.
  • allowedProviders: Claude Code учитывает список разрешённых API-провайдеров от родителя, если выигравший управляемый источник его не задаёт. Если ваш парк машин ограничивает, какими API-провайдерами могут пользоваться разработчики, задайте allowedProviders в выигравшем источнике. Требуется Claude Code v2.1.285 или новее.
  • strictKnownMarketplaces: Claude Code учитывает список разрешённых маркетплейсов плагинов от родителя, если выигравший управляемый источник его не задаёт. Claude Desktop 2.16120.0 или новее отправляет такой список, когда его управляемая конфигурация отключает добавляемые пользователями маркетплейсы плагинов. Если ваш парк машин ограничивает маркетплейсы, задайте strictKnownMarketplaces в выигравшем источнике. Требуется Claude Code v2.1.282 или новее.
  • blockedMarketplaces: список запрещённых маркетплейсов от родителя проходит фильтр и добавляется к любому списку запрещённых, заданному управляемым источником, поскольку список запрещённых может только усиливать ограничения. Требуется Claude Code v2.1.282 или новее.
  • strictPluginOnlyCustomization: этот ключ проходит фильтр независимо от блокировок и заставляет Claude Code игнорировать собственные настройки разработчика, включая защитные хуки. Ни одна блокировка его не блокирует.

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

Подключение 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 политики. Это относится и к модели, с которой сессия запускается до того, как разработчик выберет модель; см. Запуск сессий на модели, разрешённой политикой.
  • Назначение телеметрии: в сессиях, в которые выполнен вход через /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, а также об API-ключе, сохранённом при более раннем входе в Claude Console, см. Administrator policy requires a Cloud gateway sign-in.
  • Управляемые настройки: заблокированные ключи нельзя переопределить локально. CLI применяет политику при запуске и применяет изменения при каждом ежечасном опросе, за исключением изменений, которые вступают в силу только при следующем запуске.
  • Запуск при недоступном шлюзе: сессии с выполненным входом завершаются при запуске с ошибкой примерно через 10 секунд, а не запускаются без своих настроек.
  • Запуск после того, как шлюз завершил сессию: см. Принудительный запуск с отказом в закрытом режиме, где описаны запуски, которые открываются без входа в шлюз, и те, которые завершаются, когда шлюз отвечает 401.
  • Отзыв доступа: сессия пользователя, отключённого в IdP, истекает в пределах ttl_hours, когда следующее обновление не удаётся.
  • Выход: /logout удаляет учётные данные шлюза с машины разработчика.
    • Если документ обнаружения шлюза объявляет revocation_endpoint с той же схемой, хостом и портом, что и URL шлюза, /logout также отправляет сохранённые токены на этот эндпоинт, чтобы шлюз мог завершить сессию на своей стороне. Запрос выполняется по принципу best effort, поэтому выход на машине разработчика завершается независимо от того, ответит ли эндпоинт. Для отзыва требуется Claude Code v2.1.275 или новее на машине разработчика.
    • Сервер шлюза в бинарном файле claude такой эндпоинт не объявляет, поэтому выход из него завершает сессию только на машине разработчика. Чтобы принудительно завершить сессии на стороне сервера, см. Ротация секрета JWT.

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

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

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

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

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

Функция Статус Примечания
Пересылка вывода (Amazon Bedrock, Claude Platform on AWS, Google Cloud's Agent Platform, Microsoft Foundry, Anthropic) Доступно С переводом модели для каждого вышестоящего уровня и отказоустойчивостью. Вышестоящий уровень Amazon Bedrock использует эндпоинт bedrock-runtime и цепь учётных данных AWS по умолчанию. Вышестоящий уровень Amazon Bedrock Mantle требует Claude Code v2.1.283 или более поздней версии на сервере шлюза, а вышестоящий уровень Claude Platform on AWS требует v2.1.198 или более поздней версии.
Доступ к модели и управляемые настройки по группе IdP Доступно Доступ к модели применяется на стороне сервера; управляемые настройки доставляются для каждой группы IdP и применяются CLI на уровне управляемых настроек
Claude Desktop Доступно с согласия Шлюз обслуживает конфигурацию Claude Desktop по адресу /user/bootstrap после того, как политика согласится с ключом desktop, и Claude Desktop отправляет запросы модели из своих вкладок Cowork и Code, а также из вкладки Chat, когда вы её включите, через шлюз. Чтобы включить вкладку Chat, см. Подключение Claude Desktop. Требует Claude Code v2.1.203 или более поздней версии на сервере шлюза.
Телеметрия fan-out (OTLP/HTTP) Доступно Идентификация-отмечена для каждого экспорта; оба кодирования protobuf и JSON
Поставщики идентификации OIDC Доступно Любой совместимый с OIDC IdP; шлюз запускает стандартное обнаружение OIDC и поток авторизации-кода. См. Настройка поставщика идентификации для конфигурации для каждого IdP
Ограничения расходов для каждого пользователя и группы Доступно См. Ограничения расходов
Веб-поиск на стороне сервера Недоступно CLI не может видеть, какого поставщика вышестоящего уровня маршрутизирует шлюз, поэтому он не может проверить поддержку веб-поиска и отключает WebSearch в сессиях шлюза
Remote Control Недоступно CLI показывает ошибку, называющую шлюз
/design-sync и /design-login Недоступно Обе нуждаются в claude.ai, к которому CLI не обращается в сессиях шлюза, поэтому ни одна команда там не появляется
Функции, которые нуждаются в получении флага функции, такие как /import и claude import Недоступно CLI пропускает получение флага в сессиях шлюза. Функции, которые нуждаются в получении флага функции перечисляет, что это отключает
Стандартное кэширование промптов Доступно Шлюз пересылает точки разрыва cache_control каждому вышестоящему уровню. Где живёт кэш охватывает, какие блоки CLI отмечает, включая системный контекст, который он добавляет в середине разговора
TTL кэша 1 час Недоступно CLI опускает бета-версию extended-cache-ttl в сессиях шлюза, потому что не каждый вышестоящий уровень, который может маршрутизировать шлюз, поддерживает TTL 1 час, поэтому кэширование промптов через шлюз использует TTL 5 минут; см. примечание выше о бета-заголовке
Авторежим Доступно Следует правилам поставщика третьей стороны: только модели, имеющие право на поставщиков третьей стороны, могут его использовать. До версии v2.1.207 авторежим в сессиях шлюза требовал установки CLAUDE_CODE_ENABLE_AUTO_MODE=1, доставляемой через блок env управляемой политики
Оптимизации только первой стороны, такие как глобальная область действия кэша и инструменты, эффективные по токенам Недоступно CLI не включает их в сессиях шлюза; см. примечание выше о бета-заголовке
OTLP/gRPC Не поддерживается Только OTLP по HTTP
SAML, LDAP и другая аутентификация не-OIDC Не поддерживается Только OIDC. Фронт с мостом OIDC, если необходимо
Мультитенантность (несколько издателей OIDC) Не поддерживается Один издатель на шлюз. Запустите отдельные экземпляры
Сервер Windows Не поддерживается Развёртывайте на Linux. macOS только для локальной разработки
Helm chart Недоступно Шлюз работает как стандартное развёртывание без состояния; см. руководство по развёртыванию
Пользовательский интерфейс администратора Недоступно Конфигурация — это файл YAML; переразвёртывайте, чтобы изменить его

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

Быстрый старт оставляет вас с минимальной конфигурацией, работающей под 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.