Docker & Container Security

1. Giriş

Container'lar modern PHP dağıtımının standardı oldu: Docker imajları, uygulamayı bağımlılıklarıyla paketleyip her yerde aynı şekilde çalıştırır. Ama container'lar sık yanlış anlaşılan bir güvenlik varsayımı taşır: container bir sanal makine (VM) değildir. VM'ler ayrı bir çekirdek (kernel) çalıştırıp donanım seviyesinde izole olurken, container'lar aynı host çekirdeğini paylaşır ve yalnızca çekirdek özellikleriyle (namespace, cgroup) izole edilir. Bu, container izolasyonunun VM'ler kadar güçlü olmadığı anlamına gelir: çekirdekteki veya container çalışma zamanındaki (runc/containerd) bir açık, container'dan host'a kaçışa yol açabilir.

Bunun ders kitabı örneği CVE-2019-5736'dır (Bölüm 11): runc'taki bir açık, kötü niyetli bir container'ın (içinde root ise) host'un runc ikilisini üzerine yazıp host'ta root kod çalıştırmasına izin veriyordu — tam container kaçışı. Kritik önkoşul, container içinde root olmaktı; non-root çalışan veya user namespace kullanan container'lar bu saldırıya çok daha dirençliydi.

Bu bölüm, container güvenliğini ele alır ve Kısım VI'nın (php.ini, web sunucusu, Linux izinleri) altyapı temasını container katmanına taşır. Merkezî ders: container izolasyonuna tek savunma olarak güvenme; onu en az yetkiyle (Bölüm 1) — non-root, düşürülmüş capabilities, minimal imaj — katmanla, ki bir uygulama açığı bir host devrine dönüşmesin.

---

2. Temel Teori

Container ≠ VM. Container, host çekirdeğini paylaşır; izolasyon namespace (PID, ağ, mount, kullanıcı) ve cgroup'larla sağlanır. Bu güçlü ama mutlak değildir: çekirdek açıkları ve çalışma-zamanı (runc) hataları kaçışa yol açar. "Container bir güvenlik sınırıdır ama VM kadar güçlü değildir" doğru zihinsel modeldir.

Başlıca container riskleri:

Risk	Neden tehlikeli
Container içinde root	Kaçış (CVE-2019-5736) veya mount suistimali → host root
Privileged mode (--privileged)	Tüm host aygıtları/yetkileri; trivial kaçış
Docker soketi ifşası (/var/run/docker.sock mount)	Container, Docker'ı kontrol eder → privileged container başlatıp host root
Aşırı capabilities	Öntanımlı capability seti; gereksizler kaçış yardımcısı
Güvenilmez/açıklı imaj	Backdoor, bilinen açıklar (Bölüm 30)
İmajdaki sırlar	İmaj katmanlarına gömülü sır (Bölüm 25)
Read-write root FS	Kalıcılık/değişiklik (Bölüm 28)
Yamasız çalışma zamanı	runc/containerd açıkları (CVE-2019-5736)

En kritik ilke — non-root + en az yetki. Container güvenliğinin belkemiği, Bölüm 1/28'in en-az-yetki ilkesinin container'a uygulanmasıdır: - Non-root çalış (USER direktifi): Container içindeki süreç root olmasın; bir kaçış açığının (CVE-2019-5736) önkoşulunu kaldırır. - User namespaces (userns-remap): Container'ın "root"unu host'ta yetkisiz bir kullanıcıya eşle; kaçsa bile host'ta yetkisiz kalır. - Capabilities düşür: --cap-drop=ALL + yalnızca gerekenleri --cap-add. - --no-new-privileges, read-only root FS (--read-only), seccomp/AppArmor/SELinux profilleri. - Privileged/docker.sock ASLA.

İmaj güvenliği (Bölüm 30 ile bağ). Minimal taban imajı (distroless/alpine — küçük saldırı yüzeyi), imaj tarama (Trivy/Clair — bilinen açıklar), digest ile sabitleme (@sha256:...), güvenilir registry, imza doğrulama. Sırlar imaja gömülmez (Bölüm 25).

