Container Güvenliği: Docker, Kubernetes ve Runtime Korumaları

Sysdig 2025 Cloud-Native Security raporuna göre üretim ortamındaki container imajlarının %74’ü en az bir yüksek seviye CVE içeriyor; %19’unda saldırı yüzeyi aktif sömürülebilir kritik açık bulunuyor. Aqua Security 2025 Cloud Native Threat Report ise honeypot deneyimlerinde container’a karşı düzenlenen saldırıların ortalama 30 saniye içinde otomatik yararlandırma denediğini, bunların %59’unun cryptominer yüklediğini ve %25’inin runtime sırasında kalıcılık (persistence) bıraktığını ortaya koyuyor. CNCF 2024 Cloud Native Security Survey, kuruluşların %71’inin Kubernetes güvenliğini “yüksek öncelik” olarak işaretlediğini, ancak yalnızca %18’inin tüm beş katmanda (build, registry, deploy, runtime, supply chain) entegre kontrol uyguladığını gösteriyor. 2026’ya girerken Docker, containerd ve CRI-O üzerinde standartlaşmış container ekosistemi, güvenlik açısından hâlâ olgunlaşma sürecinde: NSA/CISA Kubernetes Hardening Guide v1.3, OpenSSF Best Practices, CIS Kubernetes Benchmark 1.10 ve MITRE ATT&CK for Containers matrisi gibi kılavuzlar varken çoğu kurum bunların yalnızca yüzeyini uygular.

Bu rehber container güvenliğini imaj, kayıt defteri, orkestrasyon, runtime ve tedarik zinciri olmak üzere beş katmanda ele alıyor; Docker ve Kubernetes ortamlarında uygulanacak somut kontrolleri, sertifikalı araç karşılaştırmasını, Pod Security Standards profillerini, eBPF tabanlı runtime gözlemleri ve MITRE ATT&CK saldırı zincirini sayısal veriyle birlikte inceliyor.

Container Güvenliğinin Beş Katmanı ve Tehdit Modeli

Container güvenliği tek bir araçla sağlanmaz; build-time, supply chain, registry, deploy-time ve runtime olmak üzere beş katmanda kontrol gerektirir. NIST SP 800-190 kılavuzu ve CNCF Cloud Native Security Whitepaper bu katmanları açık şekilde tanımlar. CrowdStrike 2025 Global Threat Report, en az üç katmanı kapsayan kuruluşlarda ihlal başına ortalama hasarın %63 düştüğünü; tek katmana (yalnızca imaj tarama) yatırım yapanlarda ise tedarik zinciri ve runtime kaçışı saldırılarının %4,2 kat daha yüksek olduğunu gösterir. Aşağıdaki tablo bu beş katmanı, kapsadığı tehditleri ve önerilen kontrolleri özetler.

Katman	Tehdit	Önerilen Kontrol	Referans Araç	Olgunluk
Build	Açıklı base image, gömülü secret	Multi-stage, distroless, secret scan	Hadolint, Gitleaks	Yüksek
Supply Chain	İmzasız artefakt, tampered binary	Cosign signing, SLSA Level 3+, SBOM	Sigstore, in-toto	Orta
Registry	CVE’li imaj, yetkisiz pull	Sürekli tarama, RBAC, immutable tag	Trivy, Harbor	Yüksek
Deploy / Admission	Privileged pod, hostPath, root	PSA restricted, admission policy	Kyverno, Gatekeeper	Orta
Runtime	Container kaçışı, cryptominer, C2	eBPF syscall + ağ izleme, drift	Falco, Tetragon, Tracee	Orta-Düşük

• Build: minimal base, signed image, SBOM üretimi, secret scanning, Dockerfile lint.
• Tedarik zinciri: SLSA seviyeleri (Build L3+), Sigstore cosign imzalama, in-toto attestation, provenance metadata.
• Registry: imza doğrulama, sürekli CVE taraması, izin kontrolü (RBAC), immutable tag policy, retention.
• Deploy-time: admission controller (OPA Gatekeeper veya Kyverno), Pod Security Admission, NetworkPolicy default-deny.
• Runtime: eBPF tabanlı tespit (Falco, Tetragon, Tracee), drift detection, audit log, SIEM entegrasyonu.

