Пайплайны IaC: plan на PR, policy-as-code и дрейф

Пайплайн plan/apply: дифф и есть артефакт ревью

Предыдущие уроки учили писать IaC — CloudFormation и CDK, Terraform с заблокированным удалённым бэкендом, операции над состоянием, модули по аккаунтам. Этот — о том, как запускать его безопасно, и форма, которая делает это безопасным, — GitOps для инфраструктуры: каждое изменение проходит через pull request, а с AWS говорит пайплайн, а не ноутбук.

Механизм разбивает рабочий процесс на два триггера пайплайна. На PR CI выполняет read-only половину: terraform plan (или cdk diff, или change set CloudFormation), затем публикует получившийся дифф комментарием в PR. На мердж в дефолтную ветку CI выполняет write-половину: terraform apply. Ключевая идея в том, что план и есть артефакт ревью. Ревьюер, апрувящий PR, апрувит не HCL в абстракции — он апрувит конкретный набор изменений, который напечатал план: эти три ресурса обновляются на месте, этот заменяется (удаляется и пересоздаётся), и больше ничего. Код-ревью только .tf-файлов необходимо, но недостаточно, потому что один и тот же код порождает разный план в зависимости от текущего состояния. План закрывает этот разрыв, показывая буквальную дельту, которая попадёт в аккаунт.

# .github/workflows/infra.yml — plan на PR, apply при мердже
name: infra
on:
  pull_request:        # PR: только plan, публикуем дифф для ревью
  push:
    branches: [main]   # мердж: apply

jobs:
  plan:
    if: github.event_name == 'pull_request'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: hashicorp/setup-terraform@v3
      - run: terraform init
      - run: terraform plan -no-color -out=tfplan
      - run: terraform show -no-color tfplan > plan.txt
      # …затем шаг публикует plan.txt как комментарий к PR (артефакт ревью)

  apply:
    if: github.event_name == 'push'
    runs-on: ubuntu-latest
    environment: prod   # гейт: требует ручной апрув до запуска джоба
    steps:
      - uses: actions/checkout@v4
      - uses: hashicorp/setup-terraform@v3
      - run: terraform init
      - run: terraform apply -auto-approve

Компромисс живёт в той строке environment: prod. Обязательный ручной апрув на apply безопасен — человек перечитывает план и кликает до того, как prod мутирует, — но медленнее, и ставит человека в цикл на каждое изменение. Авто-apply на мердж быстр и полностью GitOps-чист, но плохой мердж уходит прямо в продакшен без перечитывания плана. Режим отказа чистого авто-apply — мердж в 3 ночи, уничтожающий базу, потому что план показал замену -/+, которую никто не разглядел. Сеньорский дефолт асимметричен: plan на PR всегда, а apply под env-гейтом — авто-apply для dev (дёшево сломать, быстрая обратная связь), ручной апрув для prod. Ты покупаешь скорость там, где ошибки дёшевы, и гейт там, где они дороги.

CI к AWS без долгоживущих ключей: OIDC-федерация

Теперь пайплайн говорит с AWS на каждом мердже, а значит ему нужны учётки — и неверный способ их дать тот, с которого начинает большинство команд: вставить AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY долгоживущего IAM-пользователя в секреты CI. Этот ключ валиден, пока кто-то его не ротирует, а это часто никогда, и лежит в твоём CI-провайдере в ожидании утечки: в лог сборки через дамп env, через скомпрометированный сторонний action с доступом к секрету или через неправильно настроенный PR из форка. Когда утекает статический админ-ключ, радиус поражения — весь аккаунт, немедленно и бессрочно.

Механизм, убирающий постоянный секрет, — OIDC-федерация (OpenID Connect — открытый стандарт аутентификации поверх OAuth 2.0). GitHub Actions (и GitLab CI) могут выпустить короткоживущий OIDC-токен — подписанный JWT, описывающий запуск воркфлоу, — и обменять его в AWS STS через AssumeRoleWithWebIdentity на временные учётки. Ты один раз регистрируешь OIDC-провайдера GitHub в IAM, затем привязываешь к роли trust policy, которая говорит «выпускай учётки только для токена, чьи claims совпадают с этим репозиторием на этой ветке». Никакого секрета нигде не хранится; учётки, которые AWS отдаёт, истекают примерно через час (макс. сессия роли, настраивается), так что перехваченный из лога токен бесполезен через считаные минуты.

  apply:
    runs-on: ubuntu-latest
    environment: prod
    permissions:
      id-token: write     # разрешить джобу запрашивать OIDC-токен
      contents: read
    steps:
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::111122223333:role/ci-terraform-prod
          aws-region: eu-central-1
          # нигде нет AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY

Вся граница безопасности — это условие в trust policy. Сузь claim sub до конкретного репозитория и ref, чтобы форк, фича-ветка или воркфлоу другой организации не могли занять твою prod-роль:

{
  "Effect": "Allow",
  "Principal": { "Federated": "arn:aws:iam::111122223333:oidc-provider/token.actions.githubusercontent.com" },
  "Action": "sts:AssumeRoleWithWebIdentity",
  "Condition": {
    "StringEquals": {
      "token.actions.githubusercontent.com:aud": "sts.amazonaws.com",
      "token.actions.githubusercontent.com:sub": "repo:acme/infra:ref:refs/heads/main"
    }
  }
}

Компромисс мягкий — OIDC требует одноразовой настройки IAM (зарегистрировать провайдера, написать trust policy) и дисциплинированных условий по sub — против огромной выгоды: нет ротации, нет постоянного секрета, а учётка ограничена, короткоживуща и аудируема. Классический режим отказа — trust policy с sub вроде repo:acme/infra:* (любая ветка, любой ref): теперь любая ветка, в которую контрибьютор может запушить, включая атакующего, заведшего PR-ветку, может занять prod-роль. Прибей ветку, а для более сильной изоляции привяжи роль к GitHub-окружению (...:environment:prod), чтобы правила защиты самого окружения гейтили assume.

