Ünite 3 / 11

Altyapıyı Kod Olarak Yönetmek: Terraform ve IaC ile Yapay Zeka

Kazanimlar:

  • IaC kavramını ve Terraform'un çalışma döngüsünü (init, plan, apply, state, module) kavrayıp yapay zekaya güvenli HCL taslakları ürettirebilme
  • Her değişikliği apply'dan önce plan ile denetleyip beklenmedik destroy/replace satırlarını yakalayabilme
  • Secret'ları koddan uzak tutma, state'i güvenli saklama ve IAM izinlerini en aza indirme ilkelerini uygulayabilme

Eskiden sunucu kurmak, bir bulut panelinde tıklaya tıklaya ilerlemekti: bir sanal makine oluştur, ağ ayarını yap, güvenlik kuralını ekle. Bu yöntem yavaş, hataya açık ve tekrarlanamazdı — aynı ortamı ikinci kez kurmak neredeyse imkânsızdı. Bugün altyapı kod olarak yönetiliyor. IaC (Infrastructure as Code — altyapının kod olarak tanımlanması), sunucu, ağ, veritabanı gibi bulut kaynaklarını el ile değil, metin dosyalarında tarif etme yaklaşımıdır. Bu dosyalar sürüm kontrolünde (Git) durur; kim, ne zaman, neyi değiştirmiş görebilirsiniz; aynı altyapıyı bir komutla defalarca, birebir aynı şekilde kurabilirsiniz.

En yaygın IaC aracı Terraform'dur. Terraform, HCL (HashiCorp Configuration Language — Terraform'un yapılandırma dili) adında okunabilir bir dille yazdığınız tanımları alıp bulut sağlayıcının (AWS, Azure, GCP) API'sine çevirir ve kaynakları oluşturur. YZ, HCL'yi çok iyi bilir ve karmaşık bloğları hızla üretir. Ama IaC'de bir hatanın maliyeti büyüktür: yanlış bir tanım koca bir üretim veritabanını silebilir. Bu yüzden Terraform'da altın kural, her değişikliği uygulamadan önce `plan` ile görmektir.

Terraform'un çalışma döngüsü

Terraform üç temel komutla çalışır — bunları bilmek YZ çıktısını denetlemenin ön koşuludur:

  • `terraform init`: Projeyi başlatır, gerekli sağlayıcı eklentilerini indirir.
  • `terraform plan`: Mevcut durum ile istenen durumu karşılaştırıp ne ekleneceğini, ne değişeceğini, ne silineceğini gösterir. Hiçbir şeyi uygulamaz. En kritik güvenlik adımıdır.
  • `terraform apply`: Plan'ı gerçekten uygular, kaynakları oluşturur/değiştirir.

Ek olarak iki kavram hayatidir. State (durum dosyası): Terraform'un yönettiği kaynakların güncel halini tuttuğu dosyadır; genellikle uzak ve kilitli (locked) bir depoda saklanır ki iki kişi aynı anda değiştirip bozmasın. Module (modül): Tekrar kullanılabilir yapılandırma paketidir; örneğin "bir ağ kur" modülünü birçok projede kullanabilirsiniz.

İpucu: Bir Terraform çıktısında en tehlikeli işaret, plan çıktısında destroy (yok et) veya -/+ (yerine yenisini koy) satırlarıdır. Bunlar kaynağın silineceği anlamına gelir. Bir plan'da beklemediğiniz bir destroy görürseniz asla apply yapmayın, önce neden çıktığını anlayın.

Adım adım: YZ ile IaC yazmak

  1. İstenen altyapıyı netleştir. "eu-central-1'de bir VPC, iki alt ağ, bir güvenlik grubu ve bir t3.micro EC2" gibi somut ol.
  2. Sağlayıcı ve sürümü belirt. Hangi bulut, hangi Terraform ve provider sürümü? Sürüm belirtmezsen YZ eski/uyumsuz sözdizimi verebilir.
  3. HCL taslağını ürettir. Değişkenleri (variable) ve çıktıları (output) da iste.
  4. Secret'ı dışarı çıkar. Parola, anahtar gibi değerler koda değil, değişken ve secret kasasına gitsin.
  5. `init` + `plan` çalıştır. Plan çıktısını satır satır oku; beklenmedik silme var mı bak.
  6. Küçük başla, kademeli uygula. Önce izole bir test hesabında/ortamında apply et.

