📌 Hızlı Özet & Temel Çıkarım:
Linux Container İzolasyonu, sanal makinelerin getirdiği hipervizör (hypervisor) yükü olmadan işletim sistemi düzeyinde süreçleri birbirinden ayıran hafif bir sanallaştırma modelidir. Çekirdeğin sunduğu namespaces ile görünürlük alanları, cgroups v2 ile CPU/RAM tüketim limitleri ve seccomp/AppArmor profilleri ile sistem çağrısı sınırlandırmaları uygulanarak; tek bir sunucu üzerinde yüzlerce izole servis tam güvenlik ve maksimum verimlilikle çalıştırılır.

1. Container ve Sanal Makine (VM) Arasındaki Çekirdek Farkı

Geleneksel sanal makinelerde (KVM, VMware vb.) her sanal makine kendi misafir işletim sistemi çekirdeğini (Guest OS Kernel) yükler ve RAM’de yüzlerce megabaytlık sabit ayak izi bırakır. Bu durum hem açılış süresini dakikalara çıkarır hem de donanım kaynaklarını israf eder.

Docker ve OCI (Open Container Initiative) uyumlu container çalışma zamanları ise doğrudan ana makinenin Linux çekirdeğini paylaşır. İzolasyon fiziksel değil, çekirdeğin sunduğu mantıksal duvarlarla sağlanır:

  • PID Namespace: Container içindeki işlemler sadece kendi süreç ağacını görür; ana makinedeki diğer işlemleri listeyemez.
  • Network Namespace: Her container bağımsız sanal ethernet (veth) arayüzüne, kendi routing tablosuna ve IP adresine sahiptir.
  • Mount Namespace: Kök dosya sistemi (/) ana sistemden izoledir; sadece container imajındaki dosyalar görünür.

2. cgroups v2 ile Bellek ve CPU Boğulmalarını Önleme

Bir container içindeki kodda bellek sızıntısı (memory leak) olduğunda veya sonsuz döngüye girdiğinde, tüm ana sunucunun kilitlenmesini engellemek için Control Groups (cgroups) zorunludur.

Linux çekirdeğinin modern cgroups v2 mimarisi, kaynak sınırlarını birleşik bir hiyerarşide yönetir.

Production seviyesinde güvenli bir docker-compose.yml servis tanımı:

services:
  payment-api:
    image: mycompany/payment-api:v2.4
    restart: unless-stopped
    user: "10001:10001" # Rootless kullanici (guvenlik)
    read_only: true       # Kok dosya sistemini salt okunur yap
    tmpfs:
      - /tmp:size=64M     # Gecici dosya yazimi icin RAM diski
    deploy:
      resources:
        limits:
          cpus: '1.5'     # Maksimum 1.5 CPU cekirdegi tuketebilir
          memory: 512M    # 512 MB asildiginda OOM-killer calisir
        reservations:
          cpus: '0.25'
          memory: 128M
    security_opt:
      - no-new-privileges:true
      - seccomp:unconfined # Ozel durumlarda profille, standartta default koru
    cap_drop:
      - ALL               # Tum Linux yetkilerini kaldir
    cap_add:
      - NET_BIND_SERVICE  # Sadece 80/443 portu dinleme yetkisi ver

3. Rootless Container Mimarisi Neden Hayatidir?

Geleneksel Docker kurulumlarında container içindeki root kullanıcısı (UID 0), ana sunucudaki root yetkileriyle doğrudan eşleşir. Eğer container imajında veya çalıştırılan bir kütüphanede uzaktan kod yürütme (RCE) açığı çıkarsa, saldırgan sunucunun ana kontrolünü ele geçirebilir.

Rootless Docker veya Podman kullanarak, container içi UID 0 değeri ana makinede ayrıcalıksız bir kullanıcıya (örneğin UID 100000) haritalanır (User Namespace remapping). Bu sayede container kaçışı (container breakout) gerçekleşse dahi saldırgan ana işletim sisteminde sıradan, yetkisiz bir kullanıcı olarak hapsolur.

4. İlgili Konular ve İç Bağlantılar

5. Sıkça Sorulan Sorular

Dockerfile hazırlarken multi-stage build neden tercih edilmelidir?

