Как провести code review Terraform-изменения, затрагивающего security group в production?

Короткий ответ

Проверяю не только синтаксис, а итоговые правила до и после изменения, привязанные ресурсы и соответствие least privilege. Для production нужны plan из CI, ограниченный CIDR, понятный владелец, проверка после apply и обратимый план.

Как это работает подробнее

Security group может быть общей для нескольких сервисов, поэтому локальная правка имеет больший blast radius. Динамические блоки Terraform также способны изменить или удалить правила, которые плохо заметны в исходном diff.

• Источник и назначение. Проверить, кто инициирует соединение и действительно ли сервис слушает указанный порт.
• Границы доступа. Предпочесть конкретные security group или CIDR вместо широкого 0.0.0.0/0.
• Зависимости. Найти все ресурсы, использующие группу, и оценить последствия удаления существующего правила.

Пример кода

security-group.tfКопировать

resource "aws_security_group_rule" "debug_access" {
  type              = "ingress"
  from_port         = 22
  to_port           = 22
  protocol          = "tcp"
  cidr_blocks       = ["0.0.0.0/0"]
  security_group_id = aws_security_group.app.id
}

Что использовать на практике

• Автоматизация. Запускать plan и policy checks в CI, запрещающие чувствительные порты для всего интернета.
• Временный доступ. Ограничивать CIDR офиса или VPN, задавать владельца и срок удаления правила.
• Проверка. После apply подтвердить нужное соединение и отсутствие неожиданных разрывов по метрикам и логам.

Подводные камни

• Критичный риск. Комментарий «временно» не делает правило безопасным и не гарантирует его удаление.
• Drift. Ручной hotfix в консоли без последующего изменения кода расходится с Terraform state и будет потерян при следующем apply.