Docker Hub OIDC усуває прогалину в безпеці GitHub Actions

Усунення прогалини в безпеці GitHub Actions

Docker оголосив про впровадження OIDC-з'єднань для Docker Hub, що усуває останню значну прогалину, пов'язану з довгостроковими обліковими даними в робочих процесах GitHub Actions. До цього моменту інженери, які перейшли на безпарольну хмарну автентифікацію, все ще покладалися на особисті токени доступу (PAT) або токени доступу організації (OAT), що зберігалися в секретах GitHub для автентифікації docker push. Це створювало вразливість, оскільки ці токени залишалися дійсними та могли бути викрадені.

Проблема довгострокових облікових даних

Довгострокові облікові дані, такі як PAT та OAT, були постійною мішенню для зловмисників. Згідно зі звітом GitGuardian "State of Secrets Sprawl 2026", у 2025 році було виявлено майже 29 мільйонів нових жорстко закодованих секретів у публічних комітах GitHub, що на 34% більше порівняно з попереднім роком. У 59% проаналізованих атак на ланцюг поставок скомпрометованими машинами були CI/CD-раннери, а не робочі станції розробників. Довговічність цих токенів є основною вразливістю; понад 64% облікових даних, підтверджених як дійсні у 2022 році, залишалися дійсними у січні 2026 року.

Приклади атак включають компрометацію tj-actions/changed-files у березні 2025 року, що призвело до витоку PAT, який каскадно поширився ланцюгом поставок, та кампанію Pipe-Psiphon на початку 2026 року, яка використовувала модифікований інструмент для вилучення секретів з пам'яті CI-раннерів. Компрометація Checkmarx KICS у квітні 2026 року також цілеспрямовано атакувала облікові дані Docker Hub.

Як працює автентифікація Docker OIDC

Реалізація Docker OIDC наслідує шаблон федерації ідентифікації робочого навантаження, який вже використовується AWS, GCP та Azure. Коли робочий процес GitHub Actions запускається з новою конфігурацією, провайдер OIDC GitHub генерує підписаний JSON Web Token (JWT) для цього конкретного запуску. Цей токен містить інформацію про репозиторій, гілку, середовище та ініціатора робочого процесу.

Робочий процес передає цей токен до docker/login-action (версія 4.5.0 або новіша), який представляє його Docker Hub. Docker Hub перевіряє криптографічний підпис токена за публічним реєстром ключів GitHub, а потім перевіряє поле sub токена на відповідність правилам, налаштованим адміністратором організації. Якщо правила збігаються, Docker видає короткостроковий токен доступу, термін дії якого становить від 300 до 3600 секунд (від п'яти хвилин до однієї години). Цей токен не може бути повторно використаний після завершення робочого процесу. Таким чином, нічого не зберігається, і немає облікових даних, які можна було б викрасти або відкликати у разі компрометації раннера.

Правила доступу (Rulesets)

Окрім усунення збережених секретів, нова функція запроваджує модель правил доступу (rulesets), яка надає адміністраторам детальний контроль над тим, які робочі процеси можуть автентифікуватися в Docker Hub. Організації можуть налаштувати до п'яти наборів правил для кожного OIDC-з'єднання, використовуючи зіставлення subject claim для контролю доступу.

Підтримуються шаблони від специфічних для однієї гілки (наприклад, repo:my-org/my-repo:ref:refs/heads/main) до доступу в межах усієї організації (repo:my-org/*). Docker явно не рекомендує шаблон для всієї організації, оскільки це фактично відтворює проблему надмірних дозволів, характерну для довгострокових облікових даних. Модель правил також враховує зміни у форматі токенів OIDC GitHub, де репозиторії, створені після 15 липня 2026 року, використовують незмінні числові ідентифікатори.

Практичні зміни та доступність

Міграція є одноразовим оновленням, що включає створення з'єднання в Docker Home, визначення правил, копіювання ідентифікатора з'єднання та невелику зміну у файлі YAML робочого процесу. Після успішного запуску робочого процесу з новою конфігурацією старі PAT або OAT можна видалити з секретів GitHub. Існуючі PAT та OAT продовжують працювати під час та після міграції, оскільки Docker не примушує до негайного переходу.

Ця функція доступна для організацій Docker Team, Docker Business, Docker Hardened Images та Docker Sponsored Open Source Program. Docker зазначає, що підтримка додаткових платформ буде оцінюватися на основі попиту.

Важливо зазначити, що OIDC-з'єднання автентифікує робочий процес як користувача, а потім авторизує його відповідно до налаштованих правил. Доступ на рівні організації для інших ресурсів Docker продовжує регулюватися OAT.

Ризики конфігурації

Хоча перевага безпеки є структурною (усунення токена), конфігурація правил несе ризик, який вже демонстрували попередні реалізації OIDC. Дослідження Unit 42 у квітні 2025 року показало, що надмірно дозвільне зіставлення subject claim (наприклад, довіра будь-якому робочому процесу з будь-якої гілки будь-якого репозиторію в організації) фактично надає такий самий широкий доступ, як і довгостроковий токен, але з коротшим терміном дії. Модель безпеки залежить від специфічності правил, а не лише від механізму OIDC.

Для проєктів з відкритим вихідним кодом, що беруть участь у програмі Docker Sponsored Open Source Program, ця функція є особливо важливою, оскільки вони є цінними цілями для атак на ланцюг поставок. Впровадження автентифікації без облікових даних для публічно підтримуваних проєктів усуває одну з найпоширеніших поверхонь атаки.

Що це означає для розробників

Ця новина означає, що розробники тепер можуть усунути довгострокові облікові дані Docker Hub (PAT/OAT) зі своїх GitHub Secrets, замінивши їх на короткострокові, одноразові токени OIDC. Це значно підвищує безпеку CI/CD-пайплайнів, оскільки викрадення токена після завершення робочого процесу не надасть зловмиснику доступу. Розробникам потрібно буде оновити конфігурацію своїх робочих процесів GitHub Actions, щоб використовувати нові OIDC-з'єднання та налаштувати відповідні правила доступу.

Ключові факти

Docker Hub запровадив OIDC-з'єднання для автентифікації в GitHub Actions.
Нова система замінює довгострокові PAT/OAT на короткострокові токени, що діють лише під час виконання робочого процесу.
Токени OIDC генеруються GitHub, перевіряються Docker Hub та видаються на термін від 5 хвилин до 1 години.
Система використовує правила доступу (rulesets) для детального контролю над тим, які робочі процеси можуть автентифікуватися.
Надмірно дозвільні правила доступу (наприклад, для всієї організації) не рекомендуються, оскільки вони можуть відтворити проблеми безпеки довгострокових токенів.