Çok Kiracılı Docker İzolasyonu İçin Adım Adım Rehber

Özet

Birden fazla müşteri kampanyası veya dahili web varlığı için paylaşılan altyapıyı yönetmek; barındırma maliyetleri ve veri güvenliği konularında üst yönetimle sıklıkla sürtüşmelere yol açar. Docker konteynerleri, tahsis edilmiş sanal makinelere hafif bir alternatif sunar ancak varsayılan kurulumlar ciddi izolasyon açıkları barındırır. Gerçek bir çok kiracılık (multi-tenancy); çekirdek, süreç, ağ ve depolama düzeylerinde bilinçli sınırlar çekmeyi gerektirir. Bu kılavuz, yerel Linux izolasyon temellerini kullanarak çok kiracılı Docker dağıtımlarını güvenli hale getirmek için pratik, beş adımlı bir çerçeve sunmaktadır. Kaynak kotalarını nasıl zorunlu kılacağınızı, süreç yetkilerini nasıl kısıtlayacağınızı, konteyner ağlarını nasıl segmentlere ayıracağınızı ve doğru izolasyon katmanını nasıl seçeceğinizi öğreneceksiniz. Bu planı takip ederek kiracı ortamlarını güvence altına alabilir ve teknik olmayan paydaşlara karşı altyapı bütçelerini savunabilirsiniz.

Teknik geçmişi olmayan yöneticiniz, geçen ayın bulut barındırma faturası çıktısıyla çalışma alanınıza gelir. Maliyetler artmıştır, üstelik eşzamanlı bir ürün lansmanı sırasında yüksek öncelikli birkaç açılış sayfasında gecikme dalgalanmaları yaşanmıştır. Pazarlama varlıklarının neden aynı sunucuları paylaştığını, müşteri verilerinin açığa çıkıp çıkmadığını ve ekibin neden her bir kampanya için pahalı, tahsis edilmiş bir sanal makine başlatamadığını açıklamanız istenir.

Her dijital varlığa kendi sanal makinesini (VM) vermek gürültülü komşu (noisy neighbor) sorununu ortadan kaldırır ancak operasyonel bütçenizi hızla tüketir. Standart Docker dağıtımları, birden fazla siteyi tek bir işletim sistemi çekirdeğinde çalıştırarak maliyet sorununu çözer; fakat varsayılan yapılandırmalar tehlikeli izolasyon açıkları bırakır. Bir kiracı uygulaması kontrolden çıkan bir betikle veya kötü amaçlı bir ihlalle karşılaşırsa, o sunucuda barındırılan diğer tüm uygulamalar risk altına girer.

Docker'da titiz bir çok kiracılı izolasyon yapılandırmak için bu adım adım teknik rehberi kullanın. Sistem kararlılığını korumak, kiracı verilerini izole etmek ve teknik altyapı tercihlerini liderliğiniz için net bir iş değerine dönüştürmek üzere bu beş operasyonel adımı uygulayın.

---

1. Control Groups Kullanarak Kesin Kaynak Kotaları Belirleyin

Her konteyner üzerinde derhal açık CPU, bellek ve disk G/Ç sınırları belirleyin. Birden fazla kiracı aynı ana makineyi paylaştığında, sınırlandırılmamış konteynerler sistem kaynakları için rekabet eder. Kontrolden çıkan tek bir veritabanı sorgusu veya yüksek trafikli bir kampanya, ana makinenin tüm bellek havuzunu tüketerek Linux Bellek Yetersizliği (OOM) sonlandırıcısının rastgele sistem süreçlerini durdurmasını tetikleyebilir.

Linux kontrol grupları (cgroups), herhangi bir konteynerin ne kadar işlem kapasitesi tüketebileceğini yönetir. Bu sınırları doğrudan dağıtım tanımlarınıza uygulayın:

services:
  tenant_app:
    image: nginx:alpine
    deploy:
      resources:
        limits:
          cpus: '0.75'
          memory: 512M
        reservations:
          cpus: '0.25'
          memory: 256M

• Bellek Sınırları (limits.memory): Kesin bir üst sınır belirler. Konteyner 512 megabaytı aşarsa, çekirdek komşu kiracıları etkilemeden yalnızca o konteyner içindeki süreçleri sonlandırır.
• Bellek Ayırmaları (reservations.memory): Düşük trafikli uygulamaların yanıt vermeye devam etmesi için temel bellek tahsisini garanti eder.
• CPU Sınırları (limits.cpus): Konteyneri mevcut CPU çekirdeklerinin maksimum bir oranıyla sınırlandırarak tek bir kiracının tüm CPU'yu tüketmesini (CPU starvation) önler.

