Docker Güvenliği: Konteyner Sertleştirme Rehberi

Kısa cevap: Docker güvenliğinde en yüksek getirili beş önlem şunlardır: docker grubu üyeliğini sudo kadar ciddiye almak, konteynerleri root olmayan kullanıcıyla çalıştırmak, gereksiz capability’leri düşürmek, dosya sistemini mümkün olduğunda salt okunur bağlamak ve Docker soketini konteynere vermemek. Bunların hepsi birkaç satırlık yapılandırma değişikliğidir ve hiçbiri uygulama kodunu değiştirmeyi gerektirmez.

Temel gerçek: Docker daemon root olarak çalışır

Docker güvenliğinin tamamı bu cümleden türer. Varsayılan kurulumda dockerd süreci root yetkisiyle çalışır ve ona komut verebilen herkes, dolaylı olarak root yetkisine sahiptir.

Bunun en somut sonucu docker grubudur. Bir kullanıcıyı bu gruba eklemek, ona sunucuda root yetkisi vermekle pratik olarak aynı şeydir. Neden basittir: o kullanıcı, ana sistemin kök dizinini bağlayan bir konteyner çalıştırabilir ve içeriden ana sistemin dosyalarına root olarak erişebilir.

Buradan çıkan kural: docker grubu üyeliğini parolasız sudo yetkisi gibi değerlendirin. Grup üyeliğini yalnız sunucuda zaten tam yetkili olan kişilere verin; “sadece konteyner çalıştırsın” diye verilen bir üyelik, aslında tam yetki vermektir.

Kimlerin bu yetkiye sahip olduğunu görün:

getent group docker

Rootless Docker: daemon’u yetkisiz çalıştırmak

Rootless mod, Docker daemon’ını sıradan bir kullanıcı olarak çalıştırır. Konteynerler kullanıcı ad alanı içinde koşar; içerideki root, ana sistemde yetkisiz bir kullanıcıya eşlenir.

Kurulum:

# Root olmayan kullanıcı olarak
dockerd-rootless-setuptool.sh install

# Ortam değişkeni (kabuk profiline eklenir)
export DOCKER_HOST=unix:///run/user/$(id -u)/docker.sock

Kazanç gerçektir: konteynerden çıkış sağlayan bir açık kullanılsa bile saldırganın eline geçen yetki, sıradan bir kullanıcınınkidir.

Bedelini de bilin:

• 1024’ün altındaki portlar doğrudan dinlenemez. 80 ve 443 portları için ya bir yetki tanımı gerekir ya da trafiği yüksek portlara yönlendiren bir katman. Ters vekil sunucuyu zaten ana sistemde çalıştırıyorsanız bu kısıt sorun yaratmaz.
• Bazı ağ modları ve depolama sürücüleri kısıtlıdır. Özellikle macvlan gibi modlar kullanılamaz; ayrıntısı Docker ağ yapılandırması yazısında.
• Ağ performansında bir miktar kayıp olabilir.

Karar kuralı: bu üç kısıt iş yükünüzü etkilemiyorsa rootless moda geçin. Etkiliyorsa, klasik kurulumda kalıp aşağıdaki diğer önlemleri uygulayın; onlar da tek başına ciddi kazanç sağlar.

Konteyner root olmayan kullanıcıyla nasıl çalıştırılır?

Varsayılan olarak konteyner içindeki süreçler root olarak çalışır. Bu, konteyner sınırını aşan bir açık kullanıldığında saldırganın elindeki yetkiyi belirler.

Dockerfile içinde:

FROM node:22-alpine

WORKDIR /app
COPY --chown=node:node . .
RUN npm ci --omit=dev

# Ayrıcalıkları düşür (imajda hazır gelen node kullanıcısı)
USER node

CMD ["node", "server.js"]

İmajı siz üretmiyorsanız compose tarafında da belirtebilirsiniz:

services:
  web:
    image: ucuncu-taraf-imaj:1.2.3
    user: "1000:1000"

Bir uyarı: bazı imajlar açılış sırasında root gerektiren işler yapar (izin düzeltme, port bağlama). user alanını eklediğinizde konteyner açılmıyorsa, imajın dokümantasyonuna bakın; genellikle bir ortam değişkeniyle veya farklı bir giriş noktasıyla çözülür. Bu durumda dosya sahipliğini önceden düzeltmek gerekebilir; izin yönetiminin ayrıntısı Docker veri kalıcılığı yazısında.

Capability nasıl düşürülür, ayrıcalık yükseltme nasıl engellenir?