https://omeronal.com/wp-content/uploads/2026/05/container-guvenligi-docker-kubernetes-v2-inline-1.webp

İmaj Sertleştirme: Distroless, Minimal ve Tam Dağıtım Karşılaştırması

Kurumsal Dockerfile’daki en kritik karar base image seçimidir. Ubuntu 22.04 LTS ortalama 280 MB ve 90+ yüksek CVE ile gelirken Alpine 3.20 tabanlı imajlar 8 MB altında, distroless veya Chainguard Wolfi tabanlı imajlar ise 5-25 MB aralığında ve neredeyse sıfır CVE ile çalışır. Multi-stage build ile derleme araçları nihai imajdan çıkarılmalı; root yerine USER 1001 gibi sabit, rastgele bir UID kullanılmalıdır. Trivy, Grype veya Snyk Container ile her push CI sürecinde otomatik taranmalı; bulunan kritik açıklarda “fail the build” politikası tetiklenmelidir.

Base Image	Boyut	Ort. CVE	Shell?	Paket Yöneticisi	En Uygun Senaryo
Ubuntu 22.04 LTS	280 MB	90+	Var	apt	Geliştirme / debug
Debian Slim	74 MB	45	Var	apt	Genel amaç
Alpine 3.20	7 MB	3-8	ash	apk	Statik bağımlı binari
Google Distroless	20-50 MB	0-3	Yok	Yok	Üretim runtime
Chainguard Wolfi	10-25 MB	0 (zero-CVE SLA)	Opsiyonel	apk	SLSA L3+ üretim
Scratch	0 MB	0	Yok	Yok	Go / Rust static

Imaj imzalama, 2026 itibarıyla artık opsiyonel değildir. SolarWinds (2020), Log4Shell (2021) ve XZ Utils (2024) gibi tedarik zinciri saldırıları, imzasız artefaktın kurumsal ortamda kabul edilemez risk taşıdığını kanıtladı. Sigstore cosign ile imzalama saniyeler sürer, OIDC kimlikli keyless imzalama anahtar yönetimini ortadan kaldırır. Admission controller imza doğrulaması yaparak imzasız veya bilinmeyen publisher’dan gelen imajların kümeye dağıtımını engeller. SLSA framework Level 3’e ulaşan kurumlarda tedarik zinciri saldırı yüzeyi yüzde 95 oranında daralır.

Kayıt Defteri ve Görüntü Tarama Araçları

Image scanning, container güvenliğinin en olgun katmanıdır; pazardaki araç çeşitliliği yüksek, doğruluk oranları (CVE detection rate) gözlenebilir düzeyde standartlaşmıştır. Forrester 2025 Wave raporuna göre üç ürün ailesi öne çıkıyor: açık kaynak Trivy/Grype, ticari Aqua/Sysdig/Snyk ve bulut sağlayıcı entegre çözümleri (AWS Inspector v2, GCP Artifact Analysis, Azure Defender for Containers). Seçim kriterleri yalnızca CVE veritabanı kapsamı değil; aynı zamanda IaC misconfig tespiti, secret detection, SBOM üretimi ve runtime’a aktarılabilir politika köprüsü olmalıdır.

Araç	Kapsam	İmaj Tarama	Runtime Tespit	Politika	SBOM	Lisans
Trivy	İmaj + IaC + secret	Çok güçlü	Yok	Misconfig	SPDX/CycloneDX	Apache 2.0
Grype	İmaj + SBOM	Güçlü	Yok	Sınırlı	Syft entegre	Apache 2.0
Snyk Container	İmaj + IaC	Çok güçlü	Sınırlı	Orta	Var	Ticari
Aqua Security	Tam yığın CNAPP	Güçlü	Güçlü	Kapsamlı	Var	Ticari
Sysdig Secure	Tam yığın CNAPP	Güçlü	Çok güçlü	OPA / runtime	Var	Ticari
Anchore	İmaj + uyum	Güçlü	Yok	Custom policy	Var	Apache 2.0 / Ticari

• Üretim öncesinde her imajı en az iki bağımsız tarayıcı ile (örn. Trivy + Snyk) tarayın; tek tarayıcının yanlış-negatif oranı ortalama %12’dir.
• CVE skor eşiğini CVSS 7.0+ değil, EPSS (Exploit Prediction Scoring System) ile birleştirerek prioritize edin.
• Tarama sonuçlarını dakikalar değil saniyeler içinde geri bildirmek için layered cache ve incremental scanning kullanın.
• Registry tarafında Harbor gibi enterprise registry’lerde signed manifest dışındaki pull işlemlerini reddedin.