Bu mimariyi teknik olmayan yöneticilere açıklarken, cgroups'u otomatik dijital ara sayaçlar olarak düşünebilirsiniz. Bir ofis binasındaki kiracıların ana şalteri aşırı yüklemek yerine yalnızca kendi elektrik kullanımları için ödeme yapması gibi, cgroups da yüksek trafikli bir açılış sayfasının başka bir müşterinin potansiyel müşteri kazanma portalını asla çökertmemesini sağlar. Mimari ödünleşimlere daha yakından bakmak için çok kiracılı bir mimari tasarlama kılavuzumuzu inceleyin.

---

2. Namespaces ve Non-Root Kullanıcılar ile Kiracı Süreçlerini Segmentlere Ayırın

Konteyner süreçlerini asla varsayılan root kullanıcısı olarak çalıştırmayın. Standart Linux konteyner ortamlarında, açıkça yeniden eşlenmediği (remap) sürece bir konteynerin içindeki root kullanıcısı, temel ana makine çekirdeğindeki root kullanıcısına karşılık gelir. Bir saldırgan root olarak çalışan bir web uygulamasını ihlal ederse, paylaşılan ana makine üzerinde yükseltilmiş ayrıcalıklar elde eder.

Kullanıcı ad alanları (user namespaces) ve açık non-root çalıştırma ile süreç izolasyonunu zorunlu kılın:

1. Ayrıcalıksız çalışma zamanı kullanıcıları tanımlayın: Dockerfile dosyalarınızda özel, düşük ayrıcalıklı hizmet kullanıcıları oluşturun.

   FROM php:8.2-fpm-alpine
   RUN addgroup -g 10001 tenantgroup && \
       adduser -u 10001 -D -G tenantgroup tenantuser
   USER tenantuser
   

2. Kullanıcı Ad Alanlarını (userns-remap) Etkinleştirin: Docker arka plan programını (/etc/docker/daemon.json), konteyner kullanıcı kimliklerini ana makinede ayrıcalıksız bir aralığa yeniden eşleyecek şekilde yapılandırın.

   {
     "userns-remap": "default"
   }
   

Linux ad alanları sistem görünürlüğünü bölümlere ayırır. Süreç Kimliği (PID) ad alanı, A Kiracısının B Kiracısına ait süreçleri görüntüleyememesini, bunlara sinyal gönderememesini veya sonlandıramamasını sağlar. Bağlama (MNT) ad alanı her kiracıya dosya sisteminin yalıtılmış bir görünümünü verirken, IPC ad alanları yetkisiz süreçler arası iletişimi engeller.

Kullanıcı ad alanlarını yeniden eşlemek konteynerden kaçış (escape) vektörlerini etkisiz hale getirir: Konteyner içinde kendisini root (UID 0) sanan bir süreç, ana makinede ayrıcalıksız bir kimlikle (örneğin UID 165536) eşlenir. Bir istismar konteyner engellerini aşsa bile, saldırgan ana makine yapılandırmalarını değiştiremeyeceği veya komşu kiracı dizinlerine erişemeyeceği yetkisiz bir kabukta kalır.

---

3. Çekirdek Ayrıcalıklarını Kaldırın ve Salt Okunur Dosya Sistemlerini Zorunlu Kılın

Mevcut Linux yeteneklerini (capabilities) en aza indirin ve konteyner kök dosya sistemini önyükleme sırasında sabit (immutable) hale getirin. Varsayılan konteyner çalışma zamanları yaklaşık bir düzine Linux çekirdek yetkisi verir; bunların birçoğuna web uygulamaları asla ihtiyaç duymaz. Fazlalık yetkiler saldırganlara ağ yönlendirmesini manipüle etme, ana makine saatini değiştirme veya dosya erişim kontrollerini atlatma araçları sunar.

Tüm varsayılan yetkileri kaldırıp yalnızca temel operasyonel bayrakları geri ekleyerek çalışma zamanı konteynerlerini kilitleyin:

services:
  tenant_web:
    image: custom-nginx:latest
    read_only: true
    cap_drop:
      - ALL
    cap_add:
      - NET_BIND_SERVICE
    security_opt:
      - no-new-privileges:true
      - seccomp=default.json
    tmpfs:
      - /tmp:rw,noexec,nosuid,size=64m
      - /var/run:rw,noexec,nosuid,size=16m