Linux’ta root yetkisi tek parça değildir; capability adı verilen parçalara ayrılmıştır (ham soket açma, dosya sahipliği değiştirme, çekirdek modülü yükleme gibi). Docker konteynerlere varsayılan olarak bunlardan bir alt küme verir; çoğu uygulamanın bunların neredeyse hiçbirine ihtiyacı yoktur.

En güvenli yaklaşım hepsini düşürüp yalnız gerekeni geri vermektir:

services:
  web:
    image: benim-uygulamam:1.4.2
    cap_drop:
      - ALL
    cap_add:
      - NET_BIND_SERVICE      # yalnız 1024 altı port dinlemek gerekiyorsa
    security_opt:
      - no-new-privileges:true
    read_only: true
    tmpfs:
      - /tmp

Her satırın karşılığı:

• cap_drop: ALL: tüm ek yetkileri kaldırır. Çoğu web uygulaması bundan etkilenmez.
• no-new-privileges:true: konteyner içindeki bir sürecin setuid ikili dosyalar aracılığıyla yetki yükseltmesini engeller. Maliyeti sıfır, kazancı gerçek; neredeyse her serviste açık olmalıdır.
• read_only: true: konteynerin kök dosya sistemini salt okunur bağlar. Kod enjeksiyonu başarılı olsa bile saldırgan kalıcı bir dosya bırakamaz.
• tmpfs: /tmp: salt okunur dosya sistemiyle çalışan uygulamaların geçici dosya ihtiyacını bellekte karşılar.

read_only ilk denemede bazı uygulamaları bozar (geçici dosya, önbellek veya soket yazan uygulamalar). Doğru yaklaşım vazgeçmek değil, hangi dizine yazdığını bulup onu tmpfs veya hacim olarak eklemektir:

# Konteyner neden yazamadı, hangi yola yazmaya çalışıyor
docker compose logs web | grep -i -E "permission|read-only|EACCES|EROFS"

Docker soketini konteynere vermek neden tehlikeli?

Bazı araçlar (izleme ajanları, otomatik imaj güncelleyiciler, dağıtım panelleri) Docker soketine erişim ister:

volumes:
  - /var/run/docker.sock:/var/run/docker.sock    # dikkat

Bu satırın anlamı şudur: bu konteyner, ana sistemde root yetkisine eşdeğer bir güce sahiptir. Soket erişimiyle yeni konteynerler oluşturulabilir, ana sistemin kök dizini bağlanabilir ve dosyalar okunup yazılabilir. Konteyner izolasyonu bu noktada tamamen ortadan kalkar.

Uygulanabilir yaklaşımlar:

1. Gerçekten gerekli mi diye sorun. Birçok araç, soket erişimi olmadan da ihtiyacınız olan işi yapabilir.
2. Salt okunur bağlayın (:ro). Tam koruma değildir ama bazı yazma işlemlerini engeller.
3. Araya bir yetki kısıtlayıcı vekil koyun. Soketi doğrudan vermek yerine, yalnız izin verilen API çağrılarını geçiren bir aracı kullanılabilir.
4. Soket erişimi olan konteyneri güven sınırının içinde sayın. O konteynere giren, sunucuya girmiştir. Aynı sunucuda başka güven seviyeleri barındırıyorsanız, o iş yükünü ayrı bir sanal makineye taşıyın; gerekçesi LXC, Docker ve sanal makine yazısında.

İmaj güvenliği: içinde ne var?

Konteyner güvenliğinin gözden kaçan yarısı imajdır. Çalıştırdığınız imaj, sizin yazmadığınız yüzlerce paketi taşır.

Dört alışkanlık:

1. Kaynağa dikkat edin. Resmi imajları veya doğrulanmış yayıncıları tercih edin. Bilinmeyen bir depodan çekilen imaj, sunucunuzda root olarak çalışacak kodu getirir.

2. Sürümü sabitleyin. latest etiketi, hangi kodu çalıştırdığınızı bilmemek demektir. Gerekçesi ve yöntemi Docker Compose üretim rehberinde.

3. En küçük temel imajı seçin. alpine veya minimal imajlar yalnız disk tasarrufu değil, güvenlik kazancıdır: içinde olmayan paketin açığı da olmaz. Bir kabuk bile içermeyen minimal imajlar, ele geçirilmiş bir uygulamada saldırganın elini belirgin biçimde bağlar.

4. Düzenli tarayın ve güncelleyin. İmajlar zamanla eskir; kurduğunuz gün güvenli olan imaj altı ay sonra bilinen açıklar taşıyabilir. Docker’ın kendi tarama komutu bir başlangıç noktasıdır:

docker scout cves benim-uygulamam:1.4.2

Otomatik güncelleme araçları (imaj değiştiğinde konteyneri yenileyenler) kolaylık sağlar ama iki riski vardır: soket erişimi isterler ve test edilmemiş bir sürümü doğrudan üretime alabilirler. Üretimde güncellemeyi bilinçli bir işlem olarak tutmayı tercih ediyorum.

Konteyner portları dışarıya nasıl kapatılır?

Konteyner güvenliğinin en somut ayağı, dışarıya ne açtığınızdır.

# YANLIŞ: veritabanı tüm arayüzlerde dışarı açık
ports:
  - "5432:5432"

# DOĞRU: yalnız yerelden erişilebilir
ports:
  - "127.0.0.1:5432:5432"

# EN İYİSİ: hiç yayımlama, konteynerler iç ağda konuşsun

Docker’ın port yayımlama kuralları, ufw’nin filtre zincirinden önce değerlendirilir; bu yüzden ufw’de kapalı görünen bir port dışarıdan erişilebilir olabilir. Konunun tamamı Linux firewall rehberinde, ağ modelleri Docker ağ yapılandırması yazısında.

Dışarı sunulması gereken servisler ters vekil sunucu arkasından yayımlanmalıdır; seçenekler nginx, Traefik ve Caddy karşılaştırmasında.

Gerçekten ne açık olduğunu doğrulayın:

sudo ss -tulpn | grep LISTEN
# 0.0.0.0:PORT satırlarının her biri açıklanabilir olmalı

Sertleştirilmiş servis örneği

Yukarıdaki önlemlerin hepsini içeren bir servis tanımı:

services:
  web:
    image: benim-uygulamam:1.4.2
    restart: unless-stopped
    user: "1000:1000"
    read_only: true
    tmpfs:
      - /tmp
    cap_drop:
      - ALL
    security_opt:
      - no-new-privileges:true
    ports:
      - "127.0.0.1:3000:3000"
    environment:
      DATABASE_URL: ${DATABASE_URL}
    volumes:
      - uygulama-verisi:/app/data
    deploy:
      resources:
        limits:
          memory: 512M
          cpus: "1.0"
    logging:
      driver: json-file
      options:
        max-size: "10m"
        max-file: "3"
    networks:
      - arka-uc

volumes:
  uygulama-verisi:

networks:
  arka-uc:

Bu tanımda konteyner: yetkisiz kullanıcıyla çalışıyor, kök dosya sistemi salt okunur, tüm ek yetkiler düşürülmüş, yetki yükseltme kapalı, portu yalnız yerele bağlı, kaynakları sınırlı ve logları rotasyonlu.

Sertleştirme kontrol listesi

• docker grubu üyeleri denetlendi, yalnız yöneticiler var
• Uygun iş yüklerinde rootless mod değerlendirildi
• Konteynerler root olmayan kullanıcıyla çalışıyor (user veya Dockerfile USER)
• no-new-privileges:true her serviste tanımlı
• cap_drop: ALL, yalnız gereken capability geri eklenmiş
• Mümkün olan servislerde read_only: true ve tmpfs
• Docker soketi hiçbir konteynere verilmiyor (veriliyorsa gerekçesi yazılı)
• İmajlar resmi kaynaktan, sürümleri sabit, temel imajlar minimal
• İmajlar düzenli taranıyor ve güncelleniyor
• Portlar 127.0.0.1: ile bağlı, dışa açıklar ters vekil arkasında
• Kaynak sınırları tanımlı (kaçak konteyner sunucuyu düşürmesin)
• Kalıcı veri hacimlerde ve yedekleniyor

Bu liste, konteyner katmanının güvenliğini çoğu kurulumun ihtiyacının üzerine çıkarır. Altındaki sunucu katmanı da aynı disiplinle sertleştirilmeli: VPS ilk 30 dakika, SSH sertleştirme ve Linux firewall yazıları bu zemini kuruyor. Bütünün haritası Linux sunucu yönetimi yol haritasında.

Konteyner altyapısının güvenlik denetimi kurumsal ölçekte yapılacaksa siber güvenlik hizmet sayfasına bakabilirsiniz.

Kaynaklar

• Docker security (daemon yetkisi, izolasyon mekanizmaları)
• Rootless mode (kurulum ve bilinen kısıtlar)
• capabilities(7) manual page (Linux yetki parçalama modeli)