Güvenlik: IaC'ye özgü riskler

IaC güçlü olduğu kadar risklidir. Üç kritik nokta:

  1. State dosyasında secret olur. Terraform state, bazen veritabanı parolası gibi hassas değerleri düz metin tutar. State'i asla halka açık bir depoya koymayın; şifreli, erişimi kısıtlı uzak backend kullanın.
  2. Secret'ları HCL'ye gömmeyin. password = "prod123" gibi satırlar Git geçmişine kalıcı olarak yazılır. Bunun yerine değişken kullanıp değeri çalışma anında ortam değişkeni (TF_VAR_...) veya secret kasasından verin.
  3. Çok geniş IAM izni. YZ bazen "çalışsın" diye Action: "*" (her şeye izin) gibi bloklar üretir. Bu bir güvenlik açığıdır; izni gereken minimuma daraltın.
Dikkat: Git geçmişine bir kez giren secret, dosyayı silseniz bile geçmişte kalır ve ele geçirilebilir. Yanlışlıkla commit ederseniz secret'ı derhal iptal edip yenileyin (rotate); sadece silmek yeterli değildir.

Riskli plan işaretleri tablosu

Plan çıktısı

Anlamı

Ne yapmalı

+ create

Yeni kaynak eklenecek

Genellikle güvenli, yine de gözden geçir

~ update in-place

Kaynak yerinde değişecek

Etkiyi doğrula (kesinti olur mu?)

-/+ replace

Silinip yeniden oluşturulacak

DİKKAT: veri kaybı olabilir

- destroy

Kaynak yok edilecek

DUR: beklemiyorsan asla apply etme

Üç mini vaka

Vaka 1 — 2 günlük iş 3 saatte. Bir ekip yeni bir test ortamını (VPC, alt ağlar, RDS veritabanı, ECS kümesi) kurmak için Terraform yazacaktı ama HCL'ye yeni geçmişlerdi. YZ'ye mimariyi ve sürümleri tarif edip modüler bir taslak ürettiler. Her modülü plan ile doğrulayıp 3 saatte ayağa kaldırdılar; elle deneme-yanılma iki günlerini alacaktı.

Vaka 2 — plan bir silmeyi yakaladı. Bir mühendis, YZ'nin ürettiği bir güncelleme kodunu apply etmeden plan çalıştırdı. Çıktıda üretim veritabanı için -/+ replace vardı — YZ, değiştirilemez bir alanı değiştirmeye çalışmış, bu da veritabanının silinip yeniden yaratılması demekti. Mühendis apply'ı durdurup değişikliği güvenli yönteme çevirdi. plan alışkanlığı bir felaketi önledi.

Vaka 3 — gömülü secret sızıntısı. Bir junior, YZ'nin verdiği db_password = "S3cret!" satırını olduğu gibi commit edip push etti. Kod incelemesinde (code review) yakalandı; parola derhal iptal edilip değiştirildi, değer bir değişkene taşındı ve secret kasasından beslendi. Ders: HCL'de asla düz metin secret bulunmaz.

Dört kopyalanabilir şablon

1) Altyapı taslağı üretme:

Terraform (sürüm ~> 1.7) ile [BULUT: AWS] üzerinde şu altyapıyıyaz: [KAYNAK LİSTESİ]. Bölge [X]. Kurallar:- Tüm hassas değerleri variable yap, HCL'ye gömme.- Sağlayıcı sürümünü sabitle (required_providers).- IAM izinlerini en aza indir, "*" kullanma.- output olarak [X, Y] döndür.Kodu modüler ve açıklamalı ver.

2) Plan çıktısını yorumlatma:

Aşağıdaki 'terraform plan' çıktısını analiz et. Bana:(1) hangi kaynakların eklendiğini/değiştiğini/SİLİNDİĞİNİ,(2) veri kaybı veya kesinti riski taşıyan satırları,(3) apply etmeden önce sormam gereken 3 soruyu listele.Plan: [ÇIKTI]