Runtime Güvenlik: Falco, Tetragon ve Tracee Karşılaştırması

Runtime tespit, container güvenliğinin en kritik fakat aynı zamanda en olgunlaşmamış katmanıdır. İmaj taraması yalnızca bilinen CVE’leri yakalar; zero-day saldırıları, davranışsal anomalileri ve container kaçışlarını tespit edemez. Falco, Tetragon ve Tracee, eBPF tabanlı sistem çağrısı izleme ile container kaçışı, kripto madenciliği, şüpheli ağ bağlantısı ve dosya sistemi tampering gibi tehditleri saniyeler içinde işaretler. MTTD süresini ortalama 287 günden 24 saatin altına indirir.

https://omeronal.com/wp-content/uploads/2026/05/container-guvenligi-docker-kubernetes-v2-inline-2.webp

Özellik	Falco	Tetragon	Tracee
Sahibi	Sysdig / CNCF Graduated	Isovalent / CNCF Incubating	Aqua Security
Çekirdek Modülü	eBPF (modern) / kmod	eBPF + LSM hooks	eBPF
Kural Dili	YAML (Sysdig syntax)	TracingPolicy CRD	YAML / Rego
Önleme (Enforce)	Yok (alert-only)	Var (signal/kill)	Sınırlı
Performans Overhead	%2-5	%1-3	%2-4
Ağ Görünürlüğü	Orta	Çok güçlü (Cilium ile)	Orta
En Uygun Senaryo	SIEM beslemek, alerting	Aktif önleme + Cilium	Forensik, audit

Falco, en geniş topluluğa ve hazır kural setine sahiptir; SIEM (Splunk, Elastic Security, Chronicle) entegrasyonu için olgun bir alert pipeline sunar. Tetragon ise Cilium ile aynı eBPF datapath’i paylaşması sayesinde ağ + syscall korelasyonunda öne çıkar ve LSM hook’ları üzerinden gerçek enforcement (process kill, signal) yapabilir. Tracee, forensik ve detaylı audit log için optimize edilmiştir; CSPM süreçlerinde ham olay zenginleştirmesinde tercih edilir. Üretim ortamlarının %62’si Falco + Tetragon kombinasyonunu seçer (CNCF 2024 survey).

Kubernetes Sertleştirme: Pod Security Standards ve Admission Control

Kubernetes v1.25’te PodSecurityPolicy (PSP) tamamen kaldırıldığından beri Pod Security Admission (PSA) ve harici admission controller’lar (Kyverno, OPA Gatekeeper) tek geçerli politika katmanıdır. Pod Security Standards üç hiyerarşik profil tanımlar: privileged (kısıtlama yok), baseline (bilinen tehlikeli özellikleri engeller) ve restricted (sertleştirilmiş üretim). NSA/CISA Kubernetes Hardening Guide, üretim namespace’leri için “restricted” profilini zorunlu kılar.

https://omeronal.com/wp-content/uploads/2026/05/container-guvenligi-docker-kubernetes-v2-inline-3.webp

Kontrol	Privileged	Baseline	Restricted
privileged: true	Serbest	Yasak	Yasak
hostNetwork / hostPID / hostIPC	Serbest	Yasak	Yasak
hostPath volume	Serbest	Yasak	Yasak
runAsNonRoot	İsteğe bağlı	İsteğe bağlı	Zorunlu (true)
allowPrivilegeEscalation	Serbest	Serbest	false zorunlu
readOnlyRootFilesystem	İsteğe bağlı	İsteğe bağlı	Önerilir (true)
seccompProfile	İsteğe bağlı	İsteğe bağlı	RuntimeDefault / Localhost
Capabilities	Hepsi	Tehlikeli olanlar yasak	Hepsi drop, NET_BIND_SERVICE izinli

