Docker добавил OIDC-подключения для GitHub Actions при работе с Docker Hub. Для CI/CD это практичная новость: вместо постоянных токенов вроде PAT и OAT теперь можно использовать короткоживущие учетные данные, которые выдаются под конкретный запуск workflow.
Иными словами, секретов в репозитории и в настройках GitHub станет меньше, а цена одной утечки заметно падает.
Постоянные токены были слабым местом
Раньше GitHub Actions обычно логинились в Docker Hub через Personal Access Token или Organization Access Token. Схема рабочая, но не идеальная: такой токен может жить долго, его нужно ротировать, а при утечке злоумышленник получает вполне реальный доступ к реестру.
Docker переводит этот сценарий на OIDC-модель: GitHub выдает workflow подписанный ID-токен, Docker проверяет его и в ответ отдает временный токен доступа. Это снижает зависимость от «вечных» секретов, которые команды часто годами боятся трогать.
Как устроен обмен токенами
Сценарий состоит из двух шагов. Сначала в Docker Home администратор создает OIDC connection и настраивает rulesets и subject claims. Затем в GitHub Actions workflow запрашивает право id-token: write, вызывает docker/oidc-action@v1 и получает временный токен, который передается в docker/login-action@v4.
Есть важное ограничение: функция рассчитана на организации в Docker, а не на личные аккаунты. В документации Docker также прямо сказано, что OIDC-подключения не заменяют OAT полностью, а закрывают именно сценарий аутентификации GitHub Actions.
Что это меняет для команд разработки
Для команд из России и СНГ смысл очень приземленный: меньше ручного управления секретами, проще аудит CI/CD и ниже риск, что старый токен останется жить после увольнения сотрудника или миграции проекта. Особенно полезно это для компаний, где один Docker Hub namespace обслуживает несколько репозиториев и несколько команд.
На практике Docker догоняет подход, который давно стал нормой у облачных провайдеров и корпоративных платформ: доступ выдается не человеку «навсегда», а конкретному процессу и на короткое время. Для DevOps и платформенных инженеров это не революция, но хороший апгрейд базовой гигиены.
Следующий логичный шаг для Docker — расширять OIDC-интеграции за пределы GitHub и добавлять более гибкие политики доступа.
Оригинал: документация Docker по OIDC connections