Чому підписування Docker-образів зривається на етапі викладки
Класичний збій виглядає так: збірка відпрацювала, образ пішов у реєстр під плаваючим тегом, а через годину на вузлі в робочому середовищі запущено зовсім інший набір шарів.
Причини бувають побутові — хтось перезібрав локально і дописав тег поверх, складальне завдання впало на середині й виклало попередній результат, дзеркало реєстру віддало закешовану копію. Тег — змінна мітка, і вона нічого не говорить про те, що саме завантажилося.
Відрізнити підміну від нормального релізу за зовнішніми ознаками майже неможливо: той самий тег, той самий порт, застосунок стартує і проходить базові проби.
Непідписаний образ у проді живе до першого інциденту — його помічають за фактом витоку, стороннього мережевого трафіку або втрачених даних, а не на етапі викладки.
Розбір потім займає дні, бо пов'язати працюючий контейнер з конкретним набором вихідних кодів і номером складального запуску постфактум нічим.
Перевірка походження образу потрібна саме для того, щоб це питання закривалося за секунди.
Криптографічний підпис фіксує, що артефакт зібрано конкретним складальним завданням з конкретного стану вихідного коду, а перевіряльний механізм у кластері просто не дає запустити те, чий підпис не збігається.
Тоді підміна артефакту між збіркою та викладкою впирається у відмову на вході, а не в розбір наслідків.
Розбираємо, як це закривається: підписування Docker-образів, Keyless через Sigstore і політики Kyverno, які пропускають у кластер лише перевірене.
Що дає перевірюваний ланцюг постачання: ефект у вимірюваних величинах
Підпис образу перетворює питання «звідки цей артефакт» на машинну перевірку. Поки образ не підписано ключем складального процесу, розгортання відхиляється на вході в кластер — до того, як контейнер отримає доступ до мережі та секретів. Це і є контроль цілісності артефактів: звіряється не ім'я тегу, а конкретний зліпок збірки.
Підготовка релізу перестає чекати ручного підтвердження: складальний конвеєр сам підписує та публікує артефакт, а інженер втручається лише там, де потрібне рішення.
Частка ручних операцій у викладці падає до поодиноких кроків, час викладки скорочується з годин до хвилин — і на кожному релізі, а не разово.
На розборі інциденту журнал перевірок відповідає, яка збірка і який підписувач породили артефакт у конкретному середовищі. Локалізація займає хвилини замість перебору версій вручну, а вікно простою обмежується одним відкатом на попередню підписану збірку.
Окремий наслідок — усунутий клас відмов. Підміна тегу, образ з локальної збірки, відкат на непідписаний артефакт більше не доходять до бойового контуру: їх відхиляє політика на вході в кластер.
Перевірюваний ланцюг постачання перестає бути звітом для аудиту і стає штатним механізмом, який економить години на кожному релізі та кожному розборі.
Підписування артефактів: ключовий, безключовий і гібридний режими
Режими різняться не алгоритмом, а тим, як перевіряльна сторона пов'язує підпис з особистістю. Ключовий підпис тримає довгоживучий закритий ключ, безключовий випускає короткоживучий сертифікат під посвідчення конвеєра, гібридна схема посвідчення поєднує обидві довіри.
| Режим | Коли підходить | Обмеження |
|---|---|---|
| Ключовий | Замкнуті контури без вихідного доступу: підпис ставиться із захищеного сховища, кластер перевіряє образ за публічним ключем | Потрібні ротація та охорона ключа: його компрометація означає перепідпис усього реєстру, а підпис не говорить, хто саме його поставив і з якої гілки |
| Безключовий | Збірка в загальному конвеєрі: зовнішній засвідчувальний центр видає сертифікат на хвилини, приватного матеріалу на диску не залишається | Потрібен вихідний доступ до сервісу посвідчення та журналу прозорості; в ізольованому контурі без проксіювання режим не працює взагалі |
| Гібридний | Політика вимагає і офлайн-перевірки, і прив'язки до конкретного конвеєра, гілки, середовища | Дорожче в налаштуванні: доводиться синхронізувати ланцюг довіри та підтримувати два джерела перевірки одночасно |
На боці кластера режим задає правило допуску: перевірка за публічним ключем або за посвідченням і видавцем сертифіката. Типова пастка — правило, яке дивиться лише на факт підпису: тоді проходить образ, підписаний будь-яким посвідченням, і сенс перевірки втрачається. Тому порівняння режимів підпису роблять до впровадження і фіксують області перевірки явно.
Впровадження за кроками: від аудиту конвеєра до передачі експлуатації
Порядок робіт будуємо так, щоб підпис образів не зупинив поточні викатки: спочатку фіксуємо реальний стан, потім вводимо правила і лише потім вмикаємо блокування.
-
Аудит конвеєра збірки. Інвентаризація: де і чим збираються образи, які реєстри задіяні, хто деплоїть, які політики допуску вже є. Результат — карта залежностей і точки вбудовування підпису.
-
Схема довіри. Вирішуємо, що засвідчує особистість збирача: безключовий режим з посвідченням від системи збірки або ключ у сховищі секретів. Фіксуємо список довірених посвідчень.
-
Налаштування підпису. Cosign підписує образ після публікації, запис іде в журнал прозорості. Перевіряємо на одному сервісі, що теги та дайджести не розходяться.
-
Налаштування перевірки артефактів. Правило допуску в кластері звіряє підпис і посвідчення до старту контейнера — спочатку в режимі попередження, щоб побачити, що відвалиться.
-
Прогін на стенді. Повний цикл: збірка, підпис, перевірка, відкат на попередній образ, поведінка при недоступності журналу. Вимірюємо затримку викатки і частку хибних відмов.
-
Приймання та передача експлуатації. Переводимо перевірку в блокуючий режим, віддаємо регламент: як підписати вручну, як додати довірене посвідчення, що робити при інциденті.
Комплект передачі: політики допуску, схеми та регламенти
Працююча перевірка — це половина результату. Друга половина — комплект, за яким інший інженер зможе цю перевірку підтримувати, змінювати та за потреби скасовувати без автора. Нижче — що саме залишається у вашої команди після передачі.
- Політики допуску. Які образи запускаються в кластері, чи обов'язковий підпис, що робити з непідписаними збірками, які винятки відкриті та до якої дати діють.
- Розмежування ролей. Хто має право підписувати артефакт, хто — змінювати політику, хто — лише читати журнал. Право підпису та право допуску розведені: збирач не дозволяє собі викладку одноосібно.
- Схема потоків збірки та викладки. Один аркуш: де ставиться підпис, де проходить перевірка, що відбувається при відмові та куди йде повідомлення. За ним новий інженер входить у контур без перепитувань.
- Регламент реагування на інцидент. Компрометація ключа або облікового запису підпису: як відкликати, як перепроверити вже викладене, за який час зобов'язаний вкластися черговий.
- Документація щодо підпису. Як випускається короткоживучий сертифікат, до якої особистості збірки він прив'язаний, як відтворити перевірку вручну на своїй машині поза контуром.
- Інструкція для чергового. Розбір типових відмов — образ не підписано, підпис прострочено, недоступний сервіс ідентичності — з командами та межею «роблю сам / ескалюю».
- Журнал перевірок. Що і як довго зберігається, як вивантажити звіт для внутрішнього аудиту та довести, що в прод не потрапляв непідписаний артефакт.
Комплект збирається під ваші процеси і передається разом із розбором: показуємо, як змінювати політику, не ламаючи викладку. Політика без регламенту перетворюється на налаштування, яке бояться чіпати, — тому документація йде в постачання, а не залишається в листуванні.
Кейс: прибрали підміну артефактів між збіркою та викладкою
У замовника збірка та викладка жили в одному конвеєрі, але право на реліз залишалося за інженером, а образи адресувалися тегами.
Одного дня в продакшен пішов образ з чужої гілки: тег встигли перезаписати між збіркою та викладкою, і перевірити зв'язок релізу з вихідним комітом було нічим. Інцидент локалізували більше трьох годин — зв'язок шукали за логами.
Підписування docker-образів ми поставили в той самий конвеєр: викладка йде за digest, а не за тегом, а кожна збірка отримує короткоживучий сертифікат у keyless-режимі Sigstore — довгоживучий ключ не зберігається.
На вході в кластер політика Kyverno відхиляє образ, якщо підпис невалідний або випущений не тим конвеєром.
Метрики до та після
- Відхилена викладка: раніше перевірок не було жодної — тепер на вході відсікається приблизно кожна двадцята спроба, і це підміни, а не робочі релізи.
- Час локалізації інциденту: з трьох годин до п'ятнадцяти хвилин — за підписом видно конвеєр, гілку та коміт.
- Ручні операції на реліз: з п'яти до нуля; відкат іде за раніше підписаним digest, а не за «попереднім тегом».
З якими застереженнями застосовний результат
Схема працює там, де збірка централізована і в неї є власний обліковий запис. Якщо частину сервісів збирають підрядні команди, починаємо з режиму попередження: політика пише подію в журнал, але не блокує викладку, — і вмикаємо блокування після того, як підписано всі гілки.
Для приватних реєстрів окремо налаштовуємо довіру до засвідчувального центру, інакше легітимні образи не пройдуть перевірку.
Чим перевірка при викладці відрізняється від перевірки в сховищі?
Перевірка при викладці та контроль у сховищі образів — дві різні точки контролю, і закривають вони різні класи відмов.
Підписування docker-образів фіксує, хто і що саме випустив, але сам підпис можна перевірити в двох місцях: реєстр відсікає непідписане на вході, середовище виконання підтверджує справжність у момент запуску.
Політика в реєстрі спрацьовує в момент запису: якщо в образу немає валідного підпису Sigstore або не виконані вимоги до базового шару, він не потрапляє в сховище.
Розробник дізнається про це одразу, а не після розгортання, і в реєстрі не накопичуються артефакти з неясним походженням. Але точка контролю тут одна — лише запис.
Контролер допуску в середовищі ловить те, що приходить повз звичайний канал: образи з іншого реєстру, локально завантажені архіви, теги, перезаписані після публікації.
Він відхиляє запуск, якщо підпис формально є, але видано не тим, хто повинен підписувати: при keyless-підписі перевіряється конкретний обліковий запис та її емітент, а не сам факт наявності сертифіката.
Без цього уточнення перевірка працює, але пропускає все — будь-який валідний сертифікат відкриває доступ до середовища. І обмеження в контролера допуску своє: він перевіряє лише створення, вже запущений контейнер він не зупинить, тому політика в реєстрі залишається обов'язковою. Потрібні обидві точки контролю — одна чистить вхід, друга гарантує факт у середовищі.
Технічні сумніви інженерів: ключі, відкликання, довірені джерела
Підпис допомагає рівно настільки, наскільки передбачувані відповіді на незручні питання: що робити при компрометації ключа, що з образами, викладеними до впровадження, хто і як змінює політику допуску.
Нижче — те, що найчастіше обговорюємо на погодженні, бо без цих відповідей перевірка в кластері залишається формальністю.
Працюємо з Cosign: підпис лежить поруч із образом у реєстрі, а перевірка виконується в момент допуску. Тоді ротація, відкликання та довірені джерела вирішуються інфраструктурно, а не листуванням у чаті.
Що відбувається при компрометації ключа підпису?
Ключ відкликається, його відбиток потрапляє до списку недовірених, і всі образи, підписані ним, перестають проходити перевірку допуску — включно з тими, що вже лежать у реєстрі.
Артефакти при цьому перезбирати не потрібно: перепідпис займає хвилини, бо підпис не змінює вміст образу. Відкликання підпису діє одразу при наступній перевірці, а не «колись при перезбірці».
Вже викладені непідписані образи — видаляти?
Ні. Політику вмикаємо в режимі спостереження: вона лише фіксує порушення, нічого не блокуючи. Далі обмеження поширюється на нові розгортання, а працюючі контейнери не гасяться — їх замінюють підписаними версіями в міру планових оновлень.
Як визначається довірене джерело?
Правило допуску прив'язує образ до конкретного реєстру та посвідчення збірки, виданого довіреним центром. Тоді для нових збірок підпис можна не зберігати у вигляді довгоживучого ключа: підробити її не можна, а втекти — нічому.
Хто володіє політиками допуску?
Політики — частина репозиторію, а не налаштування в особистому кабінеті: будь-яка зміна проходить рев'ю і потрапляє в історію. У кожного правила є власник з команди, тому посилення вимог не перетворюється на несподіване блокування релізу.
Обговоримо задачу: розберемо ваш конвеєр і повернемося з планом
Розбір конвеєра викладки починається з фактів, а не із загальних питань: за зрізом вашої інфраструктури видно, де підпис образів вбудується в поточний процес, а де потребує правок у правах і порядку випуску.
Надішліть те, що вже є — цього достатньо, щоб повернутися з оцінкою обсягу робіт, а не з припущеннями.
- схему викладки від правки в репозиторії до продакшену: які кроки автоматичні, де залишилися ручні підтвердження;
- список середовищ і відмінності між ними за доступами та політиками;
- поточні права збірки та публікації: хто випускає образи і в кого є запис у реєстр;
- конфігурацію реєстру: правила зберігання, теги, термін життя старих версій;
- перелік перевірок перед випуском: сканування, тести, погодження і хто їх підтверджує;
- обмеження контуру: закрита мережа, вимоги до зберігання ключів, розподіл обов'язків.
У відповідь ви отримуєте план впровадження: послідовність етапів, обсяг робіт по кожному, точки відкату, зміни в правах і критерії, за якими перевірите, що підпис дійсно працює. Опишіть задачу та додайте зріз — повернемося з оцінкою та планом.