1. Pod Security Admission ile her namespace’e “restricted” enforce, “baseline” audit, “baseline” warn label’larını ekleyin.
2. NetworkPolicy ile varsayılan deny yapılandırın; sadece ihtiyaç olan source/destination + port izinli olsun.
3. seccomp profili (RuntimeDefault veya custom Localhost) tüm pod’larda etkin olmalı; Security Profiles Operator ile otomatik üretin.
4. AppArmor / SELinux profili tercih edilen distro’da aktif olmalı; “audit” modunda başlatıp “enforce” moduna geçiş yapın.
5. RBAC kuralları en az ayrıcalık prensibine göre tasarlanmalı; ServiceAccount token otomatik mount kapatılmalı (automountServiceAccountToken: false).
6. Admission controller olarak Kyverno veya OPA Gatekeeper devreye alın; imzasız imajları, root container’ı ve privileged pod’u reddedin.
7. Falco veya Tetragon ile runtime tehditleri eBPF temelli izleyin; SIEM’e (Splunk / Elastic Security / Chronicle) gönderin.
8. CIS Kubernetes Benchmark kontrollerini kube-bench ile haftalık çalıştırın, drift raporu üretin.
9. Audit logging etcd erişimi dahil enable edilmeli; log retention 90 gün üzerinde tutulmalıdır.

Admission Controller Karşılaştırması: Kyverno vs OPA Gatekeeper

Admission controller seçimi politika ekibinin teknik tercihiyle değil, organizasyon kapsamıyla belirlenir. Yalnızca Kubernetes ortamı yöneten ekipler için Kyverno daha düşük öğrenme eğrisi sunar; YAML tabanlı politikalar dakikalar içinde yazılır ve test edilebilir. Çoklu bulut, Terraform plan validation veya Kafka topic policy gibi Kubernetes dışı senaryolar gerekiyorsa OPA Gatekeeper ve Rego dili daha güçlü bir genel amaçlı motor sağlar.

Kriter	Kyverno	OPA Gatekeeper
Politika Dili	YAML (Kubernetes native)	Rego (domain-specific)
Öğrenme Eğrisi	Düşük (1-2 gün)	Yüksek (1-2 hafta)
Mutating Webhook	Var (image mutation, default ekleme)	Sınırlı (3.x ile geliyor)
Image Verification	Cosign / Notary native	Harici kütüphane gerekir
Policy Reports	CRD native (PolicyReport)	Constraint statüs
Kapsam	Yalnızca Kubernetes	Kubernetes + harici (Terraform vb.)
CNCF Statüsü	Incubating	Graduated (OPA çatısında)
2025 Adopsiyon	%47 (CNCF survey)	%29

Üretim politikalarının çoğu—imzasız imaj reddi, restricted PSS enforce, kaynak limit zorunluluğu, etiket standardı—her iki araçta da yazılabilir. Karar verirken takımın Rego deneyimi, mutating webhook ihtiyacı ve image verification gereksinimi belirleyici olur. Kurumsal ortamların büyük kısmı 2026 itibarıyla Kyverno’yu tercih ediyor; OPA Gatekeeper ise multi-cloud governance ihtiyacı olan FinServ ve telco segmentinde lider.

MITRE ATT&CK for Containers ve Saldırı Zinciri

MITRE ATT&CK for Containers matrisi, 2021’de yayımlandığından beri container saldırılarını sekiz taktik altında sınıflandırır. Aqua Nautilus 2024 raporu en sık kullanılan teknikler olarak T1610 (Deploy Container), T1611 (Escape to Host), T1525 (Implant Internal Image) ve T1496 (Resource Hijacking / cryptominer) belirler. Container kaçışları sıklıkla CVE-2022-0185 (Linux kernel), CVE-2024-21626 (runc) ve CVE-2025-XXX serisi yamasız çekirdek açıklarıyla başlar.

https://omeronal.com/wp-content/uploads/2026/05/container-guvenligi-docker-kubernetes-v2-inline-4.webp

Taktik	Teknik ID	Örnek	Karşı Kontrol
Initial Access	T1190 / T1525	Exposed kubelet, malicious base image	Auth disable, registry scanning
Execution	T1610	kubectl exec, deploy ile yeni pod	RBAC, admission policy
Persistence	T1543.005	DaemonSet, MutatingWebhook abuse	Audit log, Tetragon kill
Privilege Escalation	T1611	Container escape (runc, kernel CVE)	seccomp, AppArmor, patched kernel
Defense Evasion	T1078.004	Default ServiceAccount, kullanım	Token mount disable, least privilege
Discovery	T1613	Kubernetes API tarama	NetworkPolicy, audit
Lateral Movement	T1550.001	Token ile pod-to-pod	NetworkPolicy, service mesh mTLS
Impact	T1496	Cryptominer, ransomware	Runtime detection, resource limit

