Кратко

  • id-token: write позволяет job или workflow GitHub Actions запросить OIDC JSON Web Token; GitHub отдельно указывает, что эта настройка сама по себе не даёт права записи во внешние ресурсы.
  • Облачный провайдер отдельно оценивает настроенные условия доверия и может обменять JWT на краткоживущий токен доступа. Последующее решение самого ресурса — ещё одна поверхность контроля.
  • Обоснованное утверждение об облачной авторизации связывает ревизию workflow и ограниченный набор claims, ревизию политики доверия, запись об обмене и сессии, контекст эффективных разрешений, решение ресурса и наблюдение целевой среды, выполненное в другое время.

Фраза «у этого конвейера есть облачный доступ через OIDC» может быть полезным кратким описанием реализации. Она становится вводящей в заблуждение, когда сжимает несколько решений разных владельцев в один вывод. GitHub Actions может выдать токен идентичности OpenID Connect job, которой разрешено его запросить. Облачный провайдер можно настроить так, чтобы он доверял издателю GitHub и проверял выбранный набор claims. Успешный обмен может выдать этой job краткоживущее облачное удостоверение.

Затем облачный сервис всё равно оценивает конкретный запрос с учётом роли, политики ресурса, границы разрешений, политики сессии, организационного контроля, контекста запроса и требуемого действия. У каждого звена свой участник, момент времени и место, где остаётся доказательство.

GitHub ясно проводит первую границу. id-token: write позволяет workflow запросить и использовать OIDC JWT; из этого не следует право изменять другие ресурсы. Поэтому обнаруженная при проверке релиза настройка не должна превращаться в описание конечного привилегированного доступа. Проверяющему известно лишь узкое обстоятельство: job имела право запросить токен идентичности GitHub. Из этого не следует, что запрос был выполнен, какая audience была запрошена, какие claims вернулись, доверяла ли им облачная сторона или принял ли облачный ресурс последующее действие.

Доверительные отношения с облаком — отдельная конфигурация и отдельное решение. В руководстве GitHub для облачных провайдеров сказано, что провайдер проверяет claims токена и при успехе предоставляет job токен доступа. Именно политика провайдера превращает subject, audience, идентичность репозитория, ссылку на повторно используемый workflow или иной доступный claim в условие допуска. Токен может быть корректно сформирован, но отвергнут условием доверия. Условие может оказаться слишком широким, а ожидаемый claim — отсутствовать или изменить формат. Облачный токен может быть выдан с областью прав уже, чем предполагает владелец релиза.

И наоборот, политика ресурса может отклонить действие после успешного федеративного обмена.

Пример AWS делает это разделение наглядным. Руководство GitHub для AWS описывает настройку доверительных отношений AWS и рекомендует оценивать ключ условия OIDC sub в политике доверия роли. Наличие claim sub от GitHub не является записью о существовании сессии роли AWS. Существование сессии роли, в свою очередь, не является записью обо всех разрешениях, которые были эффективны в контексте определённого запроса. Политика роли, граница разрешений, политика сессии, ограничение уровня организации, политика ресурса и явный запрет могут сформировать конкретное решение. Этот материал не проверяет ни одну учётную запись AWS; он показывает, почему общее утверждение «OIDC авторизовал развёртывание» оставляет слишком многое неуточнённым.

Повторно используемые workflows дают ещё одну причину сохранять реальные связи. GitHub документирует, что токен job внутри повторно используемого workflow содержит обычные сведения о job и может содержать job_workflow_ref; поддержка пользовательских claims различается у облачных провайдеров. Наличие имени workflow в репозитории не доказывает, что доверяющий провайдер проверил это поле. Вызывающая сторона может быть известна GitHub, но не присутствовать в claim, который способно оценить условие облачного доверия. Поздняя настройка claims subject также может изменить формат, ожидаемый провайдером. Это факты конфигурации, которые следует сохранить, а не пробелы, которые закрывает успокаивающее слово «федерация».

Отсюда следует семичастная квитанция об облачной авторизации. Сохраните точную ревизию workflow, запускающий ref, идентичность job и контекст id-token: write. Сохраните ограниченную запись запрошенной audience и полученных claims, не раскрывая пригодный для использования токен. Сохраните версию облачного провайдера идентичности и политики доверия, действовавшую в тот момент. Сохраните результат обмена, идентичность роли или сессии и срок её действия. Сохраните относящийся к предполагаемому действию контекст эффективных разрешений. Сохраните решение ресурса и запись запроса. Наконец, сохраните отдельное по времени наблюдение целевой среды. Имена учётных записей, идентификаторы ресурсов и значения могут остаться защищёнными; задача не в публикации удостоверений, а в сохранении связей между решениями.

Источники

  1. GitHub Docs — Настройка OpenID Connect у облачных провайдеров
  2. GitHub Docs — Справочник OpenID Connect
  3. GitHub Docs — Настройка OpenID Connect в Amazon Web Services
  4. GitHub Docs — Использование OpenID Connect с повторно используемыми workflows