Kazanimlar:
- Yapay zeka ile IaC (Terraform, Ansible) kodunu en dar izin ve güvenli varsayılanlarla üretip bildirimsel yaklaşımı kavrayabilme
- Plan/check çıktısını uygulamadan önce okuyup silme ve yeniden oluşturma (forces replacement) satırlarını yakalayarak veri kaybını önleyebilme
- State dosyasını şifreli, kilitli, uzak backend'de tutup sır sızıntısını önleme ve değişiklikleri küçük, tersine çevrilebilir adımlara bölme becerisi kazanabilme
Altyapının Kod Olarak Yönetimi (IaC): YZ ile Terraform, Ansible ve Plan Denetimi
Eskiden bir sunucu kurmak elle tıklamalarla, komutlarla ve kişisel notlarla yapılırdı; sonuç, kimsenin tam olarak nasıl kurulduğunu bilmediği, tekrar üretilemeyen "kar tanesi" sunuculardı. Altyapının Kod Olarak Yönetimi (IaC — Infrastructure as Code), bu kaosu bitiren yaklaşımdır: sunucular, ağlar, güvenlik kuralları elle değil, versiyonlanabilir metin dosyaları (kod) ile tanımlanır. Bu kodu çalıştırınca altyapı tam olarak yazdığınız gibi kurulur — her seferinde aynı, belgeli ve tekrarlanabilir. En yaygın araçlar bulut altyapısı için Terraform ve CloudFormation, sunucu yapılandırması için Ansible'dır. İşte YZ, bu IaC kodunu yazmakta, açıklamakta ve gözden geçirmekte çok yeteneklidir. Ama IaC'nin gücü aynı zamanda tehlikesidir: tek bir yanlış satır tüm bir altyapıyı silebilir; bu yüzden YZ kod yazar, siz "plan"ı okur, onaylar ve uygularsınız.
Bu ünitede declarative (bildirimsel — "ne olsun"u tanımlama) yaklaşımı, plan/apply ayrımını, state (durum) güvenliğini ve idempotency'yi; YZ ile IaC üretimini ve en kritik beceri olan "plan denetimi"ni öğreneceksiniz.
Bildirimsel düşünmek: "ne olsun", "nasıl yapılsın" değil
IaC araçlarının çoğu bildirimseldir: siz sistemin son halini tarif edersiniz ("3 web sunucusu, 1 yük dengeleyici olsun"), aracın kendisi bu hale nasıl ulaşacağını hesaplar. Bu, script yazmaktan (adım adım "şunu yap, sonra bunu yap") farklıdır. Bildirimsel yaklaşımın büyük avantajı idempotency'dir: kodu on kez çalıştırsanız da sonuç aynıdır, çünkü araç "istenen hal zaten var mı" diye bakar, varsa dokunmaz. YZ'ye IaC yazdırırken bu farkı hatırlayın: ona "şu komutları çalıştır" değil, "şu altyapı hali olsun" dedirtirsiniz.
Plan/apply: en hayati güvenlik korkuluğu
IaC'nin hayat kurtaran özelliği plan adımıdır. Terraform'da terraform plan, Ansible'da --check modu, kodu çalıştırmadan önce "eğer uygularsam ne değişecek" diye bir önizleme üretir: "2 kaynak eklenecek, 1 değişecek, 0 silinecek". Bu, uygulamadan önce niyetinizi gerçekle karşılaştırmanızın tek yoludur. Kritik kural: planı okumadan asla apply etmeyin. Özellikle "destroy" (silme) satırlarına bakın; bir yazım hatası yüzünden "1 değişecek" yerine "12 silinecek" görürseniz, plan sizi felaketten kurtarmıştır. YZ'ye kodu yazdırdıktan sonra "plan çıktısını benimle satır satır incele, silme/yeniden oluşturma içeren her satırı işaretle" dedirtin.
Dikkat: Terraform'da bazı değişiklikler bir kaynağı "yerinde güncelleme" yerine "yok edip yeniden oluşturma" (destroy and recreate) olarak yapar. Bu, bir veritabanı için veri kaybı demektir. Plan çıktısında -/+ veya "forces replacement" ifadelerini görmezden gelmek en pahalı hatalardan biridir.
State dosyası: sırların ve gerçeğin kaydı
Terraform gibi araçlar, yönettikleri altyapının mevcut durumunu bir state dosyasında tutar. Bu dosya iki nedenle kritiktir. Birincisi, sırları içerebilir (veritabanı parolaları, anahtarlar düz metin olarak state'e düşebilir); bu yüzden state'i asla halka açık bir depoya veya YZ'ye yapıştırmayın, şifreli ve erişimi kısıtlı bir uzak depoda (remote backend) tutun. İkincisi, state bozulur veya kaybolursa araç gerçek altyapı ile hayalindeki altyapı arasındaki bağı yitirir; bu yüzden state'in yedeği ve kilit mekanizması (aynı anda iki kişinin bozmasını önleyen lock) şarttır.
Adım adım: YZ ile güvenli IaC
- Niyeti ve sağlayıcıyı belirt. "AWS'de, Terraform ile, şu bölgede, şu boyutta 2 sunucu ve bir güvenlik grubu." Bulut, araç ve sürüm netse YZ doğru sözdizimi üretir.
- Güvenlik varsayılanlarını iste. "Açık güvenlik grubu açma, şifrelemeyi aç, sırları değişkene çıkar, herkese açık erişim verme." YZ varsayılan olarak gevşek örnekler üretebilir.
- Kodu oku ve anla. Her kaynağı, her izni satır satır anlayın. Anlamadığınız bir izni uygulamayın.
- Plan al ve denetle. plan/--check çalıştırın, çıktıyı YZ ile inceleyin, silme ve yeniden oluşturma satırlarını işaretleyin.
- Küçük ve tersine çevrilebilir uygula. Büyük bir değişikliği tek seferde değil, küçük parçalar halinde uygulayın. Her adımda geri dönüş yolunu bilin.
- State'i koru. Uzak, şifreli backend ve kilit kullanın; state'i asla dışarı sızdırmayın.
Üç mini vaka
Vaka 1 — Plan bir veritabanını kurtardı. Bir mühendis, YZ ile ürettiği Terraform koduyla bir veritabanının boyutunu büyütmek istedi. terraform plan çıktısında "1 to change" beklerken "1 to destroy, 1 to add" gördü — seçtiği parametre yerinde güncelleme değil yeniden oluşturma tetikliyordu, yani tüm veri silinecekti. Plan denetimi, geri dönüşü olmayan bir veri kaybını uygulanmadan önce durdurdu.
Vaka 2 — Gevşek varsayılandan dönüş. Bir ekip, YZ'den bir güvenlik grubu (firewall) kodu istedi. YZ, örneği çalıştırmak için basit olsun diye 0.0.0.0/0 yani "internetteki herkese açık" bir kural üretti. Mühendis kodu okurken bunu fark etti ve erişimi yalnızca kurum IP aralığına daralttı. Denetlenmeden uygulansaydı, veritabanı tüm internete açık olacaktı.
Vaka 3 — State sızıntısı önlendi. Bir kıdemsiz üye, bir Terraform sorununu çözmek için terraform.tfstate dosyasını olduğu gibi halka açık bir araca yapıştırmak üzereydi. Kıdemli mühendis durdurdu: state içinde düz metin bir veritabanı parolası vardı. Bunun yerine sorunu tarif eden, sırlar çıkarılmış bir özet paylaşıldı ve state uzak şifreli backend'e taşındı.
Dört kopyalanabilir şablon
1) IaC kaynağı üretme (güvenli varsayılan):
Rolün: kıdemli bulut altyapı mühendisi. [Bulut, ör. AWS] için[araç, ör. Terraform] kodu üret. Amaç: [amaç].Güvenlik kuralları: herkese açık (0.0.0.0/0) erişim AÇMA;en dar izinle başla; şifrelemeyi aç; sırları değişkene çıkar,koda gömme; silme/yeniden oluşturmaya yol açabilecek ayarlarıişaretle. Her kaynağı kısa yorumla açıkla.
2) Plan çıktısı denetimi:
Aşağıda bir [Terraform plan / Ansible check] çıktısı var.Bana: (1) kaç kaynak eklenecek/değişecek/silinecek, (2) verikaybı riski taşıyan "destroy" veya "forces replacement"satırlarını ayrıca işaretle, (3) beklenmedik veya tehlikeligörünen değişiklikleri sırala. Çıktı: [plan]
3) IaC kod güvenlik incelemesi:
Aşağıdaki IaC kodunu güvenlik açısından incele:(1) fazla geniş erişim/izin var mı, (2) şifreleme kapalı mı,(3) koda gömülü sır var mı, (4) genel erişime açık kaynakvar mı? Her bulgu için düzeltme öner. Kod: [maskeli kod]
4) Değişikliği güvenli parçalara bölme:
Şu büyük altyapı değişikliğini [açıklama] tek seferdeuygulamak istemiyorum. Bunu geri dönüşü kolay, küçük vebağımsız adımlara böl. Her adım için: ne değişir, plan'daneye dikkat etmeliyim, sorun çıkarsa nasıl geri alırım?
Zayıf prompt / Güçlü prompt
Zayıf prompt:
AWS'de bir sunucu oluşturan Terraform kodu yaz.
Bölge, boyut, güvenlik, ağ, şifreleme belirsiz. YZ çalışsın diye en gevşek, en açık varsayılanları üretir — üretime alınırsa güvenlik açığı olur.
Güçlü prompt:
Rolün: kıdemli bulut altyapı mühendisi. AWS eu-central-1'deTerraform ile bir web sunucusu tanımla: t3.small, sadecekurum IP aralığından (değişkenle vereceğim) 443 portu açık,disk şifreli, herkese açık erişim yok, etiketler zorunlu.Sırları değişkene çıkar. Kod sonrası: uygulamadan önce plan'dadikkat etmem gereken 3 satır tipini söyle ve geri dönüşyolunu açıkla.
Aşama
Risk
Güvenlik korkuluğu
Kod yazma
Gevşek varsayılan (herkese açık)
En dar izin + okuma
Plan/check
Farkında olmadan silme
Plan denetimi, destroy işaretleme
Apply
Büyük tek seferlik değişiklik
Küçük, tersine çevrilebilir adımlar
State yönetimi
Sır sızıntısı, bozulma
Uzak şifreli backend + kilit
Sık yapılan hatalar
- Plan okumadan apply etmek. Plan, silme ve yeniden oluşturmayı önceden gösterir; atlanırsa veri kaybı kaçınılmaz olur.
- Gevşek varsayılanı fark etmemek. YZ örnekleri sık sık 0.0.0.0/0 üretir; üretime taşınırsa tüm internete açık kaynak demektir.
- State'i sızdırmak. State dosyasını YZ'ye veya açık depoya vermek düz metin sırları ifşa eder.
- Sırları koda gömmek. Parolayı IaC koduna yazmak, kod versiyon geçmişinde kalıcılaşan bir sızıntıdır.
- Yeniden oluşturmayı güncelleme sanmak. forces replacement satırını görmezden gelmek veritabanlarında veri kaybına yol açar.
İpucu: Plan çıktısını bir yapay zekaya incelemesi için verirken bile, nihai kararı plan metnine değil kendi bilginize dayandırın. YZ planı özetler ve riskli satırları işaretler; ama "bu silme kabul edilebilir mi" sorusunun cevabı iş bağlamınızdadır.
Özetle
IaC, altyapıyı elle tıklamalar yerine versiyonlanabilir kodla yöneterek tekrarlanabilirlik ve belgelilik getirir. YZ bu kodu yazmakta, açıklamakta ve güvenlik açısından incelemekte güçlü bir ortaktır. Ama IaC'nin gücü tehlikesidir: tek satır tüm altyapıyı silebilir. Bildirimsel düşünün, en dar izinle başlayın, gevşek varsayılanları düzeltin, sırları koddan ve state'ten uzak tutun. En hayati korkuluk plan/check adımıdır: silme ve yeniden oluşturma satırlarını okumadan asla uygulamayın. State'i şifreli, kilitli ve uzak tutun. Kod YZ'nin, karar sizindir.
Uygulama görevi
Küçük bir altyapı hedefi seçin (örneğin tek bir sanal makine ve bir güvenlik kuralı). Yukarıdaki "IaC kaynağı üretme" şablonuyla YZ'den güvenli varsayılanlarla bir kod isteyin. Kodu "IaC kod güvenlik incelemesi" şablonuyla ikinci kez denetleyin ve en az bir gevşek ayar bulmaya çalışın. Mümkünse bir test hesabında plan/--check çalıştırıp çıktıyı "Plan çıktısı denetimi" şablonuyla inceleyin; silme veya yeniden oluşturma satırı var mı bakın. Bulgularınızı ve state'i nasıl güvence altına alacağınızı 6 maddede yazın.
Kontrol listesi
- [ ] YZ'ye bulut, araç ve sürümü belirtip en dar izinle kod istedim mi?
- [ ] Kodda gevşek varsayılan (0.0.0.0/0, kapalı şifreleme) var mı diye denetledim mi?
- [ ] Sırları koda gömmek yerine değişkene çıkardım mı?
- [ ] Uygulamadan önce plan/check çıktısını okuyup silme satırlarını işaretledim mi?
- [ ] "forces replacement" / yeniden oluşturma satırlarının veri kaybı etkisini değerlendirdim mi?
- [ ] State dosyasını şifreli, kilitli, uzak backend'de tutup dışarı sızdırmadım mı?