Terraform Plan Politikaları için OPA Pipeline

Infrastructure as Code kullanan ekiplerin sık düştüğü tuzak, terraform plan çıktısını sadece insan gözüne bırakmaktır. Kod incelemesi değerlidir; fakat etiket standardı, internetten erişilebilir kaynaklar, bölge seçimi, maliyet sınırı veya şifreleme zorunluluğu gibi kuralları her PR’da elle kontrol etmek sürdürülebilir değildir. OPA tabanlı bir pipeline, plan çıktısını politika kararına çevirerek değişiklikleri insan yorumuna ek bir güvenlik katmanından geçirir.

Temel akış

Amaç, Terraform kodunu apply aşamasından önce iki kapıdan geçirmek:

1. terraform plan ile oluşacak değişikliği üretmek
2. Plan JSON çıktısını OPA policy seti ile değerlendirmek

Bu yaklaşım sayesinde “bulut hesabında ne olacak?” sorusu ile “bu değişikliğe izin var mı?” sorusu birbirinden ayrılır ama aynı pipeline içinde birleşir.

Plan çıktısını JSON olarak üretmek

İlk adım standarttır:

terraform init
terraform plan -out=tfplan.binary
terraform show -json tfplan.binary > tfplan.json

OPA veya Conftest tarafı genelde tfplan.json üzerinden çalışır. Önemli nokta, policy motorunun HCL dosyasına değil gerçek plan sonucuna bakmasıdır. Çünkü modül genişlemesi, değişken çözümü ve provider davranışları ancak plan aşamasında netleşir.

Örnek politika senaryoları

Başlangıç için yüksek değer üreten kurallar şunlardır:

• Public IP alan üretim kaynağı reddedilsin
• Zorunlu etiketler yoksa plan başarısız olsun
• Şifreleme kapalı storage kaynakları engellensin
• Belirli bölgeler dışına kaynak açılması reddedilsin
• Yüksek maliyetli instance tipleri için uyarı üretilebilsin

Basit bir Rego örneği:

package terraform.guardrails

deny[msg] {
  some rc in input.resource_changes
  rc.type == "aws_s3_bucket"
  after := rc.change.after
  after.tags.environment == "production"
  not after.server_side_encryption_configuration
  msg := sprintf("production bucket encryption missing: %s", [rc.address])
}

Bu kural tek başına yeterli değildir ama yaklaşımı net gösterir: kaynak değişikliği, hedef durum ve iş bağlamı birlikte değerlendirilir.

Pipeline tasarımı

CI akışı genelde şu sırayla kurulabilir:

1. Format ve validate
2. Plan üretimi
3. Plan JSON çıkarımı
4. OPA veya Conftest policy değerlendirmesi
5. Sonuçların PR yorumuna yazılması

Bu akışta policy sonucu sadece “geçti/kaldı” olmamalıdır. Hangi kaynağın hangi kurala takıldığı PR üzerinde açık görünmelidir. Aksi halde geliştirici için düzeltme döngüsü uzar.

Politika setini yönetmek

Başarısız policy projelerinin çoğunda teknik değil yönetişim sorunu vardır. Şunlar netleşmelidir:

• Policy deposu uygulama kodundan ayrı mı?
• Versiyonlama nasıl yapılacak?
• Acil istisna mekanizması var mı?
• Uyarı ile engelleme kuralları nasıl ayrılıyor?

Tüm kuralları ilk günden bloklayıcı yapmak ekiplerde tepki üretir. Sağlıklı model, önce görünürlük sağlamak sonra kritik kuralları kapı haline getirmektir.

Kurumsal kullanım için ek kontroller

Kurumsal yapılarda sadece güvenlik değil platform ve finans ekipleri de policy üretir. Bu yüzden kuralları üç gruba ayırmak işe yarar:

• Güvenlik guardrail’leri
• Operasyon ve gözlemlenebilirlik zorunlulukları
• Maliyet ve yönetişim kuralları

Örneğin her üretim kaynağında log toplama ajanı veya izleme etiketi zorunlu tutulabilir. Böylece IaC doğrulaması ile observability standardı da birlikte taşınır.

Sonuç

Terraform plan çıktısını OPA pipeline üzerinden geçirmek, IaC pratiğini “kod yaz ve um” seviyesinden çıkarır. En büyük kazanım, platform bilgisini insan hafızasından alıp tekrar edilebilir politika setine dönüştürmektir. Küçük bir kural kümesiyle başlayıp plan tabanlı görünürlük oluşturursanız, zamanla güvenlik ve yönetişim kararlarını çok daha az sürtünmeyle standardize edebilirsiniz.