Derinlemesine savunma. Container kaçışı genellikle birden çok zayıflığın (root + privileged + yamasız runtime) birleşmesini gerektirir. Her katman (non-root, düşürülen cap, read-only, güncel runtime) kaçışı zorlaştırır — uygulama açığının host devrine dönüşmesini engeller (Bölüm 1).

---

3. Mimarisel Bakış

 GÜVENSİZ (kaçışa açık):
   Web açığı → web shell (container içinde ROOT)
        ↓  + yamasız runc (CVE-2019-5736) / --privileged / docker.sock
   Host runc üzerine yaz → host'ta root kod çalışır → HOST DEVRİ
        ↑ container "güvenlik sınırı" çöktü

 GÜVENLİ (derinlemesine savunma):
   Web açığı → web shell (container içinde NON-ROOT, cap-drop=ALL)
        ✗ root değil → CVE-2019-5736 önkoşulu yok
        ✗ user namespace → "root" host'ta yetkisiz
        ✗ read-only FS → kalıcılık zor
        ✗ güncel runc + seccomp → kaçış yolu kapalı
   → web shell container'da SINIRLI kalır (blast radius daralır)

 KATMANLAR:
   USER non-root · userns-remap · --cap-drop=ALL · --read-only
   --no-new-privileges · seccomp/AppArmor · minimal+taranmış imaj (Böl.30)
   ASLA: --privileged, docker.sock mount, imajda sır (Böl.25)

Kritik gözlem: container izolasyonu tek savunma değildir; en az yetki katmanları, bir kaçışı hem zorlaştırır hem de kaçış olsa bile host'ta yetkiyi sınırlar.

---

4. Güvensiz Kod

Gerçekçi (güvensiz) Dockerfile ve çalıştırma:

# ⚠️ GÜVENSİZ Dockerfile
FROM php:8.3                          # şişkin taban imajı (büyük yüzey)
COPY . /var/www/app                   # sırlar (.env) dahil kopyalanabilir (Bölüm 25)
ENV DB_PASSWORD=P@ssw0rd123           # sır imaj katmanında! (Bölüm 25)
# USER direktifi yok → container ROOT çalışır
CMD ["php-fpm"]

# ⚠️ GÜVENSİZ çalıştırma
docker run --privileged \                          # tüm host yetkileri
  -v /var/run/docker.sock:/var/run/docker.sock \   # Docker kontrolü → host root
  -v /:/host \                                     # host FS mount
  myapp
# capabilities düşürülmemiş, read-only değil, imaj taranmamış, runtime güncel değil

---

5. Açığın Analizi

USER yok → container root — CVE-2019-5736'nın önkoşulu. Container içindeki süreç root olduğundan, bir web shell (Bölüm 19) veya kaçış açığı host'a yükselebilir. USER app (non-root) + user namespace bu önkoşulu kaldırır.

--privileged — Container'a neredeyse tüm host yetkilerini verir (tüm aygıtlar, capabilities, güvenlik profilleri kapalı). Bu durumda kaçış trivial'dir; container güvenlik sınırı yok sayılır. Üretimde asla kullanılmaz.

-v /var/run/docker.sock:... — Docker soketi ifşası. Container, Docker daemon'ı kontrol edebilir; yeni, privileged bir container başlatıp host FS'ini mount ederek host root'a ulaşır. Docker soketi asla container'a mount edilmez.

-v /:/host — Host kök dosya sistemini container'a mount etmek; container host'un tüm dosyalarını okur/yazar → host devri.

ENV DB_PASSWORD=... / .env kopyalama — Sır, imaj katmanına gömülü (Bölüm 25); imaja erişen (registry, imaj indiren) sırra erişir. Sırlar imaja gömülmez; çalışma zamanında sır yöneticisinden/secret'tan gelir.

