Инфраструктура как код: Terraform, Ansible, проверки до применения

Зачем это нужно

• Инфраструктура как код делает конфигурацию воспроизводимой и проверяемой.
• Ошибка в описании тиражируется на все окружения, поэтому проверки до применения критичны.
• Навык востребован в любой современной инфраструктуре.

Теория

Terraform описывает ресурсы декларативно, хранит состояние и вычисляет план изменений. Основные риски: открытые для всего мира сетевые правила, отсутствие шифрования хранилищ и передач, публичные хранилища объектов, избыточные права сервисных учётных данных, открытые базы данных, отсутствие резервного копирования, незащищённый доступ к управлению. Состояние содержит чувствительные данные: его нужно хранить в защищённом месте с шифрованием и ограничением доступа.

Ansible описывает конфигурацию шагов и применяет её по сети. Риски: избыточные права, секреты в задачах и переменных без защищённого хранилища, неидемпотентные задачи (приводят к дрейфу состояния), доверие к непроверенным модулям, отсутствие проверок перед применением. Практики: модули с явными параметрами, безопасное хранение секретов, режим проверки, идемпотентность, версионирование описаний.

Проверки до применения: статический анализ конфигураций (например, правила на открытые порты, отсутствие шифрования, публичный доступ), план изменений с обязательным ревью, политика запрета опасных параметров, разделение окружений и разных учётных данных, автоматическое выявление дрейфа между описанием и фактическим состоянием. Полезно фиксировать исключения с обоснованием: запрет без возможности исключения приводит к обходу процесса.

Ключевые концепции

Состояние Terraform

Файл описания созданных ресурсов: содержит чувствительные данные, требует защиты.

План изменений

Предварительный расчёт изменений: обязательное ревью перед применением.

Дрейф состояния

Расхождение между описанием и фактической инфраструктурой.

Правило политики

Проверка конфигурации до применения: например, запрет публичного доступа.

Идемпотентность задач

Повторное применение не меняет состояние лишний раз.

Разделение окружений

Отдельные учётные данные и ресурсы для сред: ограничивает радиус поражения.

Инструменты

• Terraform и средства анализа конфигураций (например, проверки безопасности конфигурации).
• Ansible с хранилищем секретов и режимом проверки.
• Средства проверки политик в конвейере.
• Средства контроля дрейфа и инвентаризации ресурсов.
• Хранилища состояния с шифрованием и контролем доступа.

Практика в легальных лабораториях

• Опишите в Terraform учебную инфраструктуру и проверьте план изменений глазами безопасности.
• Добавьте проверку политики: запретить публичный доступ к хранилищу и открытые правила сети.
• Настройте защищённое хранение состояния и убедитесь, что доступ ограничен.
• Напишите идемпотентную задачу Ansible и примените её дважды, сравнив результат.
• Смоделируйте дрейф и настройте его обнаружение.

Защита, детект и защитные меры

• Проверяйте конфигурации автоматически до применения и требуйте ревью плана.
• Защищайте состояние и файлы с параметрами: это чувствительные данные.
• Разделяйте окружения и учётные данные.
• Отслеживайте дрейф и разбирайте расхождения.

Правовая рамка и этика

• Не создавайте облачные ресурсы без контроля затрат: включите оповещения о бюджете.
• Не храните чувствительные параметры в открытом виде в репозиториях.

Типичные ошибки

• Применять изменения без чтения плана.
• Хранить состояние в открытом репозитории или без шифрования.
• Использовать одни и те же учётные данные во всех окружениях.
• Писать неидемпотентные задачи и получать неожиданные изменения.

Чек-лист «умею»

• Умею читать и проверять план изменений.
• Настраиваю автоматические проверки политик.
• Защищаю состояние и параметры.
• Пишу идемпотентные задачи.
• Отслеживаю дрейф состояния.

Вопросы на интервью

• Какие проверки вы добавите перед применением конфигурации?
• Почему состояние Terraform требует защиты?
• Как вы обнаружите дрейф конфигурации?

Источники и первоисточники

• Terraform — документация
• Ansible — документация
• CIS Benchmarks