Terraform CI Guardrails: Plan/Apply, Drift ve Policy Check

Terraform kullanan ekiplerde iki uç yaklaşım görürsünüz:

• “Her PR’da apply yapalım, hızlıyız.” (risk büyür)
• “Apply sadece haftada bir, değişiklikten korkuyoruz.” (hız biter)

İyi bir CI tasarımı; plan ile apply’ı ayırır, drift’i görünür kılar ve policy-as-code ile “yanlış değişikliği” daha merge olmadan durdurur. Bu yazı; prod altyapı değişiklikleri için sahada işleyen guardrail setini, ürün bağımsız prensiplerle anlatır.

Hedef: “PR = karar”, “Apply = eylem”

PR’da amaç:

• Değişikliği anlamak (review)
• Etkisini görmek (plan)
• Politika uyumunu doğrulamak (policy check)

Apply’da amaç:

• Onaylanmış değişikliği kontrollü uygulamak
• Geri dönüş planını hazır tutmak

Bu ayrım; hem güvenlik hem operasyonel olgunluk için temel.

Minimum guardrail seti

Benim “minimum viable” guardrail’lerim:

1. Format + validate (her PR’da)
2. Plan (her PR’da; ortam bazlı)
3. Policy-as-code (plan çıktısı üzerinden)
4. Drift detection (günlük/haftalık)
5. Apply sadece korumalı koşullarda (manual onay + branch koruması)

Plan stratejisi: Hangi ortama plan alacağım?

Tek bir “prod plan” yaklaşımı her repo için doğru değil. Pratik seçim:

• Küçük ekip/az ortam: PR’da dev + prod plan
• Büyük ekip/çok ortam: PR’da dev plan, merge sonrası prod plan + onay

Buradaki karar; secrets, maliyet ve saldırı yüzeyi ile ilgilidir. Prod plan için prod credential’ı PR context’inde vermek bazı kurumlarda kabul edilemez.

Policy check: Plan’ı okuyup “dur” diyebilmek

Policy check’in amacı:

• “Bu değişiklik teknik olarak çalışır” yetmez
• “Bu değişiklik kuruma uygun mu?” sorusunu otomatik cevaplamak

Örnek policy kuralları:

• Public S3 bucket yasak
• Security group 0.0.0.0/0 inbound kısıtlı
• KMS encryption zorunlu
• Prod DB instance class limitli
• Tag standardı zorunlu (cost center, owner)

Araç isimleri değişebilir; önemli olan plan çıktısından kaynağın niyetini okumak.

Drift: “Gerçek dünya” ile “repo” farklıysa ne olacak?

Drift; çoğu IaC kazasının başlangıcıdır:

• Console’dan hotfix yapıldı (ve unutuldu)
• Incident sırasında bypass edildi
• Automation dışında bir sistem değiştirdi

Drift detection için iki pratik kural:

• Düzenli plan al (apply etme)
• Drift varsa issue aç + owner’a ata

Kritik: Drift’i “suç” gibi değil, “sinyal” gibi yönetin. Drift; ya süreç açığıdır ya da IaC kapsamı eksiktir.

Apply kontrolü: Kim, ne zaman, hangi koşulla?

Prod apply için sahada en güvenli model:

• Apply sadece main (veya release branch) üzerinden
• Manual approval (en az 2 kişi)
• Apply job’ı kısıtlı runner’da (network + IAM)
• State backend lock ve audit açık

Ek guardrail’ler:

• “Destructive change” uyarısı (plan parse ile)
• “Maintenance window” kontrolü
• Slack/Teams bildirimleri + değişiklik kaydı

Çok repo / çok workspace: Ölçek büyüyünce ne değişir?

Ölçek büyüyünce iki risk artar:

• Workspace sayısı (kompleksite)
• Yetki alanı (blast radius)

Bu noktada iyi pratikler:

• Modül versiyonlama (registry veya git tag)
• Environment klasörleri (ayrı state)
• “Per-service” ownership ve review
• Kademeli rollout (önce staging, sonra prod)

Kapanış: Guardrail’leri ‘pipeline’ olarak düşünün

Terraform CI’da amaç; tek bir “mükemmel YAML” yazmak değil, riskli değişiklikleri erken yakalamak ve prod uygulamayı kontrollü hale getirmektir.

Başlangıç için önerdiğim küçük adımlar:

• PR’da fmt + validate + plan
• Plan üzerinden policy check
• Drift plan’ını düzenli çalıştır
• Prod apply’ı manual onay + korumalı runner ile sınırla