Кратко

  • draft-ietf-wimse-workload-identity-practices-06 описывает короткоживущие учетные данные платформы с узкой аудиторией вместо статических секретов приложения.
  • Валидная подпись сама по себе не подтверждает точный живой экземпляр, исключительное владение ключом, исчезновение старых копий, разрешение операции, ее исполнение или нужный итог.

Полезное улучшение с узкой семантикой

Проект Workload Identity Practices начинает с практической проблемы. Пароли, API keys и OAuth secrets внутри приложения надо распространять и ротировать; похищенный секрет позволяет выдавать себя за workload до его отмены. Платформа может вместо этого наблюдать среду, выдать собственный credential и разрешить обмен на access token для внешнего ресурса.

Kubernetes, SPIFFE, cloud metadata, CI/CD и service mesh реализуют схему по-разному. Общее достижение — отказ от долгого секрета, а не превращение одного token в полное описание реальности.

Datatracker указывает, что revision 06 остается active Internet-Draft с предполагаемым статусом Informational, переданным в IESG и находящимся в “AD Evaluation::Revised I-D Needed”. Это не RFC, не сертификат внедрения и не доказательство результата.

Первое подтверждение: что увидела платформа

До подписи платформа выбирает identity по host, IP, UID, process, kernel metadata, cgroup или orchestrator labels. SPIFFE не требует предварительного секрета: Workload API идентифицирует caller по контексту. Это снимает bootstrap loop, но не делает selector безошибочным. Machine-wide атрибут дает большему числу процессов путь к той же identity, чем привязка к конкретному process и instance.

Bootstrap receipt должен сохранить issuer, наблюдавшиеся attributes, версии attestor и policy, время и решение. Последующая signature не восстанавливает входные данные, которые никто не записал.

Второе подтверждение: какой экземпляр жив

Документация Kubernetes service accounts различает TokenRequest, bound tokens и TokenReview. Kubelet запрашивает tokens по конфигурации Pod и доставляет их containers; claims могут назвать namespace, service account, Pod и node.

Но claims не замораживают cluster. Pod может завершиться, replica с той же account — появиться, policy — измениться. Offline validation подтверждает signature и claims, не текущую жизнь object. Проект прямо говорит, что invalidation после удаления обнаруживается только через TokenReview. Нужен свежий receipt с конкретным instance, lifecycle, scheduling и policy epoch и временем проверки.

Третье подтверждение: выдача и доставка

Верные bytes у issuer не означают загрузку верным consumer. Для file delivery проект рекомендует обновить до отмены старого значения, выполнить atomic replacement и flush. Local API через Unix socket, loopback или link-local endpoint позволяет выдавать и обновлять по запросу. Environment variables статичны и легко попадают в monitoring и debug, поэтому не должны применяться при наличии альтернативы.

Atomic rename исключает половину файла, но не заставляет каждый process перечитать path и не стирает memory copy. API response не доказывает отсутствия SSRF или перехвата privileged component. Receipt доставки связывает channel, instance, credential hash и acknowledgement.

Четвертое подтверждение: владение, а не исключительность

Похищенный bearer token воспроизводится до expiry. Поэтому проект предпочитает proof of possession. X.509 демонстрирует использование private key в handshake; key-bound JWT требует дополнительного доказательства. RFC 8705 определяет OAuth access tokens, привязанные к mTLS certificate.

Это узкий факт конкретного exchange. Он не доказывает, что key никогда не копировали, что им управляет единственный process или что этот process остается исходным workload. Sidecar, node agent или HSM interface могут использовать ключ без export. Exclusive custody проверяется отдельно.

Пятое подтверждение: audience не равна permission

Проект рекомендует отдельный credential для каждого resource или Identity Provider и одну audience для JWT. Token Kubernetes API нельзя повторно использовать во внешней federation. Это уменьшает blast radius.

Но aud определяет допустимого verifier, а не разрешенную операцию. RFC 7521 задает OAuth Assertion Framework, RFC 7523 — JWT Bearer profile. Успешная assertion не отменяет проверки verb, object, parameters, current state и policy.

Ранее BTW рассматривал в Agentic OAuth власть над финальными arguments модели в первой точке эффекта. Эта статья не повторяет ту тему: ее предмет — bootstrap, runtime binding, delivery, possession и invalidation identity chain.

Шестое подтверждение: ротация во всех местах

Короткий lifetime сокращает окно злоупотребления, но не отзывает мгновенно. Выдача нового credential до отмены старого создает намеренный overlap. Application, connection pool, proxy и retry queue могут хранить прежнее значение. Backups, snapshots и images тоже удерживают копии; memory mount снижает риск, но не подтверждает полную очистку.

Issuer должен инвалидировать credential каждого остановленного или удаленного instance и давать status query, однако конкретный механизм вне scope проекта. «Rotated» требует четырех receipts: новая выдача, uptake consumers, rejection либо expiry старого значения, drain известных caches и instances.

Седьмое и восьмое подтверждения: исполнение и итог

Проекты WIMSE об architecture, credentials, HTTP signatures и mutual TLS усиливают части authentication. Ни один не подтверждает application effect.

Resource может проверить issuer, time, audience, type, key и claims и все равно отказать. Он может принять запрос и упасть до commit. Shared proxy может аутентифицироваться за несколько workloads. Effecting service должен подтвердить canonical request, authorization decision, transaction и commit; наблюдатель final state отдельно подтверждает result.

Различие Хэн Лу между реальным и символическим слоями объясняет ошибку: token и success response имеют значение, но реальность — исполненное и наблюдаемое состояние. Минимальная спецификация и локальная верификация вместе с приоритетом работающего кода требуют держать каждое доказательство рядом с системой, способной его проверить.

Надежная цепочка отвечает на восемь разных вопросов: что наблюдала платформа; какой instance связан; что выдано и доставлено; какой key доказан; какая audience и operation разрешены; где старый token перестал работать; исполнен ли request; появился ли expected result.