Кратко

  • Редакция 07 запрещает JWT иметь более одной аудитории, кроме случаев, когда невозможно получить несколько учётных данных или влиять на audience; в редакции 06 единственная аудитория была рекомендацией SHOULD.
  • Механизм риска — выдача себя за рабочую нагрузку одним получателем перед другим: всякий, кто получил общий bearer-токен, может предъявить его другой принимающей стороне.
  • В квитанции исключения по возможностям следует фиксировать причину, граф получателей, срок и зону доступа, проверки, компенсации, дату пересмотра и условие выхода.

Pod предъявляет projected service-account token API-серверу Kubernetes, а затем использует тот же токен для федерации с внешним провайдером идентификации. Оба адресата легитимны. Но оба теперь владеют одним bearer-токеном. Если aud допускает оба применения, внешний провайдер может предъявить его API-серверу и представиться рабочей нагрузкой.

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

Именно это делает явным draft-ietf-wimse-workload-identity-practices-07, загруженный 22 сентября 2026 года. Документ остаётся активным Internet-Draft с предполагаемым статусом Informational. Datatracker показывает AD Evaluation::AD Followup, ответственным указан Charles Eckel. Это стадия рассмотрения, а не одобрение, RFC, свидетельство внедрения или вывод о нарушении со стороны конкретной платформы.

От рекомендации к обязательному исходному состоянию

Редакция 06 уже советовала максимально сужать учётные данные и, если платформа умеет выдавать несколько, получать отдельные для каждого ресурса или провайдера идентификации. В разделе об аудитории говорилось, что JWT следует иметь только одну аудиторию.

Редакция 07 меняет исходное правило. Учётные данные MUST быть сужены насколько возможно. Данные для доступа к ресурсу платформы MUST относиться к этому ресурсу. Данные для федерации MUST иметь единственной аудиторией провайдера идентификации. За пределами исключения JWT MUST NOT содержать более одной аудитории.

Это не косметическая замена регистра. SHOULD допускает обоснованный иной путь; MUST делает разделение нормой и требует объяснить исключение. В тексте добавлен и механизм: любая relying party из одного aud может предъявить токен другой стороне из того же списка и получить непредусмотренный доступ.

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

Общая граница для Kubernetes, SPIFFE и облака

Kubernetes может выпускать несколько projected tokens с отдельными audience и сроками. Редакция 07 разделяет API-сервер, внутренний ресурс и внешний провайдер идентификации: требуются разные токены с разными аудиториями.

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

В примере SPIFFE JWT-SVID для внутреннего ресурса и JWT-SVID для внешней федерации также должны различаться. В облачном сценарии редакция 06 использовала SHOULD/SHOULD NOT для разделения внутреннего доступа и внешнего STS, а редакция 07 — MUST/MUST NOT. Меняется платформа, но не вопрос о том, кто получает одни учётные данные.

Исключение фиксирует дефицит возможности

Некоторые платформы выдают только одни учётные данные на нагрузку; другие не позволяют ей влиять на audience. В этих случаях редакция 07 допускает отступление от правила.

Это не удобный обход. Такой контур не может полагаться на audience scoping для ограничения ущерба. Он должен использовать минимальный доступный срок, ограничить компоненты с доступом и считать каждого получателя способным выдать себя за нагрузку перед всеми остальными.

Защита переносится с криптографического разделения на время, доступ компонентов, сеть, дисциплину проверки и обнаружение. Это компенсация, а не эквивалентность. Аналогично при отсутствии proof of possession короткие сроки, более узкая аудитория и дополнительные сетевые меры становятся обязательными. Короткая жизнь не превращает bearer-токен в привязанный к отправителю.

Квитанция исключения по возможностям

Минимальная запись должна содержать:

Поле Сохраняемое свидетельство
Возможность эмитента Платформа, issuer, точная версия, возможность нескольких учётных данных
Управление audience Может ли нагрузка запросить или изменить aud, с данными API или настройки
Назначение API платформы, внутренний ресурс, федерация или внешний ресурс
Идентичность данных Несекретный односторонний отпечаток или поколение, не значение токена
Граф получателей Все принимающие стороны и пути повторного предъявления
Срок Запрошенный и выданный TTL, продление, отзыв или инвалидизация
Зона доступа Компоненты, mounts, sidecars, прокси, журналы и исходящие пути
Проверка Issuer, audience, тип, PoP и сетевые условия у каждого получателя
Причина исключения Недостающая возможность и причина невозможности разделения
Компенсация Короткий срок, ограничение доступа, сеть, мониторинг и оповещение
Пересмотр Владелец, время решения, следующая дата, триггер исправления и выход

Отпечаток должен быть несекретным и необратимым. Квитанция не оправдывает сохранение bearer-токена в заявке. Она связывает решение о риске с конкретным поколением, получателями и действовавшими мерами.

Важно различать «невозможно» и «не сделали». Если эмитент умеет выпускать отдельные данные, а интеграция переиспользует их ради простоты, исключение неприменимо. Если новая версия добавила управление audience, условие выхода наступило. Исключение без срока пересмотра незаметно становится постоянной архитектурой.

Предыдущая статья BTW A Workload Credential Is Not the Workload рассматривала восемь доказательств от bootstrap до результата. Здесь вопрос уже: у каких получателей этот bearer-токен может говорить от имени нагрузки и кому они могут предъявить его снова?

Источники и пределы

Основные источники — карточка редакции 07, история документа, неизменяемый текст редакции 07 и текст редакции 06. Различие между координационным артефактом и эксплуатационной реальностью следует подходу Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption.

Источники подтверждают состояние документа, нормативные формулировки и механизм риска. Они не подтверждают реальный инцидент, полный перечень реализаций или нарушение конкретного оператора. Квитанция — редакционное предложение Daniel Kade, а не требование проекта WIMSE.