Bu matrise göre tek bir noktada savunma yeterli değildir; her taktiğe karşı en az iki kontrol katmanı tanımlanmalıdır. Sysdig 2025 verisi, saldırganın ilk container’a erişimden lateral movement’a geçişi ortalama 88 saniyede tamamladığını gösterir. Bu kadar dar pencere içinde insan müdahalesi mümkün değildir; otomatik enforcement ve runtime kill politikaları zorunludur. Bu konuda DevSecOps shift-left güvenlik yaklaşımı ile derinlemesine birleştirilmiş bir kontrol katmanı önerilir.

Maliyet, ROI ve Olgunluk Modeli

Açık kaynak yığın (Trivy + Cosign + Kyverno + Falco) tek bir orta ölçekli Kubernetes kümesi (50-200 node) için yıllık 25.000-45.000 dolarlık operasyon kaynağı tüketir; ticari CNAPP çözümleri (Aqua, Sysdig, Wiz, Prisma Cloud) ise 60.000-220.000 dolar bant aralığında konumlanır. IBM 2025 Cost of a Data Breach raporu, container ortamındaki veri ihlalinin ortalama maliyetini 4,88 milyon dolar olarak belirler; tedarik zinciri ihlalinde bu rakam 7,3 milyon dolara çıkar. Bu seviyede yatırım, ihlal başına engellenen hasarın küçük bir oranını oluşturur.

• Seviye 1 (temel): Imaj tarama + base image policy. Kontrol kapsamı %25.
• Seviye 2 (operasyonel): Admission controller + PSS restricted + NetworkPolicy. Kapsam %55.
• Seviye 3 (taktik): + Cosign imzalama + SBOM + runtime detection. Kapsam %78.
• Seviye 4 (stratejik): + SLSA L3 + Tetragon enforcement + SIEM korelasyon + threat hunting. Kapsam %92+.

Sınırlamalar açıkça konuşulmalıdır: hiçbir araç kötü yazılmış Dockerfile’ı, gevşek RBAC’ı veya yamasız çekirdeği telafi etmez. Güvenlik bir araç meselesi değil, süreç ve kültür meselesidir; CI/CD’de “fail the build” politikası uygulanmadığında ve geliştiriciye anlamlı geri bildirim verilmediğinde en iyi araç bile sembolik kalır. Kubernetes Network Policy ve Cilium ile mikrosegmentasyon, Zero Trust mimarisi, SBOM ve SLSA framework ile tedarik zinciri savunması; penetration testing ile kontrolün doğrulanması; service mesh mTLS ile pod-to-pod kriptosu ve GitOps ile policy-as-code akışı bir bütün olarak değerlendirilmelidir.

Sık Sorulan Sorular

Sonuç: Container Güvenliği Olgunluk Kararı

Container güvenliği 2026 itibarıyla artık opsiyonel bir özellik değil; build-time imaj taramasıyla başlayan, tedarik zinciri imzalamasıyla devam eden, admission control ile pekişen ve runtime davranış izlemeye uzanan beş katmanlı bir disiplindir. Açık kaynak yığın (Trivy + Cosign + Kyverno + Falco veya Tetragon) çoğu kurum için yeterli teknik kapsam sunar; ticari CNAPP çözümleri ise birleşik panel, uyum raporlama ve threat intel avantajıyla regülasyon ağır segmentlerde öne çıkar. Karar yalnızca araç seçimiyle değil, “fail the build” disipliniyle, geliştiriciye anlamlı geri bildirim akışıyla, restricted Pod Security profil zorunluluğuyla ve MITRE ATT&CK matrisini bilinçli izleyen runtime detection süreciyle gerçek değerini kazanır. Olgunluk hedefi: 12 ay içinde Seviye 3 (taktik), 24 ay içinde Seviye 4 (stratejik). Tek bir aracın varlığı değil, beş katmanın bütüncül entegrasyonu container güvenliğinin gerçek tanımıdır.