Kurumsal operasyonlarda en yaygın “sessiz borç” şudur: sunucular yaşayan canlılar gibi “yerinde” güncellenir. Başta hızlıdır; sonra drift büyür, hangi host’ta hangi paket sürümü var bilinmez, acil CVE’de “tek tek SSH” kabusu başlar.
Golden image yaklaşımı, bu işi tersine çevirir: sunucuyu güncellemezsin, sunucunun imajını güncellersin.
Bu yazı; Packer ile CIS baseline + test + dağıtım içeren bir imaj pipeline’ını pratik ve üretim odaklı şekilde kurgular.
Hedef: “patch yönetimi” değil “değişim yönetimi”
Golden image ile aslında şunu satın alırsınız:
- Drift’in kontrol altına alınması (aynı rol = aynı imaj)
- Acil CVE’de daha hızlı rollout (yeni imaj → wave deploy)
- Sertleştirme (hardening) kararlarının ölçülebilir olması
- Audit sorularına net cevap: “hangi imaj, hangi hash, hangi testlerle üretildi?”
Tasarım: Pipeline bileşenleri
Minimum üretim seti:
- Packer build (base OS + paketler + config)
- Hardening (CIS seviyesine göre)
- Test (boot, servis health, temel güvenlik kontrolleri)
- SBOM + zafiyet taraması (imajın içeriğini bilmek)
- İmza / provenance (imajın kaynağı)
- Yayınlama (AMI, vSphere template, qcow2, vb.)
- Dalga (wave) dağıtım (canary → pilot → genelleme)
Bu adımların her biri “ops realitesi” için gereklidir. Aksi halde pipeline bir süre sonra terk edilir.
Packer taslağı (HCL) — küçük ama doğru bir omurga
Packer config’i, kurumdan kuruma değişir. Ama mantık sabit:
source "amazon-ebs" "linux" {
region = var.region
instance_type = "t3.medium"
ami_name = "golden-linux-${var.version}"
source_ami_filter {
filters = { name = "ubuntu/images/*ubuntu-jammy-22.04-amd64-server-*" }
owners = ["099720109477"]
most_recent = true
}
ssh_username = "ubuntu"
}
build {
sources = ["source.amazon-ebs.linux"]
provisioner "shell" {
scripts = [
"scripts/bootstrap.sh",
"scripts/hardening-cis.sh",
"scripts/install-agents.sh",
"scripts/cleanup.sh"
]
}
}Burada kritik nokta: hardening-cis.sh bir “tek seferlik script” değil; versiyonlanan, diff’i görülen ve rollback’i olan bir artefact olmalı.
CIS baseline: “hepsini aç” değil, “operasyonel kontrat” yap
CIS’in tamamını uygulamak bazı servislerde gerçekçi değildir (ör. bazı kernel parametreleri, auditd ayarları, SSH policy, vb.). Bu yüzden:
- CIS kontrol listesini kurum standardına çevirin
- İstisnaları “neden + sahip” ile kaydedin
- Baseline değişince “etki analizi” üretin (hangi servisler etkileniyor?)
Önerdiğim pratik:
- Level 1: genel amaçlı baseline (çoğu sunucu)
- Level 2: yüksek riskli segment (admin, bastion, control-plane)
Test: Sadece “boot ediyor” değil, “kabul kapısı”
Pipeline’daki testler ikiye ayrılır:
1) Fonksiyonel test
- Servis ayağa kalkıyor mu?
- Agent’lar başlıyor mu?
- DNS/clock/ntp doğru mu?
2) Güvenlik/doğrulama testleri
- SSH policy
- Kernel parametreleri
- Gereksiz paket/servis yokluğu
- Log üretimi / audit doğrulaması
Yama stratejisi: “ayda bir rebuild” yetmez
İki ayrı ritim kurun:
- Planlı rebuild: haftalık/2-haftalık (paket güncellemeleri)
- Acil rebuild: CVE/0-day (24 saat altında)
Bu ritmi çalıştırmak için “sürüm sözleşmesi” gerekir:
golden-linux-2026.04.17+1gibi semantik bir versiyon- “hangi servisler hangi major’a bağlı?” görünürlüğü
- Dalga dağıtım planı ve rollback
Dalga dağıtım (wave) — en az canary kadar, “geri dönüş” de önemlidir
Örnek wave:
- Canary: 1–2 host (non-critical)
- Pilot: %5 (kritik olmayan ama gerçek trafik)
- General: %25 → %50 → %100
Her dalgada iki şey sabit olmalı:
- Başarı metrikleri: error rate, latency, CPU/memory, kernel logs
- Rollback kuralı: belirli eşiği geçerse otomatik dur
Operasyonel ölçümler (gerçek KPI)
Golden image başarısını “kaç imaj ürettik” ile ölçmeyin. Şunları ölçün:
- MTTR: acil CVE’de rollout süresi
- Drift: aynı rol host’larda paket farkı (hedef: minimal)
- Image age: prod’da kaç günlük imaj var?
- Failure budget: update dalgasında rollback oranı
Son söz
Golden image; “bir araç” değil, operasyonel bir anlaşmadır: sunucuya değil, imaja güven. Packer ile doğru pipeline’ı kurduğunuzda; hardening ve patch yönetimi, geceleri uykunuzu kaçıran “tek tek müdahale” işinden çıkar, ölçülebilir ve yönetilebilir bir release disiplinine dönüşür.