• cap_drop: - ALL: Konteyner sürecinden tüm çekirdek yetkilerini kaldırır.
• cap_add: - NET_BIND_SERVICE: Ham ağ soketi manipülasyonunu engellerken ayrıcalıklı bağlantı noktalarına (80 ve 443 gibi) bağlanmaya açıkça izin verir.
• read_only: true: Konteyner kök dosya sisteminin tamamını salt okunur olarak bağlar. Saldırganlar kötü amaçlı ikili dosyalar indiremez, PHP betiklerini değiştiremez veya web sunucusu yapılandırma dosyalarını tahrif edemez.
• tmpfs: Gerekli geçici dosyalar (/tmp gibi) için ikili dosya yürütmeyi (noexec) ve ayrıcalık yükseltmeyi (nosuid) engelleyerek bellekte uçucu dizinler ayırır.

Paylaşılan ana makine çekirdeğine yapılan sistem çağrılarını yakalamak ve kısıtlamak için güvenli bilgi işlem modu (seccomp) filtrelerini ve AppArmor veya SELinux gibi güvenlik modüllerini uygulayın. Ekibiniz özel web uygulaması derlemeleri yönetiyorsa, dağıtım süreçlerinizde Docker konteynerlerini sıkılaştırma adımlarımızı izleyin.

---

4. Kiracı Ortamları Arasındaki Ağları Bölümlere Ayırın

Varsayılan bridge ağını devre dışı bırakın ve her kiracı yığını için özel, izole yazılım tanımlı bridge ağları kurun. Varsayılan olarak, standart Docker bridge ağına yerleştirilen konteynerler dahili IP adresleri üzerinden birbirlerini keşfedebilir ve haberleşebilir. Bir kiracının pazarlama mikro hizmetindeki bir güvenlik açığı, o ana makinedeki diğer tüm dahili veritabanlarına ve uygulamalara yanal geçişe (lateral movement) olanak tanır.

Kiracı başına bağımsız ağ köprüleri bildirerek kiracı trafiğini tamamen izole edin:

networks:
  tenant_alpha_net:
    driver: bridge
    internal: true
  tenant_beta_net:
    driver: bridge
    internal: true
  public_gateway_net:
    driver: bridge

services:
  alpha_app:
    image: tenant_a_app:latest
    networks:
      - tenant_alpha_net
      - public_gateway_net

  alpha_db:
    image: mariadb:10.11
    networks:
      - tenant_alpha_net

  beta_app:
    image: tenant_b_app:latest
    networks:
      - tenant_beta_net
      - public_gateway_net

  beta_db:
    image: mariadb:10.11
    networks:
      - tenant_beta_net

• Kiracı İzolasyonu: alpha_app ve alpha_db yalnızca tenant_alpha_net üzerinden haberleşir. Bir saldırgan dahili alt ağı tarasa bile beta_app, alpha_db veritabanına erişemez.
• Dahili Bayrak (internal: true): Veritabanı ağlarının trafiği doğrudan dış internete yönlendirmesini önler; gelen ve giden erişimi yalnızca uygulama konteynerleriyle sınırlar.
• Ters Proxy Ağ Geçidi (Reverse Proxy Gateway): Yalnızca giriş proxy'si, gelen HTTP/HTTPS isteklerini ana makine adına göre belirlenen kiracı konteynerine yönlendirmek için public_gateway_net ağına bağlanır.

Gelişmiş ortamlar için, karmaşık manuel ağ komut dosyalarına gerek kalmadan daha katı kullanıcı ad alanı sınırlarını ve sanallaştırılmış /proc ve /sys dosya sistemlerini otomatik olarak uygulayan Sysbox gibi çalışma zamanlarını veya Docker'ın Gelişmiş Konteyner İzolasyonu (ECI) modlarını değerlendirin.

---

5. Objektif Bir Çok Kiracılı Karar Matrisi Oluşturun

Tüm dijital varlıkların tahsis edilmiş sanal makineler gerektirdiği varsayımına karşı çıkın. Pazarlama liderleri genellikle donanım düzeyinde VM izolasyonunun tek savunulabilir güvenlik modeli olduğunu varsayar. Pratikte, hafif açılış sayfaları veya kısa ömürlü kampanya siteleri için özel VM'ler sağlamak, web uygulaması güvenliğini artırmadan bütçenin şişmesine ve operasyonel bakım yüküne neden olur.