Policy-as-code: блокируй плохую инфру до apply

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

Инструменты группируются по экосистемам: OPA/Conftest, Checkov и tfsec/Trivy оценивают план Terraform в JSON; HashiCorp Sentinel — платный, нативный для Terraform вариант; AWS CloudFormation Guard (cfn-guard) проверяет шаблоны CloudFormation и любой JSON/YAML компактным DSL для правил. У всех этих инструментов одна задача: превратить предположение «кто-нибудь бы это заметил» в детерминированный гейт, который срабатывает до прода. Правила кодируют то, что ты никогда не хочешь отгрузить, — никаких публичных S3-бакетов, обязательное шифрование, никаких 0.0.0.0/0 на порт 22, обязательные теги для аллокации затрат, — и ловят весь класс багов, а не один экземпляр, который случайно заметил ревьюер.

# Правило cfn-guard: ни один S3-бакет не может быть публичным, шифрование обязательно
rule s3_must_be_private when Resources.*.Type == "AWS::S3::Bucket" {
  Resources.*[ Type == "AWS::S3::Bucket" ] {
    Properties.PublicAccessBlockConfiguration exists
    Properties.PublicAccessBlockConfiguration.BlockPublicAcls == true
    Properties.PublicAccessBlockConfiguration.IgnorePublicAcls == true
    Properties.BucketEncryption exists
  }
}

# Аналог Conftest/OPA для плана `terraform show -json`
package main
deny[msg] {
  r := input.resource_changes[_]
  r.type == "aws_security_group_rule"
  r.change.after.cidr_blocks[_] == "0.0.0.0/0"
  r.change.after.to_port == 22
  msg := sprintf("SSH open to the world on %s", [r.address])
}

Компромисс — трение против покрытия. Гейты политик ловят классы багов до прода и кодируют племенное знание как принудительные правила, но добавляют шаг, который проваливает сборки, а шумное правило с ложными срабатываниями приучает команду игнорировать или обходить его — худший исход, потому что регулярно обходимый гейт — это театр. Режим отказа — выкатить двадцать строгих правил в первый день: пайплайн краснеет на легитимных изменениях, люди начинают добавлять skip-аннотации, и слой политик мёртв в течение спринта. Выкатывай высокоценные правила первыми (публичный S3, открытый SSH, нешифрованные тома) в режиме warn, измеряй долю ложных срабатываний, затем переключай в enforce, когда они станут чистыми. Несколько принудительных правил, которым доверяют, лучше пятидесяти, которые обходят.

Дрейф и конкурентность: два способа, которыми кусает сам apply

Hook — это каноничный инцидент IaC, и у него есть имя: дрейф — реальность расходится с состоянием, потому что что-то изменило AWS вне пайплайна (хотфикс в консоли, скрипт, другая команда). Следующий план видит расхождение и хочет его откатить, чтобы соответствовать коду, молча отменяя ручное изменение; или, если ручное изменение конфликтует с конфигом, apply падает с ошибкой. В любом случае внепроцессное исправление потеряно или вызывает сюрприз. Механизм, чтобы быть впереди него, — плановое обнаружение дрейфа: гонять terraform plan (или нативное обнаружение дрейфа CloudFormation) по ночному расписанию, и если план непустой, когда ни один PR не открыт, алертить команду — дрейф, пойманный в 03:00 кроном, — это тикет; дрейф, пойманный внезапным откатом посреди деплоя, — это инцидент. Поймай его рано, и ты осознанно решаешь, кодифицировать ли изменение (вписать в конфиг) или откатить, вместо того чтобы пайплайн решал за тебя.

  drift:
    if: github.event_name == 'schedule'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: hashicorp/setup-terraform@v3
      - run: terraform init
      # detailed-exitcode: 0 = нет дрейфа, 2 = дрейф есть, 1 = ошибка
      - run: terraform plan -detailed-exitcode -no-color || echo "DRIFT" >> alert
      # …непустой план без открытого PR пейджит дежурного
on:
  schedule:
    - cron: "0 3 * * *"   # ночной скан дрейфа

Вторая опасность — конкурентность. Два пайплайна, применяющие одно и то же состояние одновременно, гоняются: оба читают одинаковое стартовое состояние, оба пишут, второй затирает первого, и файл состояния теперь не соответствует реальности — осиротевшие ресурсы, которые Terraform больше не отслеживает, счётчик serial, который больше не сходится. Защита — блокировка состояния из урока про Terraform: DynamoDB-лок (или use_lockfile) для S3-бэкенда и собственная серверная блокировка стека CloudFormation, — плюс сериализация apply на одно состояние в CI (concurrency-группа, чтобы два apply-джоба на одно состояние не пересекались). Режим отказа, который привносит сама блокировка: CI-джоб умирает посреди apply (раннер убит, сеть отвалилась) и оставляет лок удержанным, так что каждый последующий apply блокируется — Error acquiring the state lock — пока кто-то не разберётся. Опасный рефлекс — terraform force-unlock, чтобы «просто разблокировать команду». Если этот лок действительно принадлежит apply, всё ещё мутирующему AWS, force-unlock даёт второму apply работать конкурентно и по-настоящему портит состояние. Делай force-unlock только после того, как подтвердил, что удерживающий джоб действительно мёртв; застрявший лок раздражает, а ошибочный force-unlock — это испорченный файл prod-состояния.