Docker Container Güvenliği: Derinlemesine Uygulamalar ve Gerçek Dünya Senaryoları

13 Mayıs 2026 · Gökhan Güngör

Docker Container Güvenliği: Kapsamlı Savunma Katmanları

Modern uygulama mimarilerinde Docker konteynerleri, çeviklik ve ölçeklenebilirlik sunsa da, beraberinde ciddi güvenlik zorlukları getirir. Bir konteynerin izole yapısı, yanlış yapılandırıldığında veya zafiyet içerdiğinde tüm sistemi riske atabilir. Bu doküman, Docker tabanlı üretim ortamlarınızı güvence altına almak için uygulamanız gereken temel stratejileri ve derin teknik yaklaşımları ele almaktadır.

Minimal Base İmaj Kullanımı

Her konteyner imajı, temel bir işletim sistemi katmanıyla başlar. Bu temel imajın boyutu ve içerdiği bileşen sayısı, potansiyel saldırı yüzeyini doğrudan etkiler. Minimalist imajlar (örneğin Alpine Linux tabanlı), gereksiz paket ve servisleri dışarıda bırakarak zafiyet riskini önemli ölçüde azaltır.

# Kötü Uygulama: Gereksiz bileşenler içeren büyük bir imaj kullanmak
FROM ubuntu:latest
RUN apt-get update && apt-get install -y python3 curl procps
COPY . /app
WORKDIR /app
CMD ["python3", "app.py"]

# İyi Uygulama: Minimalist Alpine tabanlı imaj
FROM alpine:3.18
RUN apk add --no-cache python3 py3-pip
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . /app
WORKDIR /app
CMD ["python3", "app.py"]

Gerçek Dünya Senaryosu: Büyük bir mikroservis mimarisine sahip bir e-ticaret platformunda, geliştirme ekipleri Dockerfile'larında node:latest veya openjdk:latest gibi imajlar kullanmaktaydı. Güvenlik denetimlerinde, bu imajların çok sayıda CVE içerdiği tespit edildi. Güvenlik ekibi, tüm CI/CD pipeline'larını, node:alpine veya openjdk:slim-buster gibi minimalist alternatiflere geçişi zorunlu kılacak şekilde güncelledi. Bu geçiş, imaj boyutlarını %60 oranında düşürdü ve tarama sonuçlarındaki kritik zafiyet sayısını sıfırladı. Hatta bazı durumlarda multi-stage build'ler kullanılarak sadece derlenmiş ikilinin nihai imaja dahil edilmesiyle daha da küçülme sağlandı.

Least Privilege İlkesi ve Kullanıcı Yönetimi

Konteynerleri root kullanıcısıyla çalıştırmak, en yaygın güvenlik açıklarından biridir. Bir saldırgan konteynerden kaçmayı başarırsa, ana makine üzerinde root yetkileriyle hareket edebilir. Uygulamalarınızı, konteyner içinde mümkün olan en az yetkiye sahip bir kullanıcıyla çalıştırmanız esastır.

# Kötü Uygulama: Root olarak çalıştırmak (varsayılan davranış)
FROM alpine:3.18
...
CMD ["./app"]

# İyi Uygulama: Özel bir kullanıcı oluşturup onunla çalıştırmak
FROM alpine:3.18
RUN addgroup -S appgroup && adduser -S appuser -G appgroup
USER appuser
...
CMD ["./app"]

Gerçek Dünya Senaryosu: Bir finansal hizmetler sağlayıcısında, kritik veri işleyen bir arka uç servisi Docker konteynerinde çalışıyordu. Başlangıçta root olarak çalıştırılan bu servis, güvenlik denetiminde yüksek riskli olarak işaretlendi. Ekip, Dockerfile'a RUN adduser -D appuser ve USER appuser komutlarını ekleyerek servisi özel bir kullanıcı altında çalışacak şekilde yeniden yapılandırdı. Ayrıca, konteyner içindeki dosya sistemindeki ilgili dizinlerin sahiplikleri de bu appuser kullanıcısına verildi. Bu sayede, olası bir konteyner ihlalinde, saldırganın ana makineye erişim yetkileri kısıtlanmış oldu.

İmaj Zafiyet Taraması ve CI/CD Entegrasyonu