İş yükü gereksinimlerini değerlendirmek ve karar vericilere rasyonel bir dağıtım stratejisi sunmak için aşağıdaki karşılaştırma matrisini kullanın:

İzolasyon Katmanı	Temel Teknoloji	Güvenlik Sınırı	Kaynak Ek Yükü	En Uygun Kullanım Senaryosu
Paylaşımlı Yığın Konteynerleri	Tek işletim sisteminde Namespaces ve Cgroups	Mantıksal işletim sistemi düzeyinde izolasyon	Çok Düşük	Yüksek trafikli açılış sayfaları, dahili hazırlık (staging) ortamları, geçici kampanya siteleri
Sıkılaştırılmış Konteynerler (ECI / Sysbox)	Kullanıcı ad alanları, AppArmor, Salt Okunur kök dizin	Gelişmiş işletim sistemi düzeyi ve sanallaştırma	Düşük	Çok müşterili ajans barındırma hizmetleri, kimlik doğrulamalı portallar, hassas pazarlama formları
Özel Sanal Makineler (VM'ler)	Hipervizör donanım sanallaştırması	Katı donanım/çekirdek ayrımı	Yüksek	Ödeme işlemleri, HIPAA/PCI ile düzenlenen veriler, güvenilmeyen özel kod çalıştırma
Hibrit (Özel VM'ler İçindeki Konteynerler)	Kiracıya özel VM'lerin içindeki sıkılaştırılmış konteynerler	Çok katmanlı donanım ve işletim sistemi sınırları	Orta - Yüksek	Özel sözleşme uyumluluğu talep eden üst düzey kurumsal müşteriler

Altyapı bütçesi ayırmadan önce her projeyi katı kriterlere göre değerlendirin:

1. Veri Hassasiyeti: Proje mevzuata tabi verileri (örn. kredi kartı kayıtları veya tıbbi sağlık bilgileri) depoluyor mu? Yanıt evet ise, tahsis edilmiş bir VM'e dağıtın.
2. Kod Kaynağı: Standartlaştırılmış, ekip tarafından denetlenmiş kod mu dağıtıyorsunuz yoksa doğrulanmamış üçüncü taraf eklentilere izin mi veriyorsunuz? Standart kod sıkılaştırılmış konteynerlerde yer almalıdır; test edilmemiş üçüncü taraf kodlar ise hipervizör izolasyonu gerektirir.
3. Bütçe ve Yaşam Döngüsü: Sezonluk açılış sayfaları ve temel şirket web siteleri için sıkılaştırılmış konteyner çok kiracılığı, harcanan bütçe başına maksimum performans sağlar.

Yönetime altyapı planları sunarken, önerilerinizi net katman tabanlı argümanlarla desteklemek için müşterilerin ne zaman özel VM'lere ihtiyaç duyduğunu değerlendirme kılavuzumuza başvurun.

---

Sonuç: Güvenlik Kontrollerini İş Yatırım Getirisine (ROI) Dönüştürmek

Çok kiracılı bir Docker ortamını güvenli hale getirmek, kurumsal bir bulut mimarisi bütçesi gerektirmez. Yalnızca işletim sistemi kontrollerinin titiz ve disiplinli bir şekilde uygulanmasını gerektirir.

Altyapıyı teknik olmayan yönetimle gözden geçirirken, bu teknik yapılandırmaları üç temel yönetici metriği etrafında çerçeveleyin:

• Maliyet Verimliliği: Çok kiracılı konteynerler, ekibin onlarca pazarlama sitesini ayrı VM'lerin gerektirdiği işlem ayak izinin çok küçük bir kısmıyla barındırmasını sağlar.
• Çalışma Süresi (Uptime) Koruması: Kontrol grupları, sezonluk bir kampanyadaki trafik artışlarının ana marka web sitelerinin performansını düşürmemesini garanti eder.
• Etki Alanını (Blast Radius) Sınırlandırma: Salt okunur dosya sistemleri, kaldırılan yetkiler ve yalıtılmış ağ köprüleri, tek bir sitedeki istismarın komşu müşteri veritabanlarına veya ana makine kontrollerine erişememesini sağlar.

Bu güvenlik önlemlerini konteyner şablonlarınızda sistematik olarak uygulayın. Böylece hem mühendislik güvenlik standartlarını hem de yönetimin bütçe kısıtlamalarını karşılayan yüksek performanslı, uygun maliyetli bir altyapı sunabilirsiniz.