одиниця 3 / 11

Управління інфраструктурою як кодом: штучний інтелект із Terraform та IaC

Прибуток:

  • Здатність розуміти концепцію IaC і робочий цикл Terraform (ініціалізація, планування, застосування, стан, модуль) і мати штучний інтелект для створення безпечних чернеток HCL
  • Можливість перевіряти кожну зміну за допомогою плану перед застосуванням і виявляти несподівані рядки знищення/заміни
  • Здатність застосовувати принципи збереження секретів у коді, безпечного збереження стану та мінімізації дозволів IAM

Раніше налаштування сервера було простим клацанням на панелі хмари: створити віртуальну машину, налаштувати мережу, додати правило безпеки. Цей метод був повільним, схильним до помилок і неповторним — було майже неможливо налаштувати те саме середовище вдруге. Сьогодні інфраструктура управляється як код. IaC (інфраструктура як код) — це підхід до опису хмарних ресурсів, таких як сервери, мережі та бази даних, у текстових файлах, а не вручну. Ці файли знаходяться в системі керування версіями (Git); Ви можете побачити, хто що змінив, коли і що; Ви можете налаштувати ту саму інфраструктуру багато разів, абсолютно однаковим способом, за допомогою однієї команди.

Найпоширенішим інструментом IaC є Terraform. Terraform приймає визначення, які ви пишете мовою HCL (HashiCorp Configuration Language — мова конфігурації Terraform), перекладає їх у API хмарного постачальника (AWS, Azure, GCP) і створює ресурси. ШІ дуже добре знає HCL і швидко створює складні блоки. Але в IaC ціна помилки висока: одне неправильне визначення може знищити всю робочу базу даних. Ось чому золоте правило в Terraform полягає в тому, щоб кожну зміну розглядати як «план» перед тим, як її впроваджувати.

Час виконання Terraform

Terraform працює з трьома основними командами — знання цих команд є обов’язковою умовою для керування результатами ШІ:

  • `terraform init`: запускає проект, завантажує необхідні плагіни провайдера.
  • `plan terraform`: порівнює поточну ситуацію з бажаною та показує, що додати, що змінити, що видалити. Нічого не реалізує. Це найважливіший крок безпеки.
  • `terraform apply`: фактично застосовує План, створюючи/змінюючи ресурси.

Крім того, життєво важливі дві концепції. Стан (файл стану): це файл, у якому Terraform зберігає поточний стан ресурсів, якими він керує; Зазвичай він зберігається у віддаленому та замкненому складі, щоб двоє людей не могли змінити чи знищити його одночасно. Модуль: багаторазовий пакет конфігурації; Наприклад, ви можете використовувати модуль «налаштувати мережу» в багатьох проектах.

Порада: найнебезпечнішим знаком у виводі Terraform є знищення або -/+ (заміна) рядків у виводі плану. Це означає, що ресурс буде видалено. Якщо ви бачите в плані несподіване знищення, ніколи не застосовуйте, спочатку зрозумійте, чому воно з'явилося.

Крок за кроком: Написання IaC за допомогою ШІ

  1. Уточніть бажану інфраструктуру. Будьте конкретними, наприклад «один VPC, дві підмережі, одна група безпеки та один t3.micro EC2 на eu-central-1».
  2. Вкажіть провайдера та версію. Яка хмара, яка Terraform і версія провайдера? Якщо ви не вкажете версію, ШІ може повернути застарілий/несумісний синтаксис.
  3. Виготовити чернетку HCL. Також запитуйте змінні та виходи.
  4. Вийміть Secret. Такі значення, як паролі та ключі, повинні надходити в сховище змінних і секретів, а не в код.
  5. Виконайте `init` + `plan`. Прочитайте вихід плану по рядках; Перевірте наявність неочікуваних видалень.
  6. Починайте з малого, впроваджуйте поступово. Спочатку застосуйте його в ізольованому тестовому обліковому записі/середовищі.

Безпека: специфічні ризики IAC

IaC настільки ж ризикований, як і потужний. Три критичні точки:

  1. У державному файлі є секрет. Стан Terraform іноді зберігає конфіденційні значення, такі як паролі бази даних, у відкритому вигляді. Ніколи не розміщуйте стан у публічному сховищі; Використовуйте зашифрований віддалений сервер із обмеженим доступом.
  2. Не вставляйте секрети в HCL. Такі рядки, як password="prod123", постійно записуються в історію Git. Натомість використовуйте змінну та дайте значення під час виконання зі змінної середовища (TF_VAR_...) або секретного сховища.
  3. Дуже широкий дозвіл IAM. Штучний інтелект іноді створює такі блоки, як Action: "*" (дозволити все), щоб "змусити все працювати". Це вразливість; звузити дозвіл до необхідного мінімуму.
Увага: коли секрет потрапляє в історію Git, він залишається в минулому та може бути скомпрометований, навіть якщо ви видалите файл. Якщо ви зробили помилку, негайно скасуйте та поверніть секрет; Просто видалити недостатньо.

Ризикований план знаки таблиці

Роздруківка плану

Значення

що робити

+створити

Новий ресурс буде додано

Загалом безпечно, хоча перевірте

~ оновлення на місці

Джерело буде змінено на сайті

Перевірте вплив (чи буде збій?)

-/+ замінити

Буде видалено та створено заново

УВАГА: може статися втрата даних

- знищити

Ресурс буде знищено

СТОП: ніколи не подавайте заявку, якщо ви цього не очікуєте

три міні-чохла