Docker imajları, temel işletim sistemi paketlerinden uygulama bağımlılıklarına kadar birçok katman içerir. Bu katmanlarda bilinen zafiyetler (CVE'ler) bulunabilir. İmajlarınızı sürekli olarak taramak ve CI/CD pipeline'ınızın bir parçası haline getirmek, bu riskleri erkenden tespit etmenin ve gidermenin kritik bir yoludur.

# Trivy ile Docker imajı tarama örneği
# CI/CD pipeline'ınızda bir adım olarak eklenebilir

- name: Scan Docker Image for Vulnerabilities
  run: |
    docker build -t my-app:latest .
    trivy image --exit-code 1 --severity CRITICAL,HIGH my-app:latest

# --exit-code 1: Kritik veya yüksek seviyeli zafiyet bulunursa pipeline başarısız olur
# --severity CRITICAL,HIGH: Sadece kritik ve yüksek seviyeli zafiyetleri raporla

Gerçek Dünya Senaryosu: Bir SaaS firması, her kod değişikliğinde yeni Docker imajları oluşturuyor ve bunları Kubernetes kümelerine deploy ediyordu. Başlangıçta zafiyet taraması manuel veya düzenli aralıklarla yapılıyordu. Bu durum, önemli zafiyetlerin üretim ortamına ulaşmasına neden oluyordu. Çözüm olarak, GitLab CI pipeline'larına Aquasec Trivy entegre edildi. Her docker push işleminden önce imaj taraması zorunlu kılındı. Belirlenen eşiklerin (örneğin, 3'ten fazla yüksek seviyeli zafiyet) aşılması durumunda, pipeline otomatik olarak durduruluyor ve geliştiricilere bildirim gönderiliyordu. Bu proaktif yaklaşım, üretimdeki zafiyet sayısını %90 oranında azalttı.

Secrets Yönetimi: Asla İmaj İçinde Saklama

Veritabanı şifreleri, API anahtarları veya özel sertifikalar gibi hassas bilgiler (secrets) asla Docker imajlarının içinde, Dockerfile'da veya doğrudan konteyner ortam değişkenlerinde saklanmamalıdır. Bu tür bir yaklaşım, imajın veya konteynerin ele geçirilmesi durumunda tüm hassas verilere yetkisiz erişim yolunu açar. Bunun yerine, Docker Secrets, Kubernetes Secrets, AWS Secrets Manager, HashiCorp Vault gibi özel çözümler kullanılmalıdır.

# Kötü Uygulama: Secrets'ı Dockerfile'a gömmek
FROM alpine:3.18
ENV DB_PASSWORD="mysecretpassword"  # ASLA YAPMAYIN!

# Daha İyi Uygulama: Docker Secrets ile çalıştırma
# Servisi başlatırken secret'ı bağlama:
# docker service create --name my-app --secret my_db_password my-app:latest
# Konteyner içinde /run/secrets/my_db_password olarak erişilebilir.

# Uygulama kodunda erişim:
# with open('/run/secrets/my_db_password', 'r') as f:
#    db_password = f.read().strip()

Gerçek Dünya Senaryosu: Bir fintech şirketi, arka uç servislerinin veritabanı kimlik bilgilerini doğrudan Docker Compose dosyalarında ortam değişkenleri olarak saklıyordu. Bir geliştiricinin dizüstü bilgisayarının çalınmasıyla, hassas bilgilere erişim riski doğdu. Bu olayın ardından, şirket AWS Secrets Manager'ı uygulamaya karar verdi. Tüm servisler, AWS IAM rollerini kullanarak Secrets Manager'dan çalışma zamanında kimlik bilgilerini çekecek şekilde yeniden düzenlendi. Konteynerler artık hiçbir hassas bilgiyi içermiyor, bunun yerine AWS KMS tarafından şifrelenmiş ve IAM politikalarıyla kısıtlanmış bir hizmet aracılığıyla güvenli bir şekilde erişiyorlardı. Bu, güvenlik duruşunu önemli ölçüde güçlendirdi ve denetim uyumluluğunu artırdı.

Ağ Segmentasyonu ve Güvenlik Duvarları

Konteynerler arasında gereksiz ağ bağlantılarını kısıtlamak ve dış dünyaya açılan portları minimumda tutmak, saldırı yüzeyini daraltır. Docker'ın kendi ağ sürücüleri veya orkestrasyon araçlarının (Kubernetes, ECS) ağ politikaları kullanılarak mikro segmentasyon uygulanabilir. Güvenlik grupları ve ağ ACL'leri de bu katmanda kritik rol oynar.

# Docker özel bir köprü ağı oluşturma ve konteynerleri bu ağa bağlama
docker network create --driver bridge --subnet 172.18.0.0/16 my-isolated-network
docker run -d --name db-service --network my-isolated-network my-db-image
docker run -d --name app-service --network my-isolated-network my-app-image

# Sadece gerekli portları açma
docker run -d -p 8080:80 --name web-app my-web-app-image
# Sadece 80 portu dışarıya açık, 8080 host portuna maplenmiş

Gerçek Dünya Senaryosu: Bir medya şirketi, farklı servislerin (API ağ geçitleri, mikroservisler, veritabanları) tek bir flat network üzerinde çalıştığı bir Docker Swarm kümesine sahipti. Bu durum, bir servisteki ihlalin diğer servislere yatay hareket riskini artırıyordu. Çözüm olarak, Kubernetes'e geçiş yapıldı ve Network Policies uygulanarak her mikroservis sadece iletişim kurması gereken diğer servislerle konuşabilecek şekilde izole edildi. Örneğin, ödeme servisi sadece banka API'si ve sipariş servisi ile iletişim kurabilirken, diğer iç servislerle bağlantısı kesildi. Ayrıca, AWS Security Groups ile EKS nodelarına gelen ve giden trafik sıkı bir şekilde kontrol altına alındı, sadece HTTPS portu dışarıdan erişime açıldı.

