Що таке OIDC і як CI/CD отримує доступ без довгоживучих ключів

Зачіпка

OIDC у CI/CD вирішує дуже практичну проблему: як дати pipeline доступ до cloud, не кладучи постійний ключ у secrets. Замість ключа, який може роками лежати в налаштуваннях, pipeline щоразу отримує короткоживучий токен.

Для початківця це звучить як ще одна security-абревіатура. Насправді ідея проста: сервіс деплою довіряє не випадковому секрету, а підтвердженій ідентичності конкретного workflow.

Проблема / Контекст

Класична схема CI/CD часто починається з довгоживучого ключа. Хтось створює cloud access key, додає його в GitHub Actions secrets або інший CI/CD, pipeline деплоїть, усі раді. До першого витоку.

Проблема в тому, що static key не дуже розуміє контекст. Якщо ключ скопіювали, він може працювати з іншого місця. Якщо йому дали забагато permissions, він може робити більше, ніж потрібно. Якщо його забули rotate, він живе довше, ніж сам проєктний план. А якщо secret випадково потрапив у logs, issue, fork або локальний .env, команда отримує інцидент.

OIDC змінює модель. Pipeline не зберігає постійний cloud key. Під час запуску він просить identity provider видати токен. Cloud перевіряє цей токен через trust policy: з якого репозиторію запит, яка гілка, який workflow, який environment, для якого сервісу токен призначений. Якщо все збігається, cloud видає короткоживучі credentials.

Тобто секрет не лежить у CI/CD як вічний запасний ключ під килимком. Доступ створюється на час конкретного запуску і прив’язується до конкретного контексту.

Чому це важливо

CI/CD має дуже сильні права. Pipeline може збирати код, публікувати пакети, запускати Terraform, деплоїти в Kubernetes, оновлювати serverless-функції, читати secrets і чіпати production. Якщо доступ pipeline побудований на одному довгоживучому ключі, цей ключ стає дуже цінною ціллю.

OIDC зменшує ризик у трьох місцях.

По-перше, немає static secret у репозиторії або CI/CD storage. Немає що випадково надрукувати в logs або скопіювати в чужий ноутбук.

По-друге, доступ короткоживучий. Навіть якщо токен десь засвітився, його час життя обмежений. Це не чарівний щит, але наслідки зазвичай менші, ніж після витоку ключа на рік.

По-третє, trust policy може бути точнішою. Можна дозволити production deploy тільки з main, тільки через protected environment, тільки з конкретного repository, тільки для конкретного audience. Для staging можна мати м’якші правила, а для production - суворіші.

Це особливо корисно там, де команда росте. Коли людей і репозиторіїв мало, static keys здаються зручними. Коли з’являються кілька environments, підрядники, preview deploy, self-hosted runners і Terraform, старі ключі швидко перетворюються на технічний борг.

Схема в голові

Уяви три сторони.

Перша сторона - CI/CD pipeline. Він запускається з конкретного репозиторію, гілки, workflow і environment.

Друга сторона - identity provider. У випадку GitHub Actions це GitHub OIDC provider. Він може сказати: “так, цей запуск справді походить з цього repo і має такі claims”.

Третя сторона - cloud або deploy-сервіс. Він не довіряє pipeline просто на слово. Він читає токен, перевіряє issuer, audience, subject і додаткові claims, а потім вирішує, чи видати тимчасові credentials.

Здорова схема виглядає так:

• workflow просить OIDC token тільки тоді, коли йому справді треба доступ;
• cloud trust policy приймає токени лише від очікуваного identity provider;
• policy перевіряє repository, branch, environment і audience;
• роль має мінімальні permissions для конкретної задачі;
• staging і production використовують різні ролі;
• старі static keys після міграції відкликаються.

Головне: OIDC не означає “будь-який workflow може зайти в cloud”. Він означає “cloud може перевірити, який саме workflow просить доступ, і видати права тільки за правилами”.

Як це зробити

1. Проведи інвентаризацію поточних secrets

Почни не з консолі cloud, а з карти доступів. Знайди всі secrets у CI/CD, які схожі на cloud keys, deploy tokens, service account keys або Terraform credentials. Для кожного запиши:

• де він використовується;
• які permissions має;
• хто його створив;
• коли його востаннє rotate;
• чи потрібен він для staging, production або обох;
• що зламається, якщо його відкликати.

