Packer ile Golden Image Pipeline: CIS Baseline ve Yama Stratejisi

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:

1. Packer build (base OS + paketler + config)
2. Hardening (CIS seviyesine göre)
3. Test (boot, servis health, temel güvenlik kontrolleri)
4. SBOM + zafiyet taraması (imajın içeriğini bilmek)
5. İmza / provenance (imajın kaynağı)
6. Yayınlama (AMI, vSphere template, qcow2, vb.)
7. 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:

1. Planlı rebuild: haftalık/2-haftalık (paket güncellemeleri)
2. 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+1 gibi 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.