Управління секретами GitHub Actions: захист API-ключів і паролів у робочих процесах

By Mirko Peters · 2026-10-26

Дізнайтеся, як захистити свої конвеєри CI/CD за допомогою правильного використання секретів GitHub Actions. Ознайомтеся з найкращими практиками безпечного зберігання API-ключів і токенів доступу.

Automatically translated with AI from the original post. Read the English original

Коли ваша автоматизація повністю працює без нагляду в хмарі, безпека облікових даних стає критично важливою. Ефективне управління секретами GitHub Actions гарантує, що ваші API-ключі, паролі для розгортання та токени доступу не потрапляють у вихідний код, але залишаються легкодоступними для робочих процесів, яким вони потрібні для збирання й випуску ваших проєктів.

Головне

• Ніколи не вписуйте паролі, API-ключі чи токени доступу безпосередньо у YAML-файли робочих процесів.
• GitHub надає три рівні секретів: секрети репозиторію, секрети організації та секрети середовища.
• Секрети шифруються ще до того, як потраплять до GitHub, і автоматично маскуються у журналах виконання.
• Секрети середовища можуть вимагати ручного погодження перед тим, як облікові дані розгортання стануть доступними для завдання.
• Завжди дотримуйтеся принципу найменших привілеїв, надаючи кожному секрету найменший набір необхідних дозволів.

Чому облікові дані у відкритому тексті ламаються в CI/CD

Розробникам, які поспішають налаштувати новий конвеєр, спокусливо вставити API-ключ прямо у файл конфігурації робочого процесу. Адже якщо робочий процес приватний, хто його побачить? Такий підхід створює серйозні вразливості безпеки. Файли робочих процесів зберігаються в системі контролю версій, тобто кожна історична ревізія, коміт і гілка постійно зберігають запис усього, що було написано в цих YAML-документах.

Крім того, репозиторії часто змінюють дозволи, переходять із приватного режиму у публічний або отримують форки від учасників. Якщо облікові дані зберігаються як рядки відкритого тексту у ваших файлах конфігурації, одна помилка в налаштуванні дозволів може відкрити все ваше продуктивне середовище. Розглядати файли конфігурації лише як інструкції, а чутливі дані зберігати в зашифрованому, відокремленому сховищі, — базове правило сучасної безпеки хмар.

Три рівні секретів GitHub

GitHub враховує, що різні облікові дані мають різні сфери дії. Щоб допомогти розробникам ефективно керувати доступом, платформа дозволяє налаштовувати секрети на трьох окремих організаційних рівнях.

Секрети на рівні репозиторію

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

Секрети на рівні організації

Коли кільком репозиторіям у компанії потрібен доступ до спільних ресурсів, таких як центральний реєстр контейнерів або корпоративний сертифікат для підпису коду, секрети організації дозволяють не дублювати записи. Адміністратори можуть визначати політики та вказувати конкретні репозиторії чи команди, яким дозволено успадковувати ці загальноорганізаційні облікові дані.

Секрети на рівні середовища

Секрети середовища прив’язують облікові дані до конкретних цілей розгортання, таких як середовища staging або production. Саме тут зберігаються ключі, необхідні для роботи з живими системами. Важливо, що секрети середовища дозволяють налаштувати обов’язкових рецензентів, щоб людина вручну погоджувала запуск розгортання до того, як облікові дані production буде розблоковано й передано раннеру.

Як GitHub захищає ваші дані під час передачі

Безпека стосується не лише того, де зберігаються секрети, а й того, як вони передаються під час виконання. Секрети шифруються на вашому локальному комп'ютері до того, як їх передано на GitHub, тож вони ніколи не надсилаються мережею у відкритому вигляді. Після збереження вони повністю приховані в інтерфейсі налаштувань репозиторію.

Коли виконується робочий процес, ви маєте явно передати секрет у крок або дію за іменем, використовуючи синтаксис виразів, наприклад ${{ secrets.DATABASE_URL } }. Це означає, що випадкова або зловмисна сторонньої дія з маркетплейсу не може самостійно взяти всі облікові дані з вашого репозиторію — вона отримує лише те, що ви їй явно передали.

Крім того, GitHub автоматично сканує журнали виконання завдань і маскує конфіденційні рядки. Якщо ваш скрипт випадково виведе значення секрету в консоль, GitHub спробує замінити символи зірочками. Проте, оскільки скрипти можуть змінювати або кодувати рядки перед виведенням, покладатися лише на маскування в журналах не можна — це не заміна безпечному коду.

Найкращі практики безпечної автоматизації

Ефективне керування секретами GitHub Actions вимагає сталих щоденних звичок. По-перше, завжди розрізняйте параметр конфігурації та секрет. Якщо значення є просто публічною веб-адресою, назвою середовища або некритичним прапорцем функції, зберігайте його у звичайному тексті у вашому YAML-файлі, щоб команда могла легко зрозуміти, як працює конвеєр. Механізм секретів використовуйте виключно для даних, які мають залишатися конфіденційними.

По-друге, дотримуйтеся принципу найменших привілеїв. Створюйте токени доступу з найкоротшим можливим терміном дії та найвужчим набором дозволів. Якщо токену розгортання потрібен лише запис до одного конкретного бакета S3, не надавайте йому адміністративних прав на всю вашу хмарну інфраструктуру.

Висновок

Опанування керування секретами GitHub Actions перетворює ваші конвеєри CI/CD із потенційних ризиків безпеки на надійні корпоративні рушії автоматизації. Відокремлюючи облікові дані від коду та використовуючи багаторівневий контроль доступу, ви можете швидко випускати програмне забезпечення без шкоди для безпеки.

Щоб детальніше ознайомитися з основами побудови автоматизованих робочих процесів, перегляньте Listen to the full episode. Слухайте повну дискусію, щоб дізнатися більше про налаштування тригерів, завдань і раннерів для вашого сучасного хмарного середовища!

Поширені запитання

Чи можу я прочитати секрет GitHub Actions у pull request із форку?

За замовчуванням GitHub не дозволяє pull request від зовнішніх учасників (форків) отримувати доступ до секретів вашого репозиторію, щоб захиститися від шкідливого коду, який міг би викрасти ваші облікові дані.

Як передати секрет із робочого процесу в конкретний крок?

Секрети передаються в робочий процес через контекст 'env' на рівні кроку або завдання: секрет GitHub зіставляється зі змінною середовища, наприклад env: API_KEY: ${{ secrets.MY_API_KEY } }.

Чи гарантовано, що секрети GitHub Actions приховані в журналах?

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

Яка різниця між секретами репозиторію та секретами середовища?

Секрети репозиторію доступні будь-якому робочому процесу в межах конкретного репозиторію, тоді як секрети середовища прив'язані до окремих середовищ розгортання (наприклад, staging або production) і можуть вимагати ручного погодження перед використанням.