3) Var olan HCL'yi güvenlik açısından incele:

Şu Terraform kodunu güvenlik açısından denetle: gömülü secret,aşırı geniş IAM izni, açık ağ kuralı (0.0.0.0/0), şifrelenmemişdepolama var mı? Her bulguyu önem sırasıyla ve düzeltmesiyle yaz.Kod: [HCL]

4) Tekrarlı kodu modüle çevir:

Aşağıdaki tekrarlayan Terraform kodunu yeniden kullanılabilir birmodule'e dönüştür: hangi değerler variable olmalı, module arayüzünasıl olmalı? Örnek kullanımını da göster. Kod: [HCL]

Zayıf prompt / Güçlü prompt

Zayıf: "Terraform ile bir veritabanı oluştur."

Sonuç: hangi bulut, hangi motor, hangi sürüm, şifreli mi belirsiz; YZ eski sözdizimiyle, parolayı koda gömen, herkese açık bir örnek verebilir.

Güçlü: "Terraform ~> 1.7 ile AWS'de bir RDS PostgreSQL 15 örneği oluştur. Parola variable olsun, koda gömme. Depolama şifreli, yalnızca özel alt ağdan erişilebilir olsun, herkese açık olmasın. provider sürümünü sabitle. output olarak endpoint'i döndür."

Fark: ikinci istem motoru, sürümü, şifrelemeyi, ağ kısıtını ve secret kuralını verir — çıktı güvenli ve prod'a yakındır.

Sık yapılan hatalar

  • `plan` yapmadan `apply` etmek. IaC'de en pahalı hata; her zaman önce plan.
  • Secret'ı HCL'ye gömmek. Git geçmişine kalıcı sızıntı yaratır.
  • State'i güvensiz saklamak. Şifresiz, kilitsiz, halka açık state felakettir.
  • Sürüm sabitlememek. Sürüm belirtmeden provider kullanmak, gelecekte ani bozulmalara yol açar.
  • *`Action: ""` gibi geniş izin.** En az yetki ilkesini ihlal eder.
  • Beklenmedik `destroy`'u görmezden gelmek. Plan'daki silme satırlarını sorgulamadan uygulamak.

Özetle

IaC, altyapıyı tekrarlanabilir, sürümlenebilir ve denetlenebilir kod haline getirir; en yaygın aracı Terraform'dur. YZ, HCL taslaklarını hızla üretir ama sürümü, buluta özgü ayrıntıları ve güvenlik kurallarını sizin vermeniz gerekir. Terraform'da şaşmaz kural: her değişikliği plan ile görmek, beklenmedik silmeleri sorgulamak, secret'ları koddan uzak tutmak ve state'i güvenli saklamak. Bir plan çıktısındaki destroy ve replace satırları en dikkatli okunması gereken yerlerdir.

Uygulama görevi

YZ'den yukarıdaki "Altyapı taslağı üretme" şablonuyla küçük bir altyapı (örneğin bir depolama kovası/bucket ve bir erişim politikası) ürettirin. Sonra: (1) kodda gömülü secret veya * izni olup olmadığını "güvenlik incelemesi" şablonuyla denetletin; (2) mümkünse bir test hesabında init + plan çalıştırıp plan çıktısını "plan yorumlatma" şablonuyla okuyun; (3) beklenmedik bir silme/değişiklik olup olmadığını not edin.

Kontrol listesi

  • [ ] İstememe bulut, Terraform/provider sürümü ve şifreleme/ağ kısıtlarını ekledim.
  • [ ] Kodda hiçbir düz metin secret yok; hassas değerler variable.
  • [ ] IAM/izinleri en az yetkiye daralttım, * kullanmadım.
  • [ ] apply'dan önce plan çalıştırıp çıktıyı satır satır okudum.
  • [ ] Plan'da beklenmedik destroy/replace olmadığını doğruladım.
  • [ ] State'in şifreli, kilitli ve erişimi kısıtlı bir backend'de tutulduğundan eminim.