FROM php:8.3 (şişkin imaj) — Büyük taban imajı, çok sayıda paket ve dolayısıyla açık taşır (Bölüm 30). Minimal (distroless/alpine) taban tercih edilir.

Eksik: cap-drop, read-only, tarama, güncel runtime — Capabilities düşürülmemiş, root FS yazılabilir, imaj taranmamış, runtime yamasız (CVE-2019-5736). Her biri kaçışı kolaylaştırır.

Kök sorun: container root, aşırı yetkili (privileged/docker.sock), sır gömülü ve sertleştirilmemiş. Çözüm: non-root + en az yetki + minimal/taranmış imaj + sır yönetimi.

---

6. Hacker Bakış Açısı

Saldırgan bir container içinde kod çalıştırdığında (web shell) ne yapar?

Bağlamı belirler. Container içinde mi? id ile root mu? --privileged mi? /var/run/docker.sock mount edilmiş mi? /proc, capabilities (capsh --print), mount edilmiş host yolları? Bunlar kaçış fizibilitesini belirler.

Kolay kaçış yollarını arar. Docker soketi mount edilmişse: soket üzerinden yeni privileged container başlatıp host FS'ini mount eder → host root (en kolay yol). Privileged container ise: aygıtlara erişip host'a çıkar. Host mount varsa doğrudan host dosyalarına erişir.

Runtime açığı dener. Kolay yol yoksa ve container içinde root ise, CVE-2019-5736 gibi bir runc açığını dener: host runc ikilisini üzerine yazıp bir sonraki docker exec'te host'ta root kod çalıştırır. Yamasız runtime bu yolu açar.

Capabilities'i kullanır. Düşürülmemiş tehlikeli capabilities (CAP_SYS_ADMIN, CAP_SYS_PTRACE vb.) kaçış yardımcısıdır; saldırgan bunları arar.

İmajdaki sırları toplar. İmaj katmanlarında/ENV'de gömülü sırları (Bölüm 25) okuyup başka sistemlere yayılır.

Savunmacı dersi: Saldırgan container'ı bir başlangıç ve host'a köprü olarak görür. Docker soketi, privileged mode ve container-içi-root en kolay köprülerdir. Bunları kaldırmak (+ güncel runtime + düşürülen cap), kaçışı çok zorlaştırır.

---

7. Exploit Mantığı

Bu bölüm çalıştırılabilir kaçış betiği içermez. Container güvenliğinin neden derinlemesine savunma gerektirdiği kavramsaldır:

• Paylaşılan çekirdek = mutlak sınır değil. Container host çekirdeğini paylaştığından, çekirdek/runtime açıkları kaçışa yol açar. İzolasyon güçlüdür ama VM kadar değil; tek savunma olarak güvenilmez.
• En az yetki, kaçışı hem zorlaştırır hem sınırlar. Non-root + düşürülen cap + user namespace, bir kaçış açığının (CVE-2019-5736) önkoşulunu kaldırır ve kaçış olsa bile host'ta yetkiyi sınırlar (userns).
• Kolay köprüler = tek nokta felaketi. Docker soketi ve privileged mode, tüm izolasyonu tek hamlede yok eder; bunları kaldırmak en yüksek etkili savunmadır.
• Zincir doğası. Host devri genellikle bir zincirdir: web açığı → container web shell → kaçış (runtime açığı / docker.sock / privileged) → host root. Her halka bir container-sertleştirme katmanıyla kırılabilir (Bölüm 1, 28).

Araştırmacının çerçevesi: (a) container non-root mu, (b) privileged/docker.sock/host-mount var mı, (c) capabilities düşürülmüş mü, (d) runtime güncel mi, (e) imaj minimal/taranmış mı. Savunma hepsini katmanlar.

---

8. Güvenli Kod

Sertleştirilmiş Dockerfile ve çalıştırma:

# ✅ GÜVENLİ Dockerfile
FROM php:8.3-fpm-alpine                # minimal taban (küçük yüzey — Bölüm 30)
# Bağımlılıkları imaja gömülü sır OLMADAN kur
COPY --chown=app:app . /var/www/app
# .dockerignore ile .env / .git / sırlar imaja GİRMEZ (Bölüm 25)

RUN addgroup -S app && adduser -S app -G app
USER app                               # NON-ROOT çalış (CVE-2019-5736 önkoşulunu kaldır)

CMD ["php-fpm"]

# .dockerignore — sır/gereksiz dosyaları imaj bağlamından çıkar (Bölüm 25)
.env
.git
*.key
*.pem

# ✅ GÜVENLİ çalıştırma (en az yetki)
docker run \
  --user 10001:10001 \                 # non-root
  --cap-drop=ALL \                     # tüm capabilities düşür
  --cap-add=CHOWN --cap-add=SETUID --cap-add=SETGID \  # yalnızca gerekenler
  --security-opt=no-new-privileges \   # yetki yükseltme engeli
  --read-only \                        # read-only root FS (kalıcılık zor — Bölüm 28)
  --tmpfs /tmp \                        # yazılabilir tek alan
  --memory=256m --cpus=1 \             # kaynak sınırı (DoS)
  --pids-limit=100 \
  myapp@sha256:abc123...               # imaj DIGEST ile sabitlenmiş (Bölüm 30)
# ASLA: --privileged, -v /var/run/docker.sock, -v /:/host
# + Docker daemon'da userns-remap; seccomp/AppArmor profili; güncel runtime

Öne çıkan modern pratikler: - Non-root (USER) + user namespaces: Container root olmasın; userns-remap ile container "root"u host'ta yetkisiz. CVE-2019-5736 önkoşulunu kaldırır. - --cap-drop=ALL + yalnızca gerekli --cap-add: Öntanımlı capability setini daralt. - --no-new-privileges, --read-only root FS + --tmpfs: Yetki yükseltme ve kalıcılık engeli (Bölüm 28). - Privileged/docker.sock/host-mount ASLA: Kolay kaçış köprülerini kaldır. - Minimal + taranmış imaj (Bölüm 30): distroless/alpine; Trivy/Clair ile tara; digest ile sabitle; güvenilir registry + imza. - Sırlar imaja gömülmez (Bölüm 25): .dockerignore + çalışma-zamanı secret'ları. - Kaynak sınırları: --memory, --cpus, --pids-limit (DoS). - seccomp/AppArmor/SELinux profilleri + güncel runtime (CVE-2019-5736).

---

9. Patch Analizi

Neden işe yarar? Non-root + user namespace, CVE-2019-5736 gibi kaçışların önkoşulunu (container-içi-root) kaldırır ve kaçış olsa bile host'ta yetkiyi sınırlar. Privileged/docker.sock kaldırmak, kolay kaçış köprülerini yok eder. --cap-drop=ALL, --read-only, --no-new-privileges ve seccomp, kalan kaçış yollarını daraltır. Minimal + taranmış imaj (Bölüm 30) açık yüzeyini küçültür. Bunlar birlikte, bir uygulama açığı (web shell) container içinde sınırlı kalacak ve host devrine dönüşmeyecek biçimde derinlemesine savunma (Bölüm 1) kurar.

Sertleştirme karşılaştırması:

Ayar	Kaçış riski
root + --privileged + docker.sock	Kritik (trivial host root)
root, sertleştirmesiz	Yüksek (runtime açığı → host)
non-root + cap-drop + read-only	Düşük
+ userns-remap + seccomp + güncel runtime	Çok düşük (katmanlı)

Performans: Sertleştirme ayarlarının çalışma-zamanı maliyeti yok denecek kadar azdır; minimal imajlar daha hızlı çekilir/başlar. Kaynak sınırları zaten iyi bir uygulamadır. Güvenlik kazancı (host devrini engelleme) çok büyüktür.