Multi-stage build, derleme aşamasında kullanılan derleyicileri, SDK’ları ve geçici kütüphaneleri nihai imajın dışında bırakır. Bu durum imaj boyutunu 1 GB’tan 30 MB’a düşürürken, imajın saldırı yüzeyini (attack surface) dramatik oranda azaltır.

Alpine Linux tabanlı imajlar her zaman en iyi seçenek midir?

Alpine çok küçüktür (5 MB) ancak glibc yerine musl libc kullanır. C++ eklentileri olan Python paketlerinde veya karmaşık C derlemelerinde beklenmedik performans kayıplarına ve bellek tahsis sorunlarına yol açabilir. Bu durumlarda Debian-slim veya Google Distroless tercih edilmelidir.

6. Üretim Seviyesinde Docker Güvenlik Kontrol Listesi (Hardening Checklist)

Container tabanlı mikroservisleri canlı sunucularda çalıştırmadan önce sistem yöneticilerinin ve DevOps mühendislerinin uygulaması gereken standart adımlar:

  • Minimal Taban İmajlar: ubuntu:latest veya node:latest gibi yüzlerce gereksiz paket içeren imajlar yerine alpine, distroless veya scratch kullanılmalıdır.
  • Salt Okunur Kök Dosya Sistemi (--read-only): Saldırganın container içine dosya indirmesini veya mevcut ikili dosyaları değiştirmesini engeller. Günlük loglar ve geçici veriler yalnızca tmpfs RAM disklerine yazılmalıdır.
  • Yetki Kısıtlama (--cap-drop=ALL): Linux çekirdeğinin sunduğu 40’tan fazla ayrıcalıktan (capabilities) varsayılan olarak hepsi iptal edilmeli, sadece servisin mecbur olduğu (örneğin sadece port dinleme yetkisi) tek tek eklenmelidir.
  • Gizli Bilgilerin Yönetimi (Docker Secrets): Şifreler ve API anahtarları asla Dockerfile içinde ENV olarak tanımlanmamalıdır; docker secret veya HashiCorp Vault gibi araçlarla çalışma zamanında dinamik olarak belleğe monte edilmelidir.

7. Container Güvenliğinde Linux Seccomp ve AppArmor Profilleri

Container süreçlerinin Linux çekirdeğine doğrudan güvensiz sistem çağrıları (syscalls) yapmasını engellemek için Seccomp (Secure Computing Mode) filtreleri kullanılır.

Standart bir Linux çekirdeğinde 300’den fazla sistem çağrısı bulunur; ancak sıradan bir web API’si bunların yalnızca 40-50 tanesine ihtiyaç duyar. Kötü niyetli bir container kaçışında saldırganlar genellikle ptrace, sys_chroot veya reboot çağrılarını hedefler.

Aşağıdaki özel Seccomp profil kuralı, container içinden gelebilecek tehlikeli çekirdek modifikasyonu çağrılarını engeller:

{
  "defaultAction": "SCMP_ACT_ERRNO",
  "architectures": [ "SCMP_ARCH_X86_64" ],
  "syscalls": [
    {
      "names": [ "read", "write", "exit", "futex", "nanosleep", "epoll_wait" ],
      "action": "SCMP_ACT_ALLOW"
    }
  ]
}

Bu katı filtre uygulandığında, container içindeki kod root yetkisi alsa dahi çekirdek seviyesinde yasaklı çağrıları yürütemez ve sistem çökertilemez.

8. Docker İmajlarında Çok Katmanlı Güvenlik Denetimi ve Distroless Yaklaşımı

Üretim ortamında çalışan container’ların içinde bash, curl, apt veya sh gibi kabuk (shell) araçlarının bulunması saldırganların işini kolaylaştırır. Bir açığı istismar eden saldırgan ilk olarak curl ile dışarıdan zararlı komut dosyası indirmeye çalışır.

Google’ın sunduğu Distroless taban imajları, container içinde yalnızca uygulamanızı ve onun doğrudan çalışma zamanı bağımlılıklarını barındırır:

  • İçinde paket yöneticisi yoktur.
  • İçinde terminal veya kabuk bulunmaz.
  • Bir saldırgan uzaktan kod çalıştırsa bile komut çalıştırabileceği bir terminal bulamaz. Bu yaklaşım, container güvenliğinde en yüksek savunma standardı olan “saldırganın elindeki araçları alma” ilkesini hayata geçirir.