Цей список одразу покаже, де OIDC дасть найбільшу користь. Зазвичай першими кандидатами є cloud deploy, Terraform apply, container registry push і Kubernetes deploy.

2. Створи окремі ролі для staging і production

Не роби одну універсальну роль “ci-admin”. Вона зручна, але небезпечна. Краще створити окремі ролі:

• staging deploy role;
• production deploy role;
• read-only планування для Terraform;
• package publish role;
• emergency role, якщо вона справді потрібна.

Кожна роль має отримати тільки ті permissions, які потрібні для конкретної дії. Якщо workflow публікує container image, йому не треба право видаляти бази даних.

3. Опиши trust policy через claims

Найважливіша частина OIDC - не сам факт увімкнення, а умови довіри. Trust policy має відповідати на питання: яким саме запуском CI/CD ми довіряємо?

Для GitHub Actions зазвичай перевіряють repository, branch або tag, environment, workflow, issuer, audience і subject. Для production краще прив’язувати доступ до protected environment або release process, а не просто до будь-якого push у будь-яку гілку.

Приклад мислення:

• staging можна дозволити з main або preview-гілок з обмеженою роллю;
• production тільки з main і тільки через environment production;
• Terraform apply тільки з окремого workflow;
• package publish тільки з release tag.

Якщо policy занадто широка, OIDC втрачає сенс. “Будь-який repo в організації може взяти production role” - це майже той самий запасний ключ, тільки у моднішій упаковці.

4. Увімкни OIDC у workflow

У CI/CD треба дозволити workflow просити identity token. У GitHub Actions для цього зазвичай потрібен permission id-token: write, а потім офіційний cloud action або SDK обмінює OIDC token на короткоживучі credentials.

Важливий момент: id-token: write не має стояти всюди автоматично. Дай його тільки тим workflows, які справді мають входити в cloud. Для jobs, які лише запускають tests або lint, він не потрібен.

5. Перевір audit logs

Після першого тестового запуску не обмежуйся зеленим checkmark. Відкрий audit logs у cloud або deploy-сервісі й перевір:

• яка роль була отримана;
• який repository і workflow прийшли в claims;
• який audience використано;
• скільки жив доступ;
• чи не отримав pipeline зайві permissions.

Це момент, де часто ловляться помилки. Наприклад, staging workflow випадково отримує production role, або trust policy приймає всі гілки замість однієї.

6. Відклич старі ключі

OIDC не дає повної користі, якщо старі static keys лишилися активними “про всяк випадок”. Після міграції зроби контрольований rollback-план, потім відклич старі keys, видали їх з CI/CD secrets і перевір, що pipeline не залежить від них.

Якщо страшно відкликати ключ, це сигнал: команда ще не до кінця розуміє, де він використовується. Спочатку треба дорозібрати карту доступів.

Антипатерни

• залишити старий cloud key активним після переходу на OIDC;
• дозволити production role для всіх branches або всіх repositories;
• використовувати одну роль для staging, production і Terraform admin;
• додати id-token: write в усі workflows без потреби;
• перевіряти тільки repository, але не environment, branch або workflow;
• не дивитися audit logs після тестового запуску;
• плутати OIDC для CI/CD з login flow для користувачів;
• вважати, що короткоживучий токен виправить надто широкі permissions.

Висновок / План дій

OIDC у CI/CD - це спосіб замінити довгоживучі secrets на перевірену identity і короткоживучий доступ. Він не скасовує permissions, code review, protected branches і audit logs, але прибирає одну з найболючіших точок: постійний ключ у pipeline.

Почни з практичного мінімуму:

1. знайди static keys у CI/CD;
2. вибери один staging deploy як перший кандидат;
3. створи окрему роль із мінімальними permissions;
4. налаштуй trust policy за repository, branch, environment і audience;
5. додай OIDC у workflow тільки для потрібного job;
6. перевір audit logs;
7. повтори для production із суворішими правилами;
8. відклич старі ключі після успішної міграції.

Хороший OIDC-доступ відчувається менш магічно, ніж static keys. У ньому більше явних правил: хто просить, звідки, для чого і на який час. Саме це і робить його кращим фундаментом для сучасного CI/CD.

Офіційні джерела:

• https://openid.net/developers/how-connect-works/
• https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect
• https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc.html
• https://cloud.google.com/iam/docs/workload-identity-federation