Trusted publishing и краткоживущие полномочия

Trusted publishing заменяет долгоживущий токен записи отношением доверия между npm и определённым CI-процессом. В этом уроке опишем такое отношение на вымышленной модели, не создавая настройки и не публикуя пакет.

Наша лаборатория «Контур выпуска» имеет private:true и не предназначена для реестра. publisher-contract.fixture.json объясняет механизм и ограничения; это не действующая конфигурация npm. Реального OIDC-токена в архиве нет.

Краткоживущее право и доверенный источник

CI-провайдер может подтвердить идентичность выполняющегося процесса, а реестр сопоставляет её с настроенным trusted publisher. Для принятого отношения используются краткоживущие полномочия выбранной операции. Это уменьшает зависимость от постоянного write-токена в секретах pipeline. Но источник, workflow и разрешённое действие должны совпадать с договором.

В fixture укажем платформу GitLab.com, вымышленные namespace и project, имя верхнего CI-файла и среду. Эти поля не соответствуют настоящему проекту пользователя. В текущей документации поддерживаются определённые облачные runners; self-hosted runner нельзя считать совместимым только из-за наличия OIDC. Для реального выбора читатель должен сверить актуальные ограничения.

Нужно различать публикацию пакета, staged публикацию и управление dist-tags. Текущая настройка описывает отдельные разрешённые действия. Наличие OIDC-аутентификации не означает право на любую команду реестра. В нашей модели область planned_publish_package остаётся договором, а не проверенной способностью. Команда whoami также не заменяет проверку права конкретной операции.

Trusted publishing не предназначен автоматически для установки частных зависимостей. Такой доступ может требовать отдельного read-only механизма. В CI-карте из прошлого урока эти полномочия разделены: чтение и выпуск разные задачи. Нельзя передать write-токен стадии установки только потому, что ему уже нашли удобное место в pipeline.

Опасность компрометации workflow остаётся. Если разрешённый процесс выполняет изменённый вредоносный код, реестр может корректно установить его идентичность. Успешная аутентификация отвечает «это настроенный процесс», а не «этот код полезен». Поэтому нужны ревью workflow, ограничения источника, контроль результата и подходящий процесс принятия. Краткий срок полномочий уменьшает одну область риска, но не отменяет других.

Договор без выдачи полномочий

В нашей модели configured: false, validated: false, operation: not_run. Эти значения намеренно не меняются после написания статьи. Настоящая настройка потребует владения пакетом и авторизации в реестре; пользователь сейчас просит только локальные материалы. Дата просмотра справки не является датой подключения trusted publisher.

Минимальные требования окружения также нужно читать актуально. Справка trusted publishing указывает необходимые версии CLI и Node. В серии зафиксирована документация npm 12.2.0, но среда запуска не проверена. Для последующей практики выбирается совместимая точная версия Node и сохраняется отдельно. Мы не объявляем любой вариант Node 22 автоматически проверенным.

Provenance может генерироваться при определённых условиях публикации, но это отдельный результат. Не следует обещать её для любого провайдера, приватного репозитория или пакета. В текущей справке есть конкретные ограничения. Наша карточка содержит provenance_expectation: needs_conditions_check; следующий урок различит аутентификацию, происхождение и содержание.

Получаем объяснимое отношение доверия и список условий будущей настройки. Никакие полномочия не выданы, внешние аккаунты не изменены. Договор показывает, какие сведения надо проверить прежде, чем превратить модель в рабочий выпуск, и почему автоматическое доверие всем процессам одной организации слишком широко.

Добавьте в собственной карточке владельца пересмотра отношения. Настройки доверия могут пережить переименование проекта, изменение workflow или передачу команды. Точный договор должен оставаться согласованным с действующим процессом. Публичное имя не всегда описывает устойчивую идентичность; текущее руководство также содержит правила валидации настройки. Не имитируйте их успешное прохождение в локальном примере.

Для статического ProfessorWeb этот материал полезен прежде всего как понимание полномочий будущей инфраструктуры. Он не означает необходимость публиковать сайт как npm-пакет. Когда проекту понадобится собственная библиотека компонентов, договор сможет стать основой отдельного авторизованного процесса. До этого он остаётся учебным объяснением конкретного механизма.

Свойство договора	Что не следует из него
Trusted identity	Не подтверждает доброкачественность кода, если разрешённый CI-процесс или его источник скомпрометированы.
Краткий срок	Не отменяет ревью workflow и результата, хотя уменьшает зависимость от постоянного токена записи.
Право публикации	Не является правом установки частных компонентов либо управления всеми операциями реестра автоматически.
Локальный fixture	Не выдаёт никаких реальных полномочий и не подтверждает настройку аккаунтов ProfessorWeb или пользователя.

Проверка ширины отношения доверия

В publisher fixture сначала прочитайте объект назначения: публикация пакета в npm. Затем проверьте источник и workflow. Эти поля не описывают передачу статического сайта на Beget. Смешение двух процессов создало бы лишнюю настройку с полномочиями, которые текущему результату не нужны. Курс использует конкретный механизм как пример узкой области доверия.

Если изменить только имя проекта, отношение может перестать соответствовать действительному источнику. Реальная документация содержит правила проверки и валидации, которые нужно учитывать при настройке. Наша модель не получает статус validated после редактирования JSON. Любая фактическая проверка предполагает соответствующий доступ и выполненную операцию; их в этой подготовке нет.

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

Условия генерации provenance записываются отдельно. Настроенное доверие не доказывает наличие аттестации для конкретного пакета. Провайдер, публичность и способ операции могут менять доступность результата. В нашем договоре это needs_conditions_check. Такое состояние помогает не создавать красивый фиктивный документ происхождения в следующем шаге курса.

Для собственного проекта решение о механизме начинается с назначения выпуска. Если нужен только статический сайт, выбирается соответствующая инфраструктура передачи. Если позже появится собственный пакет компонентов, trusted publishing можно рассмотреть отдельно. Локальный учебный JSON не является разрешением на публикацию ни того, ни другого.

Никакой настоящий токен не нужен для чтения модели. Если в своей практике вы получили секрет, не переносите его в общий архив урока. Сохраните только договор источника, области и состояния, оставляя чувствительные значения в предусмотренном хранилище.

Полный основной артефакт publisher-contract.fixture.json выбранного состояния:

{
  "fictional": true,
  "provider": "GitLab.com shared runner model",
  "namespace": "demo-namespace",
  "project": "demo-contour",
  "top_level_ci_file": ".gitlab-ci.yml",
  "environment": "demo-release",
  "configured": false,
  "validated": false,
  "allowed_operation": "planned_package_publish_only",
  "provenance_expectation": "needs_conditions_check",
  "operation": "not_run",
  "not_site_hosting": true
}

Все исходники серии: папка lesson-08 содержит полный самостоятельный снимок, собственный проект и авторские модели. Исполнение примеров, npm, установки, аудит, тесты, CI, настройки и публикация не выполнялись.

Первичные источники: oidc.