Кейс 1 — 2 дні роботи по 3 години. Одна команда збиралася написати Terraform, щоб налаштувати нове тестове середовище (VPC, підмережі, база даних RDS, кластер ECS), але вони щойно перейшли на HCL. Вони описали архітектуру та версії для ШІ та створили модульний план. Вони звірили кожен модуль із планом і запустили його в роботу за 3 години; Їм знадобиться два дні ручних проб і помилок.

Випадок 2 — план зафіксував видалення. Інженер запустив план без застосування коду оновлення, згенерованого ШІ. Вихід містив -/+ replace для робочої бази даних — AI намагався замінити незамінне поле, що означало видалення та повторне створення бази даних. Інженер припинив застосування та змінив зміну на безпечний метод. Звичка планувати запобігла катастрофі.

Випадок 3 — прихований секретний витік. Молодший, YZ видав db_password = "S3cret!" Він зафіксував рядок як є і проштовхнув його. Під час перевірки коду; Пароль було негайно скасовано та змінено, значення було переміщено до змінної та подано з секретного сховища. Урок: у HCL ніколи не буває секретів відкритого тексту.

Чотири шаблони, які можна копіювати

1) Створення проекту інфраструктури:

Напишіть таку інфраструктуру на [CLOUD: AWS] за допомогою Terraform (версія ~> 1.7): [СПИСОК ДЖЕРЕЛ]. Регіон [X]. Правила:- Зробіть усі конфіденційні значення змінними, не вставляйте їх у HCL.- Виправте версію постачальника (required_providers).- Мінімізуйте дозволи IAM, не використовуйте "*".- Повертайте [X, Y] як вихідні дані. Надайте код модульно та з поясненнями.

2) Interpreting the plan output:

Проаналізуйте вихідні дані «плану тераформи» нижче. Перелічіть мене: (1) які ресурси було додано/змінено/ВИДАЛЕНО, (2) рядки з ризиком втрати або переривання даних, (3) 3 запитання, які я маю поставити перед подачею заявки. План: [ВИВІД]

3) Вивчіть наявний HCL на предмет безпеки:

Перевірте наступний код Terraform на предмет безпеки: вбудований секрет, надто широкий дозвіл IAM, правило відкритої мережі (0.0.0.0/0), незашифроване сховище? Запишіть кожну знахідку в порядку важливості та виправлення. Код: [HCL]

4) Перетворіть повторюваний код на модуль:

Перетворіть наступний повторюваний код Terraform на багаторазовий модуль: які значення мають бути змінними, яким має бути інтерфейс модуля? Також покажіть приклад використання. Код: [HCL]

Слабка підказка / Сильна підказка

Слабко: «Створіть базу даних за допомогою Terraform».

Result: unclear which cloud, which engine, which version, encrypted or not; Завдяки застарілому синтаксису ШІ може надати загальнодоступний приклад, який вбудовує пароль у код.

Сильно: «Створіть екземпляр RDS PostgreSQL 15 на AWS з Terraform ~> 1.7. Зробіть змінну пароля, не вставляйте її в код. Пам’ять зашифрована, доступна лише з приватної підмережі, а не загальнодоступної. Виправте версію постачальника. Поверніть кінцеву точку як вихід».

Відмінність: у другому запиті наводиться механізм, версія, шифрування, обмеження мережі та секретне правило — вихід безпечний і схожий на прод.

Поширені помилки

  • «Подати заявку» без «плану». Найдорожча помилка в IaC; завжди спочатку плануйте.
  • Вбудовування секрету в HCL. Створює постійний витік в історію Git.
  • Стан збереження небезпечний. Незашифрований, розблокований публічний стан – це катастрофа.
  • Не виправлення версії. Використання постачальника без зазначення версії призведе до раптових збоїв у майбутньому.
  • *`Дія: широкі дозволи, такі як ""`.** Порушує принцип найменших привілеїв.
  • Ігнорування неочікуваного "destroy". Застосування видалених рядків у Плані без питань.

Підсумовуючи

IaC перетворює інфраструктуру на повторюваний код, доступний для версій і аудиту; Найпоширенішим інструментом є Terraform. Штучний інтелект швидко створює заглушки HCL, але ви повинні надати версію, дані про хмару та правила безпеки. Безпомилкове правило в Terraform: бачити кожну зміну з планом, запитувати несподівані видалення, тримати секрети подалі від коду та зберігати стан у безпеці. Рядки знищення та заміни у вихідних даних плану є місцями, які слід прочитати найбільш уважно.

Аплікаційне завдання

Попросіть штучний інтелект створити невелику інфраструктуру (наприклад, відро для зберігання та політику доступу), використовуючи наведений вище шаблон «Створити ескіз інфраструктури». Тоді: (1) перевірте шаблон "перевірки" на наявність секретних або * дозволів, вбудованих у код; (2) якщо можливо, запустіть init + plan у тестовому обліковому записі та прочитайте вихід плану за допомогою шаблону «тлумачення плану»; (3) зверніть увагу на будь-які неочікувані видалення/зміни.

контрольний список

  • [ ] Я додав хмару, версію Terraform/провайдера та обмеження шифрування/мережі до свого запиту.
  • [ ] У коді немає секрету відкритого тексту; змінна точності значень.
  • [ ] Я звузив IAM/дозволи до мінімальних дозволів, * Я не використовував їх.
  • [ ] Я запустив план перед застосуванням і прочитав результат рядок за рядком.
  • [ ] Я переконався, що в Плані немає неочікуваного знищення/заміни.
  • [ ] Я впевнений, що стан зберігається в зашифрованому, заблокованому та обмеженому сервері.