---

10. Gerçek Hayat Senaryosu

Kurgu — bir SaaS'ın Kubernetes/Docker altyapısı. Kolaylık için container'lar root çalışıyor, biri /var/run/docker.sock'ı mount etmiş (bir "CI helper" için) ve runtime aylardır güncellenmemiş. Bir PHP uygulamasındaki dosya yükleme açığı (Bölüm 19) container içinde web shell'e dönüşünce, saldırgan (container root): (1) mount edilmiş Docker soketi üzerinden yeni bir privileged container başlatıp host FS'ini mount ederek host root'a ulaşır; ya da (2) yamasız runc'ta CVE-2019-5736 ile host runc'ı üzerine yazar. Her iki yolla da tek bir web açığı tüm cluster'ın devrine tırmanır. Doğru sertleştirmeyle: non-root + docker.sock yok + güncel runtime + cap-drop → web shell container içinde sınırlı kalırdı. Dersler: (1) container root olmamalı; (2) docker.sock/privileged asla; (3) runtime güncel tutulmalı — container izolasyonu tek savunma değildir.

---

11. Gerçek CVE Analizi — runc Container Escape (CVE-2019-5736)

Dragon Sector (Adam Iwaniuk, Borys Popławski) bulgusu, runc/Aleksa Sarai koordinasyonu, Palo Alto Unit 42 ve MITRE/NVD ile doğrulanmıştır. Silahlaştırılmış payload verilmez.

Özet. 11 Şubat 2019'da, container çalışma zamanı runc'ta (Docker, containerd, Kubernetes, CRI-O tarafından kullanılan) bir container kaçış açığı açıklandı. Kötü niyetli bir container, host'un runc ikilisini üzerine yazarak host'ta root seviyesinde kod çalıştırabiliyordu — tam container kaçışı. runc < 1.0-rc6 ve Docker < 18.09.2 etkilendi.

Teknik neden — /proc/self/exe ve container-içi-root. docker exec çalıştığında, runc container'a girmek için container dosya sistemindeki bir sembolik link üzerinden /proc/self/exe'yi açar — bu, host'taki runc ikilisine işaret eder (/proc/self/exe, her sürecin çalıştırdığı ikiliye işaret eden, çekirdeğin oluşturduğu sembolik linktir). Saldırgan, container içinde bu sembolik linkin nasıl ve ne zaman çözüldüğünü kontrol ederek, runc çalışırken host'taki runc ikilisine yazabiliyordu. Sonuç: host runc ikilisi saldırganın payload'ıyla üzerine yazılıyor; bir sonraki runc çağrısında (bir yönetici docker exec yaptığında veya kötü imaj çalıştığında) bu payload host'ta root olarak çalışıyordu.

Kritik önkoşul izin modeliyle ilgilidir (Bölüm 28): saldırganın container içinde root (uid 0) olması gerekiyordu. İki saldırı vektörü vardı: (1) saldırgan-kontrollü kötü niyetli bir imaj çalıştırmak (Bölüm 30 tedarik zinciri), (2) saldırganın yazma erişimi olan mevcut bir container'a docker exec ile bağlanılması. runc'ın (ve dolayısıyla tüm kurulumun) host'ta root çalışması, kaçışın neden host root verdiğini açıklar.

