GitHub изменила формат идентификатора в OIDC-токенах GitHub Actions: в него добавили неизменяемые ID владельца и репозитория. Это закрывает риск, когда старые политики доверия в облаке могли «узнавать» не тот проект после переименований и передачи репозитория.
GitHub обновила OIDC-токены, которые GitHub Actions выдает для доступа к облачным сервисам (AWS, Azure, GCP) без долгоживущих секретов. Главная идея — сделать идентификатор в токене устойчивым к ситуациям, когда меняется имя репозитория или организации.
Что именно поменялось
В OIDC-токенах есть поле sub (subject) — по нему облако «понимает», кому доверять. Раньше этот идентификатор часто строился на именах, которые можно изменить: например, включал строку вида repo:org/repo:ref:refs/heads/main.
Теперь GitHub добавляет в стандартный sub неизменяемые идентификаторы владельца и репозитория (ID). В результате subject становится «привязан» не к имени, а к конкретной сущности, даже если проект переименовали, перенесли или позже кто-то занял освободившееся имя.
Почему это важно обычной команде разработки
OIDC в CI/CD — это когда сборка получает краткоживущий токен и обращается к облаку без ключей, лежащих в переменных. Такой подход удобен, но безопасность держится на том, что облачная сторона проверяет: «это действительно тот репозиторий/ветка, которым я доверяю».
Если доверие завязано только на имя, возникает неприятный сценарий: имя организации или репозитория может смениться, а затем быть использовано снова. В теории это способно привести к тому, что новые владельцы смогут выпустить токен с «тем же» subject, и облако примет его как старый доверенный проект — если политика доверия не была обновлена.
Кого коснётся и когда
- Уже сейчас можно включить новый формат для существующих репозиториев через настройки на уровне организации или репозитория.
- С 18 июня 2026 новый формат станет автоматическим для новых репозиториев.
- С 18 июня 2026 переименования и переносы репозиториев также будут переходить на новый формат.
- Существующие репозитории не изменятся сами по себе, если не включать опцию вручную.
- Изменение относится к github.com и не затрагивает GitHub Enterprise Server.
Практические шаги: что проверить, чтобы ничего не «сломалось»
Самый частый риск при таких изменениях — не утечка, а обратная сторона безопасности: сборки внезапно теряют доступ к облаку, потому что политика доверия (например, IAM trust policy) ожидает старый sub.
Чтобы перейти спокойно:
- Найдите, где у вас используются OIDC-токены GitHub Actions (деплой, Terraform, загрузка артефактов, доступ к секретам в облаке).
- Перед включением нового формата подготовьте обновление политик доверия в облаке так, чтобы они принимали новый subject.
- Используйте режим предварительного просмотра subject (preview), чтобы увидеть, как будет выглядеть идентификатор именно для вашего репозитория, и заранее сверить правила доступа.
- Если у вас много репозиториев, планируйте миграцию поэтапно: включайте новую схему сначала на не критичных проектах.
Итог: GitHub делает OIDC-доступ из CI/CD менее хрупким и закрывает класс проблем, связанный с «переиспользованием имен». Для команд это хороший повод инвентаризировать OIDC-интеграции и привести политики доверия в порядок до автоматического включения для новых репозиториев после 18 июня 2026 года.
Источник: GitHub Changelog