Runtime Güvenliği: AppArmor ve Seccomp

Docker konteynerleri, varsayılan olarak Linux çekirdeğinin güvenlik mekanizmalarından (AppArmor, Seccomp) faydalanır. Ancak, bu profiller genellikle genel amaçlıdır. Hassas uygulamalar için özel AppArmor profilleri veya Seccomp filtreleri oluşturarak, konteynerin yapabileceği sistem çağrılarını ve dosya sistemi erişimlerini daha ince taneli bir şekilde kısıtlayabilirsiniz. Bu, bir konteyner ihlal edildiğinde bile saldırganın potansiyel hasarını sınırlar.

# Docker'ı özel bir AppArmor profiliyle çalıştırma
docker run --security-opt apparmor=my_custom_profile my-app:latest

# Örnek AppArmor profili (my_custom_profile.d)
# /etc/apparmor.d/my_custom_profile
# Bu profil sadece /usr/bin/my_app_binary'ye okuma ve çalıştırma izni verir

#include <tunables/global>

profile my_custom_profile flags=(attach_disconnected, complain) {
  #include <abstractions/base>
  file,

  # Kendi uygulamanızın ikili dosyasına erişim
  /usr/bin/my_app_binary rcx,

  # Yasaklanan tüm diğer dosya işlemleri
  deny @{HOME}/** rwklx,
  deny /etc/** wklx,
  deny /proc/** wklx,
  deny /sys/** wklx,
  deny /dev/** wklx,
  
  # Sistem çağrılarını kısıtlamak için seccomp kullanılabilir
}

Gerçek Dünya Senaryosu: Bir blockchain düğümü çalıştırma servisi sunan bir şirket, konteynerlerinin çekirdek erişimini daha da sıkılaştırmak istedi. Varsayılan Seccomp profili yerine, sadece gerekli sistem çağrılarına izin veren özel bir Seccomp profilini elle yazdı. Bu profil, ağ soketleri, dosya okuma/yazma ve temel işlem yönetimi gibi kritik işlevlere izin verirken, sistem ayarlarını değiştirebilecek veya çekirdek modüllerini yükleyebilecek tüm diğer çağrıları engelledi. Docker komutlarına --security-opt seccomp=my_custom_seccomp.json parametresi eklenerek dağıtım yapıldı. Bu sayede, potansiyel bir zafiyetin kötüye kullanılması durumunda dahi, çekirdek seviyesindeki saldırı yüzeyi minimuma indirildi.

Kapsamlı Loglama ve İzleme

Güvenlik olaylarını tespit etmek ve kök neden analizini yapmak için konteyner ve ana makine seviyesinde kapsamlı loglama ve izleme kritik öneme sahiptir. Docker'ın yerleşik loglama sürücülerini kullanarak logları merkezi bir log yönetimi sistemine (ELK Stack, Splunk, CloudWatch Logs, Grafana Loki) yönlendirmelisiniz. Ayrıca, konteynerlerin kaynak tüketimi, ağ trafiği ve işlem aktiviteleri gibi metrikleri izleyerek anormal davranışları erken tespit edebilirsiniz.

# Docker daemon'ı syslog sürücüsünü kullanacak şekilde yapılandırma
# /etc/docker/daemon.json
{
  "log-driver": "syslog",
  "log-opts": {
    "syslog-address": "udp://127.0.0.1:514",
    "tag": "{{.Name}}/{{.ID}}"
  }
}

# Tek bir konteyner için farklı bir log sürücüsü kullanma
docker run -d --log-driver=json-file --log-opt max-size=10m --log-opt max-file=3 my-app:latest

Gerçek Dünya Senaryosu: Büyük bir finansal kurum, yüzlerce Docker konteynerini AWS ECS üzerinde çalıştırıyordu. Güvenlik ihlallerini tespit etmekte zorlanıyorlardı çünkü loglar dağınık ve standart dışıydı. Mevcut durumu iyileştirmek için, tüm ECS görev tanımları, loglarını doğrudan Amazon CloudWatch Logs'a gönderecek şekilde yapılandırıldı. Ayrıca, CloudWatch Logs'a entegre edilmiş bir AWS Lambda fonksiyonu, belirlenen anahtar kelimeler (örneğin, "failed login", "permission denied") veya anormal log hacimleri tespit ettiğinde otomatik olarak güvenlik ekibine bildirim gönderiyordu. Prometheus ve Grafana kullanarak konteyner metrikleri (CPU, bellek, ağ G/Ç) izleniyor, böylece anormal kaynak tüketimi veya dışarıya giden yüksek trafik gibi göstergelerle potansiyel saldırılar proaktif olarak tespit edilebiliyordu.

← Blog Listesine Dön