Neden non-root ve user namespace önemli. Container içinde non-root çalışan veya user namespaces kullanan (container "root"unu host'ta yetkisiz bir kullanıcıya eşleyen) kurulumlar bu saldırıya çok daha dirençliydi — çünkü saldırgan host runc ikilisine yazma yetkisine sahip olmuyordu. Bu, "container içinde root olma" ilkesinin (Bölüm 28) neden kritik olduğunun somut kanıtıdır.

Etki. Kötü niyetli imaj veya container-içi-root erişimi olan bir saldırgan için tam host devri; Docker/Kubernetes'in yaygınlığı nedeniyle devasa. runc, Docker, Red Hat, AWS, GCP, Kubernetes yamalar yayımladı.

Düzeltme ve mitigasyon. runc 1.0-rc7/Docker 18.09.2 yamaladı. Ek mitigasyonlar: container'ları non-root çalıştırmak, user namespaces (userns-remap), SELinux enforcing, ve güvenilmeyen imajları çalıştırmamak (Bölüm 30).

Çıkarılacak dersler: 1. Container izolasyonu mutlak değildir. Paylaşılan çekirdek + runtime, kaçışa açıktır; derinlemesine savunma şart. 2. Container içinde root olma (Bölüm 28). Non-root + user namespaces, bu ve benzeri kaçışların önkoşulunu kaldırır. 3. Güvenilmez imaj çalıştırma (Bölüm 30). Kötü niyetli imaj, doğrudan bir kaçış vektörüdür. 4. Runtime'ı güncel tut (Bölüm 30 yama). runc/containerd/Docker açıkları hızla silahlaştırılır.

---

12. Detection

Yapılandırma incelemede:

grep -rn 'USER' Dockerfile                     # non-root çalışıyor mu?
docker inspect <c> | grep -iE 'Privileged|CapAdd|ReadonlyRootfs'  # ayarlar
docker inspect <c> --format '{{.Mounts}}' | grep docker.sock      # soket mount?
docker inspect <c> --format '{{.Config.User}}'                    # root mu?
trivy image myapp                              # imaj açık taraması (Bölüm 30)

Kontroller: non-root mu? privileged/docker.sock/host-mount var mı? cap-drop/read-only var mı? imaj minimal/taranmış mı? runtime güncel mi?

SAST/yapılandırma tarama: Dockerfile/compose/K8s manifest denetimi (Hadolint, Trivy config, kube-bench, Checkov); root çalışma, privileged, docker.sock, gömülü sır (Bölüm 25) için kurallar.

İmaj tarama (Bölüm 30): Trivy/Clair/Grype ile taban imajı ve bağımlılıklardaki bilinen açıklar.

Runtime izleme/SIEM: Container'dan host'a olağandışı erişim; runc/docker.sock ile etkileşim; container içinden beklenmeyen ayrıcalıklı süreçler; yeni container başlatma (docker.sock suistimali); dosya bütünlüğü (runc ikilisi değişimi — CVE-2019-5736). Falco gibi container-farkında runtime güvenlik araçları bu davranışları yakalar.

---

13. Prevention

• Non-root (USER) + user namespaces (userns-remap): Container root olmasın (Bölüm 28); kaçış önkoşulunu kaldır.
• --cap-drop=ALL + minimal --cap-add; --no-new-privileges; --read-only root FS.
• Privileged/docker.sock/host-mount ASLA.
• Minimal + taranmış + imzalı imaj (Bölüm 30): distroless/alpine; Trivy; digest sabitleme; güvenilir registry.
• Sırlar imaja gömülmez (Bölüm 25): .dockerignore + çalışma-zamanı secret.
• Kaynak sınırları: memory/cpu/pids (DoS).
• seccomp/AppArmor/SELinux + güncel runtime (CVE-2019-5736 — Bölüm 30).
• En az yetki her katmanda (Bölüm 1).

---

14. Mitigation

• Acil: privileged/docker.sock/host-mount'u kaldır; container'ı non-root'a çevir; runtime'ı yamala (CVE-2019-5736); imajı tara ve açıklı bağımlılıkları güncelle (Bölüm 30).
• Geçici: Kaçış olduysa host'u ele geçirilmiş say; runtime izlemesinden (Falco) kaçış izlerini tara; sızmış imaj sırlarını döndür (Bölüm 25); etkilenen host/cluster'ı yeniden inşa etmeyi değerlendir.
• Kalıcı: Sertleştirilmiş container baseline'ı (non-root, cap-drop, read-only, userns) zorunlu kıl; imaj taramayı + config denetimini (Trivy/Checkov) CI'a ekle; runtime güvenlik izleme kur; yama yönetimini (Bölüm 30) otomatikleştir.

---

15. Checklist

• [ ] Container non-root çalışıyor mu (USER) ve user namespaces etkin mi (Bölüm 28)?
• [ ] --privileged, docker.sock mount ve host-FS mount yok mu?
• [ ] --cap-drop=ALL + yalnızca gerekli capabilities mi?
• [ ] --no-new-privileges ve read-only root FS var mı (Bölüm 28)?
• [ ] Taban imajı minimal (distroless/alpine) ve taranmış mı (Bölüm 30)?
• [ ] İmaj digest ile sabitlenmiş ve güvenilir registry'den mi?
• [ ] Sırlar imaja gömülü değil mi (.dockerignore + secret — Bölüm 25)?
• [ ] Kaynak sınırları (memory/cpu/pids) var mı?
• [ ] seccomp/AppArmor profili ve güncel runtime var mı (CVE-2019-5736)?

---

16. Laboratuvar

Lab 29.1 — Non-root fark. İzole ortamda root ve non-root (USER app) container'lar oluştur; her ikisinde de hangi işlemlerin mümkün olduğunu karşılaştır. Non-root'un yükseltme yüzeyini nasıl daralttığını yaz.

Lab 29.2 — Docker soketi tehlikesi (kavramsal). Bir container'a docker.sock mount etmenin neden host root'a köprü olduğunu (yeni privileged container başlatma) diyagramla; asla üretimde denenmez.

Lab 29.3 — İmaj tarama. Şişkin bir imaj (php:8.3) ile minimal bir imajı (php:8.3-fpm-alpine) Trivy ile tara; açık sayısı farkını gözlemle (Bölüm 30'a bağla).

Lab 29.4 — Sertleştirme. Bir container'ı --cap-drop=ALL --read-only --no-new-privileges ile çalıştır; uygulamanın çalıştığını ve yazma/kalıcılığın kısıtlandığını doğrula.

---

17. Quiz

1. Container neden bir VM değildir? Bu güvenlik açısından ne anlama gelir?
2. "Container içinde root olma" neden tehlikelidir? CVE-2019-5736 ile ilişkisi nedir?
3. User namespaces (userns-remap) bir kaçışta neyi sağlar?
4. --privileged mode neden asla üretimde kullanılmaz?
5. Docker soketini (docker.sock) container'a mount etmek neden host root'a köprüdür?
6. --cap-drop=ALL + seçili --cap-add neden önerilir?
7. CVE-2019-5736'da /proc/self/exe nasıl bir rol oynadı?
8. CVE-2019-5736'nın önkoşulu neydi ve non-root/userns bunu nasıl kaldırır?
9. Minimal taban imajı (distroless/alpine) neden daha güvenlidir (Bölüm 30)?
10. Sırlar neden imaja gömülmemelidir (Bölüm 25)?
11. Read-only root FS bir web shell için neyi zorlaştırır (Bölüm 28)?
12. Container kaçışı neden genellikle "derinlemesine savunma" ile önlenir (tek katman değil)?

---

18. Kaynakça

• OWASP, Docker Security Cheat Sheet; Kubernetes Security Cheat Sheet; CIS Docker/Kubernetes Benchmark.
• MITRE / NVD, CVE-2019-5736 (runc); Dragon Sector, Escape from Docker and Kubernetes containers to root on host; Palo Alto Unit 42, Breaking Docker via runC.
• Docker resmi güvenlik dokümantasyonu (rootless, userns-remap, capabilities, seccomp); NIST SP 800-190 (Application Container Security Guide).
• MITRE, CWE-269 (Privilege Management), CWE-250 (Unnecessary Privileges).
• Trivy / Clair / Falco / Hadolint dokümantasyonu (imaj tarama ve runtime güvenlik).