Сканування Terraform: де ламається інфраструктура
Інфраструктура рідко ламається в момент застосування конфігурації. Зазвичай вона розповзається повільніше: інженер править правила доступу в консолі, щоб розблокувати реліз, додає маршрут «на п'ять хвилин», лагодить прод вручну — і все це живе повз код. Через кілька ітерацій стан у хмарі перестає збігатися з описом у репозиторії.
Так починається розбіжність середовищ. Стенд зібрано з того самого модуля, але він відрізняється від проду налаштуваннями, які вносили руками й не переносили назад.
Перевірки проходять, а відмова приходить уже після розгортання: порт відкритий назовні, роль видано надто широко, сховище доступне публічно.
Відкат у такій ситуації не рятує — проблема не в конкретному релізі, а в тому, що опис і реальність ніколи не збігалися.
Дрейф конфігурації коштує дорого не часом збірки, а часом до виявлення: чим пізніше він спливає, тим більше ручних правок інфраструктури доводиться розбирати й повертати в код.
Сканування terraform переносить ці перевірки на момент, коли конфігурацію ще не застосовано. Аналізатори tfsec і Checkov розбирають описи ресурсів і знаходять небезпечні значення на етапі рев'ю, а не після інциденту. Розбираємо, як це влаштовано і що дає в роботі.
Що дає регулярна перевірка конфігурацій: класи відмов
Статичний аналіз інфраструктурного коду переносить точку контролю вліво: конфігурація розбирається до розгортання, а не після того, як правка поїхала в робоче середовище.
Перевірка йде за описом ресурсів — відкриті порти, шифрування диска й сховищ, права доступу, публічні адреси — і не потребує піднімати саме середовище. Звіт з'являється на етапі рев'ю, поки зміна ще нічого не зачепила.
Час перевірки змін падає з годин ручного читання конфігурацій до хвилин: правила формулюються один раз і застосовуються до кожної зміни автоматично. Інженер розбирає не сотню рядків, а короткий список зауважень із зазначенням ресурсу й місця.
Перевірка не залежить від уважності рев'юера, тому та сама помилка не повертається в наступних релізах.
Друга частина ефекту — єдина картина середовищ. Один набір правил проганяється для всіх середовищ, і розбіжність між тестовим і робочим контуром видно як конкретний пункт звіту, а не як сюрприз під час наступного застосування. Дрейф конфігурацій, накопичений із ручних правок, перестає бути невидимим.
Усунений клас відмов — не «стало безпечніше» загалом, а конкретика: публічно доступне сховище з резервними копіями, відкритий назовні порт бази, права адміністратора у сервісного облікового запису, вимкнене шифрування.
Наші інженери налаштовують Checkov разом із tfsec так, щоб такі знахідки блокували зміну до застосування, а не перетворювалися на завдання на потім.
Сканування Terraform: режими запуску та їхні обмеження
Режим запуску визначає не швидкість сканера, а те, які помилки ви зловите до застосування.
tfsec і Checkov розбирають ті самі декларації Terraform, але увімкнені в різних точках, дають різний сигнал: обов'язкова відмова під час злиття і нічний звіт по всьому репозиторію відповідають на різні питання.
| Режим | Коли підходить | Чим обмежений |
|---|---|---|
| Перевірка в конвеєрі збірки | Кожен коміт у робочій гілці: помилка видна в момент появи | Подовжує збірку; на великому репозиторії час очікування зростає помітно |
| Перевірка перед злиттям | Блокувальний шлюз для правил, які не можна обійти | Без налаштованих винятків гальмує термінові правки |
| Планове сканування | Обхід усього коду за розкладом: знаходять нові правила й розбіжності | Звіт приходить після факту — частину змін уже застосовано в хмарі |
| Перевірка змінених модулів | Інкрементально за розбіжностями коміту: швидкий зворотний зв'язок | Пропускає зв'язки між модулями й порушення, успадковані із загального коду |
На практиці режими не конкурують, а збираються у зв'язку: на змінених модулях тримають швидкі перевірки в конвеєрі збірки, повний набір правил вмикають перед злиттям, а за розкладом проганяють весь репозиторій.
Спільні набори правил і списки винятків при цьому перевикористовуються між точками запуску — інакше команда отримує три різні відповіді на той самий код.
Окреме обмеження — застарілі знахідки: без зафіксованого набору винятків інкрементальний режим і повний прогін показують різну кількість зауважень, і довіра до звіту падає.
Етапи впровадження: від інвентаризації до передачі регламентів
Порядок робіт вибудувано так, щоб сканування terraform давало передбачуваний результат з першого дня, а не перетворювалося на потік попереджень, які всі звикли ігнорувати.
Спочатку знімаємо фактичну картину по репозиторіях, потім формулюємо правила під реальні ризики, і лише після цього вмикаємо блокування в конвеєрі збірки.
- Аудит репозиторіїв. Інвентаризація модулів Terraform, файлів стану, провайдерів і власників: де описано інфраструктуру, які частини спільні, які давно не супроводжуються. На виході — перелік периметра, який увійде в перевірки.
- Схема правил перевірки. Знахідки tfsec і Checkov зіставляємо з фактичними ризиками: публічний доступ до сховищ, відкриті групи безпеки, вимкнене шифрування, надлишкові права ролей. Усе, що не несе ризику, до набору не потрапляє.
- Рівні строгості. Правила ділимо на блокувальні та інформаційні. Зупинка злиття — лише для критичного; решта йде звітом, інакше команда втрачає швидкість на дрібницях.
- Налаштування винятків. Кожне вимкнення оформлюється точково, із зазначенням ресурсу, причини й терміну перегляду. Масові винятки за цілими перевірками заборонені — вони знецінюють набір.
- Вбудовування в конвеєр. Перевірка запускається на етапі запиту на злиття, локально — на попередньому коміті, щоб автор бачив зауваження до відправлення гілки на рев'ю.
- Налагодження порогів на реальних змінах. Проганяємо набір по історії репозиторію й рахуємо частку спрацювань, що потребують ручного розбору. Пороги підкручуємо до стану, коли знахідки справді потребують уваги.
- Передача регламентів. Команда отримує документ: що блокує, як додати виняток, хто власник правила, як оновлювати набір при зміні інфраструктури, — плюс розбір на живих прикладах.
Що залишається в замовника: конфігурації, політики, регламенти
Результат роботи — не звіт про знахідки, а артефакти, які живуть у репозиторії та працюють без нас. Правила перевірки — теж код: конфігурація сканерів tfsec і Checkov, обов'язкові умови й поріг, за якого збірка зупиняється.
Після передачі інженер запускає перевірку локально й у конвеєрі та отримує той самий вердикт, що й ми.
Неналаштований сканер видає сотні спрацювань, команда перестає на них дивитися, і захист стає формальністю — тому кожен виняток фіксуємо з причиною й терміном перегляду.
- Політики допуску — які ресурси дозволені, які атрибути обов'язкові (шифрування, закриті мережі, мітки власника), за якої критичності зміна блокується.
- Схема модулів — карта перевикористовуваних модулів: обов'язкові параметри, де лежать спільні правила, як підключити новий сервіс без копіювання конфігурації.
- Матриця доступу — ролі й права за середовищами: що змінює інженер, що лише конвеєр, де лежать секрети й хто їх читає.
- Опис винятків — кожне вимкнене правило з обґрунтуванням, відповідальним і умовою зняття.
- Інструкція для інженерів — як запустити перевірку до коміту, як читати вердикт, що робити при спрацюванні та як оформити відступ.
- Порядок розбору знахідок — маршрут від спрацювання до виправлення: хто дивиться, у який термін, що блокує випуск, що йде в чергу.
Артефакти оновлюються разом із кодом у звичайному порядку змін — новий інженер бачить працюючі правила, а не усні домовленості.
Кейс: дефекти конфігурацій, упіймані до розгортання
Інфраструктура проєкту — кілька десятків середовищ у Terraform, правки вносили три команди й заводили в середовища після рев'ю очима по дифу. Налаштування копіювали за зразком, тому один невдалий фрагмент розходився по десятках конфігурацій і спливав уже на працюючому контурі.
Що показав замір до впровадження перевірок
Ми пройшли по історії змін: дефект конфігурації доходив до середовища приблизно в кожному четвертому випадку. Понад половина знахідок — широкі правила мережевого доступу й відкриті порти, решта — диски без шифрування, публічно читані сховища та значення секретів прямо у змінних. Частка відкатів при розгортанні трималася близько 18%, а розбір кожного займав години.
Що змінили
Сканери tfsec і Checkov підключили в перевірку запиту на злиття: критичні знахідки блокують його, решта приходять попередженням із зазначенням файлу й рядка. Завели перелік усвідомлених винятків з обґрунтуванням і свої правила під вимоги проєкту, щоб перевірки не шуміли. Звіт сканування додається до рев'ю — рев'юер бачить не лише диф, а й ризик.
Що стало
Дефекти конфігурацій, що доходять до середовища, — з 25% до 2-3%, відкати — з 18% до менш ніж 4%. Розбір знахідки займає хвилини замість годин: у звіті видно правило, файл і рядок. Перевірками покриті всі зміни конфігурацій, включно з правками в один рядок.
Що робити, якщо інфраструктуру вже розгорнуто вручну?
Універсального шляху немає: вибирати потрібно за ціною простою середовища й обсягом ручних змін, які ніхто не документував. Працююча інфраструктура — факт, із яким код має зійтися, а не навпаки.
| Шлях | Коли підходить | Обмеження |
|---|---|---|
| Описати в коді | Критичні середовища, які не можна зупиняти | Імпорт у state — ручна робота; частину налаштувань описано заново |
| Залишити як є, точковий контроль | Контури під швидкий вивід, пісочниці | Розбіжність накопичується, інциденти погано відтворюються |
| Перебрати з нуля | Тестові контури з відновленням із копій | Потрібні вікно простою й перенесення даних |
Опис у коді починається з імпорту: реальні об'єкти вносяться в state, і наступний план має бути порожнім. Якщо план щось змінює — опис не збігся з фактом, і це видно на рев'ю, а не в момент відмови.
Потім у контур додається сканування terraform: tfsec і Checkov перевіряють описи на відкриті порти, публічні сховища й відсутність шифрування до застосування.
Точковий контроль — компроміс: сканування працює в режимі перевірки, запис у консоль закривається, розбіжності шукаються регулярно. Обмеження в тому, що стан залишається ручним — відтворити середовище з нуля, як і раніше, не можна.
Перебирання дає повну керованість, але потребує вікна простою й перенесення даних. Його обкатують на некритичному контурі, налагоджують описи й лише потім переносять на продуктив.
Хибні спрацювання, пороги та успадкування правил
Сканери на живому репозиторії видають сотні зауважень, і частина з них — шум від рішень, які команда ухвалила усвідомлено. Якщо цим не керувати, звіт читають один раз і перестають відкривати: реальний сигнал тоне в обсязі.
Тому ми одразу налаштовуємо поріг спрацювання за рівнем критичності — збірка зупиняється лише на тому класі знахідок, який справді блокує випуск, решта потрапляє у звіт як довідкова інформація.
Успадкування правил будується від загального набору політик: базовий профіль живе в окремому модулі й підключається в усі репозиторії, а проєкт може перевизначити або послабити конкретне правило — з явною фіксацією в коді.
Винятки в правилах ми оформлюємо не вимкненням перевірки, а точковим пропуском із зазначенням причини й власника: Checkov і tfsec дозволяють задати такий пропуск поруч із ресурсом, і на рев'ю видно, хто і навіщо його поставив.
Розбір знахідок іде за однією схемою: підтверджені уразливості — у чергу виправлень із пріоритетом, хибні спрацювання — у список винятків з обґрунтуванням, спірні — до власника ресурсу. Звіт перестає бути звалищем і перетворюється на список завдань, який реально закривається.
Сканер видає сотні зауважень на наявну інфраструктуру — з чого починати?
Починаємо з базової лінії: фіксуємо поточний стан, вмикаємо поріг лише на нові зміни й поступово розбираємо накопичене. У міру зниження шуму суворий профіль поширюється на весь репозиторій — без зупинки роботи команд.
Обговоримо завдання й повернемося з оцінкою та планом робіт
Щоб розмова була предметною, варто заздалегідь зібрати мінімальний зріз: де лежить інфраструктурний код, хто і як його змінює, які середовища живуть окремо.
За цим зрізом ми оцінимо обсяг сканування terraform і повернемося з оцінкою та планом робіт — з етапами й строками, а не загальними словами.
До обговорення завдання корисно підготувати:
- доступи до репозиторіїв — достатньо на читання, щоб побачити структуру модулів і історію правок;
- перелік середовищ і те, як вони розділені: розробка, передпродуктивне, продуктивне;
- поточні правила перевірок — які перевірки вже увімкнено і що потребує доналаштування.
На основі цього зрізу ми повернемося з планом робіт і строками за етапами.
