Настройка Claude Code Workload Identity Federation через OIDC

Если ваша инфраструктура по-прежнему аутентифицируется в Claude API с помощью долгоживущего ключа sk-ant-..., хранящегося в менеджере секретов, Anthropic теперь предоставляет механизм для полного устранения этого риска. Anthropic Claude workload identity federation (WIF) позволяет любой рабочей нагрузке с поддержкой OIDC — GitHub Actions runner'у, Kubernetes-поду, AWS Lambda-функции — обменять свой облачный идентификационный токен на краткосрочный токен доступа Anthropic во время выполнения. Нет статических секретов для хранения, ротации или утечки, и каждый вызов API привязан к именованному сервисному аккаунту в вашей организации.

Если вы ищете, как настроить workload identity federation для Claude Code, Claude Code Action или routing gateway, практический путь такой: создать Anthropic service account, зарегистрировать OIDC issuer рабочей нагрузки, связать claims через federation rule и запускать Claude clients с WIF-переменными окружения вместо ANTHROPIC_API_KEY.

Для команд маршрутизации это важно не только потому, что меняется способ аутентификации в Claude, но и потому, что меняется способ хранения и инъекции учётных данных в вашем gateway или proxy-слое для нисходящих вызовов Claude API.

Как настроить Claude Code workload identity federation

Самый короткий путь настройки — мастер Claude Console Settings → Workload identity → Connect workload. Он подходит для Claude Code Action в GitHub Actions, Claude Code agents в Kubernetes или gateway, который вызывает Claude от имени разработчиков:

1. Создайте или выберите Anthropic service account. Это нечеловеческий principal, от имени которого будет действовать Claude Code или gateway. Добавьте его в целевой workspace до тестирования token exchange.
2. Зарегистрируйте OIDC issuer рабочей нагрузки. Для Claude Code Action это GitHub Actions (https://token.actions.githubusercontent.com). Для Kubernetes используйте cluster service-account issuer. Для AWS, Google Cloud, Entra ID, Okta или SPIFFE выберите соответствующий provider tile или Custom OIDC.
3. Ограничьте federation rule. Матчите конкретный GitHub repository/ref, Kubernetes namespace/service account или cloud workload identity. Не используйте широкий subject_prefix, который позволит несвязанным jobs выпускать Claude tokens.
4. Настройте OAuth scope и lifetime. Для inference обычно нужен workspace:developer. MCP tunnel management требует org:manage_tunnels, поэтому не переиспользуйте ту же rule без проверки. Начните с 600–3600 секунд lifetime и корректируйте после load testing.
5. Инжектируйте WIF-переменные во время запуска. Настройте ANTHROPIC_FEDERATION_RULE_ID, ANTHROPIC_ORGANIZATION_ID, ANTHROPIC_SERVICE_ACCOUNT_ID, ANTHROPIC_WORKSPACE_ID и ANTHROPIC_IDENTITY_TOKEN_FILE. Затем создавайте SDK client без api_key.
6. Проверьте из реальной рабочей нагрузки. Запустите Claude Code Action, CI job, pod или gateway deployment в тестовом окне мастера. Exchange должен пройти из настоящего identity provider, а не только из локального shell.

Если вы настраиваете именно Claude Code Action, главный риск — доверить все GitHub Actions tokens организации. Привяжите rule к конкретному repository, политике branch/tag, environment и workflow claims, которые действительно должны иметь доступ.

Что произошло

Anthropic опубликовал полную документацию по workload identity federation в Claude Console в разделе Settings → Workload identity. Функция использует модель из трёх ресурсов, аналогичную паттерну GCP Workload Identity Federation и AWS IRSA:

Сервисные аккаунты (svac_...) — нечеловеческие идентификаторы внутри вашей организации Anthropic. У сервисного аккаунта нет электронной почты, пароля и доступа к Console. Он активируется в рабочем пространстве при добавлении в качестве участника; при обмене токеном Anthropic создаёт краткосрочный токен, ограниченный лимитами скорости и атрибуцией использования этого рабочего пространства.

Федеративные провайдеры (fdis_...) — зарегистрированные OIDC-провайдеры идентификации. Вы регистрируете по одному провайдеру на среду (продакшн-кластер EKS, стейджинг-кластер, GitHub Actions — три отдельных провайдера). Запись провайдера сопоставляет значение iss claim с JWKS-источником для проверки подписи JWT.

Федеративные правила (fdrl_...) — связующее звено: «JWT от провайдера X с claims, соответствующими Y, могут действовать как сервисный аккаунт Z». Правила определяют условия сопоставления (subject_prefix, audience, точные значения claims или CEL-выражение), целевой сервисный аккаунт, OAuth scope (по умолчанию workspace:developer) и время жизни токена (60–86400 секунд, по умолчанию 3600).

Процесс обмена следует стандарту RFC 7523 jwt-bearer: рабочая нагрузка отправляет JWT, выданный IdP, на POST /v1/oauth/token вместе с идентификатором федеративного правила, org ID, service account ID и workspace ID. Anthropic возвращает токен доступа ***-.... SDK Anthropic обрабатывает обмен и автоматическое обновление; код приложения создаёт клиент без аргумента api_key и вызывает API как обычно.

Поддерживаемые провайдеры из коробки: AWS IAM, Google Cloud, GitHub Actions, Kubernetes service account issuer, SPIFFE, Microsoft Entra ID и Okta. Для изолированных кластеров доступны режимы explicit_url или inline JWKS.

Значение для AI-инженерных команд

Статические API-ключи — самый большой нерешённый риск в области учётных данных в большинстве AI-стеков. Ключ sk-ant-... обычно хранится как переменная окружения, Kubernetes Secret или CI-секрет и никогда не истекает. В случае утечки — через git commit, строку лога, инспекцию образа контейнера или скомпрометированный артефакт сборки — атакующий получает неограниченный доступ до ручной ротации. Workload identity federation полностью устраняет этот класс риска для рабочих нагрузок с существующей OIDC-идентификацией.

Управление временем жизни токена обеспечивает ограниченный по времени и скоупированный доступ. По умолчанию 3600 секунд означает, что скомпрометированный токен действителен максимум один час. Для коротких CI-задач можно снизить до 60 секунд. Для долгоживущих агентных рабочих процессов SDK автоматически выполняет повторный обмен до истечения срока.

Сервисные аккаунты делают вызовы API аудируемыми. Сегодня большинство команд привязывают вызовы Claude API к единому ключу, что затрудняет ответ на вопрос «какое развёртывание сгенерировало эти потреблённые токены в прошлый вторник?». С сервисными аккаунтами каждая рабочая нагрузка сопоставлена с именованным principal. В сочетании с лимитами скорости на уровне workspace это даёт ту же детализацию атрибуции, что и AWS IAM-роли.

CEL-условия позволяют создавать тонкие правила доступа. Если Kubernetes-кластер обслуживает и продакшн, и стейджинг, можно создать отдельные правила с CEL-выражениями, сопоставляющими namespace-метки, claims окружения или конкретные имена сервисных аккаунтов — каждое маппится на отдельный сервисный аккаунт Anthropic с разными рабочими пространствами.

С точки зрения роутера/оператора

Для команд, маршрутизирующих трафик Claude через gateway или proxy-слой, workload identity federation меняет модель учётных данных конкретным образом, который стоит спланировать уже сейчас.

Ваш gateway — главный кандидат для внедрения WIF. Маршрутизирующий gateway совершает исходящие вызовы Claude API от имени множества клиентов. Сегодня он обычно хранит статический ключ sk-ant-... и инжектирует его в пересылаемые запросы. Если gateway работает на AWS, GCP или Azure, у него уже есть OIDC-идентификатор (IAM-роль, сервисный аккаунт или managed identity). Вы можете зарегистрировать его как WIF issuer, создать сервисный аккаунт для gateway, настроить федеративное правило и сконфигурировать SDK через переменные окружения:

export ANTHROPIC_FEDERATION_RULE_ID="fdrl_..."
export ANTHROPIC_ORGANIZATION_ID="00000000-0000-0000-0000-000000000000"
export ANTHROPIC_SERVICE_ACCOUNT_ID="svac_..."
export ANTHROPIC_WORKSPACE_ID="wrkspc_..."
export ANTHROPIC_IDENTITY_TOKEN_FILE="/var/run/secrets/anthropic.com/token"

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

Workspace-скоупинг делает изоляцию команд примитивом учётных данных, а не просто меткой маршрутизации. Если вы запускаете отдельные workspace Anthropic для разных команд или центров затрат, WIF позволяет создать отдельные сервисные аккаунты для каждого workspace и отдельные федеративные правила для каждого развёртывания. Запрос, маршрутизируемый в workspace team-a, использует токен сервисного аккаунта team-a; запрос в workspace team-b использует токен team-b. Лимиты скорости, атрибуция использования и контроль доступа следуют за workspace, а не только за меткой маршрутизации в конфигурации gateway.

Интеграция с MCP tunnel требует специфического scope. Если вы используете Claude Code или других агентов через MCP tunnel, туннельный поток создаёт федеративные правила со scope org:manage_tunnels, а не workspace:developer. При построении слоя маршрутизации, проксирующего как инференс, так и вызовы управления туннелями, необходимы отдельные федеративные правила (и, возможно, отдельные сервисные аккаунты) для каждого scope.

Задержка обмена токенами — единственная операционная стоимость для моделирования. Каждый обмен WIF — это HTTP-запрос на POST /v1/oauth/token. При времени жизни 3600 секунд SDK кэширует и автоматически обновляет токен, поэтому накладные расходы амортизируются на тысячи запросов на токен. Для gateway с высокой пропускной способностью стоимость пренебрежимо мала. Для gateway с очень короткими пакетами запросов или cold-start путями учтите задержку обмена при планировании ёмкости.

Чек-лист миграции для операторов Anthropic WIF:

1. Определите рабочие нагрузки с существующими OIDC-идентификаторами. Проверьте gateway, CI/CD-пайплайны и развёртывания Claude Code на наличие AWS IAM-ролей, GCP-сервисных аккаунтов, GitHub Actions OIDC или Kubernetes projected tokens.

2. Зарегистрируйте по одному провайдеру на среду. Создайте отдельные записи fdis_... для продакшна, стейджинга и CI. Это предотвращает создание токенов для продакшн-рабочего пространства с помощью стейджинг-учётных данных.

3. Сопоставьте по одному сервисному аккаунту на команду или центр затрат. Добавьте каждый сервисный аккаунт в соответствующее рабочее пространство Anthropic. Лимиты скорости и атрибуция использования следуют автоматически.

4. Используйте CEL-условия для общих провайдеров. Если единый Kubernetes-кластер обслуживает несколько команд, применяйте CEL-выражения с condition для сопоставления по namespace или меткам, а не широкому subject_prefix.

5. Обновите конфигурацию SDK в gateway. Замените api_key=os.environ["ANTHROPIC_API_KEY"] на конструктор без аргументов и инжектируйте ANTHROPIC_FEDERATION_RULE_ID и связанные переменные окружения для каждой среды.

6. Протестируйте время жизни токена под нагрузкой. Начните с token_lifetime_seconds равного 3600. Для высокопроизводительных gateway убедитесь, что тайминг обновления SDK не создаёт contention при конкурентности, прежде чем снижать время жизни.

7. Отдельно проверьте MCP tunnel scope. Если развёртывание включает MCP tunnel, убедитесь, что федеративное правило туннеля использует scope org:manage_tunnels и маппится на сервисный аккаунт с членством на уровне организации, а не только workspace.

Что пользователям TheRouter следует отслеживать

Модель workload identity federation наиболее применима для команд, запускающих Claude Code или агентные рабочие процессы на базе Claude через маршрутизационный слой. Если ваше развёртывание работает в облачной среде с существующей OIDC-идентификацией, вы можете исключить хранимый статический ключ sk-ant-... из конфигурации маршрутизации AI provider и заменить его потоком обмена токенами через паттерн конструктора SDK без аргументов.

Для команд, использующих мульти-провайдерную маршрутизацию между OpenAI и Anthropic, стоит отметить, что оба провайдера теперь поддерживают безключевую аутентификацию на основе OIDC, но реализации различаются. OpenAI использует собственный workload identity federation на уровне организации; Anthropic использует сервисные аккаунты + федеративные правила с CEL-условиями и workspace-скоупингом. Команды, управляющие обоими провайдерами в одном gateway, нуждаются в отдельных конфигурациях федерации для каждого провайдера.

Документация Anthropic Claude Console в Settings → Workload identity является авторитетным руководством по настройке. Следите за Anthropic changelog за обновлениями OAuth scope, новыми предустановленными провайдерами идентификации и изменениями ограничений времени жизни токенов по мере созревания функции.