Konteyner Güvenliği: İzolasyon Mutlak mı? (Docker vs. Köksüz Podman)

5

0

Okuyun 12 min.

Konteyner izolasyonunun temel sınırlamaları

Konteynerleştirme, bulut ve mikro hizmet mimarilerinde uygulamaları paketlemek ve sunmak için baskın yöntem haline gelmiştir. Konteynerler kod, kütüphane ve bağımlılıkları paketlemenize olanak tanıyarak yüksek taşınabilirlik ve operasyonel verimlilik sağlar.

Bununla birlikte, kritik iş yüklerinin konteynerlere yoğun bir şekilde taşınması, izolasyon mekanizmalarının dayanıklılığını temel bir endişe haline getirmektedir. DevOps ve güvenlik ekipleri arasında yapılan araştırma ve anketler sürekli olarak konteyner güvenliğinin en önemli endişelerden biri olmaya devam ettiğini gösteriyor: çekirdek ve çalışma zamanı güvenlik açıkları, yapılandırma hatalarının yanı sıra düzenli olarak gerçek dünyada izolasyon ihlallerine yol açıyor.

Anahtar soru şudur: Konteyner izolasyonu mutlak mıdır?

Cevap hayır ve bunun nedeni de mimarilerinde yatıyor. Bu makalede, bu soruyu daha derinlemesine inceleyecek ve güvenlik açığı risklerini azaltmak için mevcut önlemleri keşfedeceğiz.

Konteynerler ve Sanal Makineler: Paylaşılan Çekirdek

Sanal Makine (VM):

• Her VM, ana bilgisayardan tamamen ayrı olarak kendi işletim sistemi çekirdeğini çalıştırır.

• İzolasyon bir hipervizör (KVM, Xen, ESXi, vb.) tarafından sağlanır.

• Bir saldırı tipik olarak hipervizörü hedef almalıdır, bu da saldırı vektörlerini önemli ölçüde daraltır.

Konteynerler:

• Konteyner, Linux çekirdeği ilkelleri (isim alanları, cgroups, vb.) kullanılarak izole edilmiş bir süreçtir.

• Bir konteyner yalnızca kullanıcı alanını (kütüphaneler, çalışma zamanı, uygulama) tutar ancak bir çekirdeği ana bilgisayar ve diğer konteynerlerle paylaşır.

• Herhangi bir kritik çekirdek açığı otomatik olarak düğüm üzerindeki tüm konteynerler için potansiyel bir saldırı vektörü haline gelir.

Paylaşılan bir çekirdeğin mimari seçimi, konteyner izolasyonunu temelde mutlak olmayan bir hale getirir: bir çekirdek açığının başarılı bir şekilde kullanılması, bir saldırganın herhangi bir ad alanının sınırlarını aşmasına izin verir.

İsim alanlarının ve Cgruplarının izolasyon yaratmadaki rolü

Linux'ta konteyner izolasyonunun temeli Namespaces ve Cgroups'a dayanır.

• İsim Alanları - Sistem Görünümünün İzolasyonu: PID, Mount, Network, User, IPC, UTS ve diğerleri. Süreçler yalnızca kendi alanlarını "görürler": dosya sistemleri, PID'leri, ana bilgisayar adları ve ağları.

• Cgroups - Kaynak Kontrolü ve Sınırlama: CPU, bellek, I/O, işlem sayısı vb.

İsim alanları ayrı bir sistem yanılsaması yaratır ve Сgroup'lar bir konteynerin ana bilgisayarın kaynaklarını kullanmasını engeller. Bununla birlikte, Ad alanlarının bir izolasyon mekanizması olduğunu, kasıtlı bariyer atlatmaya karşı tam teşekküllü bir güvenlik mekanizması olmadığını belirtmek çok önemlidir. Çekirdek güvenlik açığından yararlanılmasını engellemez, aşırı kök ayrıcalıkları veya ayrıcalıklı kapsayıcılarla ilgili sorunları çözmez, sistem çağrılarını filtrelemez ve erişim politikalarını yönetmez.

Bu nedenle, isim alanları ve gruplar yalnızca güçlendirilmesi gereken bir temel katmandır:

1. Sistem çağrısı filtreleme (Seccomp)

2. MAC ilkeleri (AppArmor/SELinux)

3. Kapasite kısıtlamaları

4. İdeal olarak, Kullanıcı Ad Alanları + köksüz mod

Konteyner Platformu Güvenliği: kritik tehditler ve saldırı vektörleri

Bir konteyner platformunun saldırı yüzeyi çok katmanlıdır. Aşağıdaki ana yüzeyler tanımlanabilir:

• Runtime ve kernel (runc, containerd, CRI-O, Linux kernel).

• Görüntü tedarik zinciri.

• Konteyner ve orkestratör yapılandırması.

• Bulut ve altyapı (IAM, API, depolama, ağ).

Saldırı vektörlerine ve kritik güvenlik açıklarına genel bakış: Konteynerden Kaçış

Bir konteyner ortamındaki tipik vektörler şunları içerir: Linux çekirdeğinde veya konteyner çalışma zamanında bir CVE'den yararlanma; güvenli olmayan imajların kullanılması (eski paketler, istismar kitleri); Kubernetes / Docker'daki yapılandırma hataları (aşırı ayrıcalıklar, ana bilgisayar dosya sistemi montajı, ana bilgisayar ağ yığını); ve kayıt defteri ve CI / CD tehlikesi.

Bir Konteyner Kaçışının genellikle faktörlerin bir kombinasyonu olduğunu anlamak önemlidir:

Kernel/Runtime Güvenlik Açığı + Kötü Yapılandırma (root olarak çalıştırma, --privileged, host dosya sistemi bağlama, eksik MAC/Seccomp).

Tedarik zinciri güvenlik açıkları

Konteyner imajı tedarik zinciri ana risklerden biridir çünkü genel kayıtlardan alınan temel imajlar genellikle bilinen CVE'leri içerir. Bağımlılıklar (pip/npm/gem/go modülleri) geçişli olarak çekilir ve her zaman kontrol edilmez. En tehlikelisi, kötü amaçlı yazılımlar "uykuda" olabilir ve yalnızca çalışma zamanında ortaya çıkabilir.

Bu nedenle, aşağıdaki en iyi uygulamalar üretimde zorunludur:

• Trivy, Clair, Grype gibi araçları kullanarak CVE'ler için görüntü taraması.

• Harbor, Quay veya GHCR gibi politika farkındalığı olan kayıt defterlerinin kullanılması.

• Dağıtımdan önce görüntü imzalama ve doğrulama.

Yapılandırma hataları ve ayrıcalıklı kapsayıcılar

Güvenlik açıklarına geniş ölçüde kapı açan en yaygın hata, konteyner içindeki işlemleri root olarak çalıştırmaktır! Konteynerdeki uygulama süper kullanıcı haklarıyla başlatılırsa, konteynerin ele geçirilmesi üzerine saldırgan konteyner içinde root olur. Konteynerin dışına başarılı bir kaçış, daha sonra ana bilgisayar köküne yükselmeyi önemli ölçüde kolaylaştırır.

Uygulamaların root olarak başlatılmasını ve ayrıcalıksız UID/GID kullanılmasını yasaklamak, uygun sertleştirmenin temel kuralıdır.

Privileged bayrağını kullanan ayrıcalıklı konteynerler, özellikle bazı Cgroups, AppArmor/SELinux ve Seccomp kısıtlamaları gibi temel izolasyon mekanizmalarını pratikte devre dışı bırakır. Bu, konteynere ana bilgisayar cihazlarına ve sözde dosya sistemlerine (/proc, /sys, /dev, vb.) doğrudan erişim sağlar. Ayrıcalıklı bir kapsayıcıdan ana bilgisayar disklerini bağlamak ve dosya sistemi ile yapılandırmaları değiştirmek kolaydır.

Özünde, ayrıcalıklı bir kapsayıcı, kasıtlı bir ayrıcalık yükseltmesine eşdeğerdir. Unutmayın, bu yalnızca nadir, iyi izole edilmiş senaryolarda kabul edilebilir ve kesinlikle çok kiracılı bir ortamda kabul edilemez.

Ayrıca --privileged bayrağı kullanılmasa bile konteyner ortamını son derece savunmasız hale getirebilecek "sessiz" yapılandırma hataları da vardır. En tehlikeli olanları şunlardır:

• hostPath'i /etc veya /var/run/docker.sock gibi hassas ana bilgisayar dizinlerine bağlamak.

• CAP_SYS_ADMIN gibi, ana bilgisayarda neredeyse kök hakları veren gereksiz Yetenekler vermek.

• hostNetwork veya hostPID modlarının gerekçesiz kullanımı.

Görünüşte önemsiz olan bu ayarlar, bir saldırganın konteynerden kaçmasına ve çekirdek ya da tüm ana bilgisayar sistemi üzerinde kontrol sahibi olmasına olanak tanıyabilir.

Mimari karşılaştırması: Docker vs Podman

Docker ve Podman arasındaki mimari farklılıklar tehdit modelini doğrudan etkilemektedir. Docker, yüksek ayrıcalıklı daemon'u ile ana riski sunar: tek bir hata noktası.

Docker ve rootful modu

Klasik veya standart Docker mimarisinde Docker CLI, dockerd daemon ile /var/run/docker.sock soketi veya TCP aracılığıyla iletişim kurar. dockerd daemon root kullanıcısı olarak çalışır ve temel işlemleri gerçekleştirir:

• Konteyner oluşturma/silme

• Bina görüntüleri

• Ağları/birimleri yönetme

• Kayıtlarla etkileşim

Docker API'sine doğrudan erişim, ana bilgisayara neredeyse tam kök erişimine eşdeğerdir - bir saldırganın dosya sistemini bağlamasına, ayrıcalıklı kapsayıcıları başlatmasına vb. izin verir. Bu senaryoda, daemon tek bir hata noktası haline gelir - eğer ele geçirilirse, saldırgan ana bilgisayar erişimine sahip olur.

Bu nedenle Docker, sokete sıkı erişim kontrolü, MAC ve Seccomp'un zorunlu olarak etkinleştirilmesini ve Yeteneklerin kısıtlanmasını gerektirir. En önemlisi, Docker API'sine erişimi olan kullanıcı ve hizmet sayısını en aza indirmek esastır.

Daemonless Podman: yerel linux yaklaşımı

Podman, Red Hat ve topluluk tarafından daha güvenli, "yerel" bir Linux alternatifi olarak geliştirilmiştir. Başlangıçta daemonless bir mimari ile tasarlanmıştır, yani kalıcı, merkezi bir daemon yoktur. Bunun yerine, konteynerler komutu çalıştıran kullanıcının alt süreçleridir. Temel, birimlerin ve hizmetlerin doğrudan oluşturulduğu systemd ile derin entegrasyondur.

Bu, kök daemon tarafından sunulan tek hata noktasını ortadan kaldırır ve geleneksel Unix modeliyle daha iyi uyum sağlar: "Süreci kim başlattıysa onun sahibidir".

Köksüz mod: Ana güvenlik bariyeri olarak Kullanıcı Ad Alanları

Köksüz mod aslında temel tehlikeye verilen mantıklı bir cevaptır: "Ya konteyner patlarsa?"

Kullanıcı ad alanlarının rolü ve hasar azaltma

Kullanıcı Ad Alanları UID/GID'yi izole eder ve UID'nin yeniden eşlenmesine izin verir. Örneğin, bir konteyner içindeki bir işlem UID 0'a (root) sahipse, aynı işlem ana bilgisayardaki subuid/subgid aralığından ayrıcalıksız bir UID ile eşleştirilir.

Bu nedenle, konteyner içindeki bir saldırgan kök ayrıcalıklarına sahip olsa ve ana bilgisayar seviyesine kaçmak için bir çalışma zamanı/çekirdek açığından yararlanmayı başarsa bile, ana bilgisayarda ayrıcalıksız bir kullanıcı olarak çalışmaya devam eder.

Bu nedenle, runc-escape de dahil olmak üzere birçok istismar zinciri kırılır veya önemli ölçüde azaltılmış bir etkiye sahip olur. Bunun nedeni, saldırganın köke ait ikili dosyaların/yapılandırmaların üzerine yazamaması, dosya sistemlerini bağlayamaması veya Yetkinlikler olmadan aygıtları yönetememesidir ve MAC politikaları da ana bilgisayarda çalışmaya devam eder.

Köksüz Podman: Sınırlamalar ve Ağ Yığını

Podman en başından beri köksüz işlemlere odaklanarak tasarlanmıştır. Konteynerler ayrıcalıksız bir kullanıcı tarafından oluşturulur ve yönetilir, kullanıcı ad alanları varsayılan olarak etkinleştirilir ve SELinux/AppArmor ve Cgroups, root erişimi olmadan mümkün olduğu ölçüde kullanılır.

Ancak, bu şemada bazı ödünleşimler vardır. Köksüz bir konteyner subuid/subgid aralığında çalıştığında, imaj bu aralığın dışında kalan UID/GID değerlerine sahip dosyalar içeriyorsa eşleme hataları oluşabilir.

Bir başka dolaylı dezavantaj ise, ayrıcalıksız bir kullanıcının ağ ad alanlarını serbestçe yapılandıramamasıdır. Podman, 2025'in başlarından beri slirp4netns'in yerine kullanıcı alanı yığın makarnasını kullanmaktadır. Bu eklenti tamamen kullanıcı alanında çalışır, ancak dokunma arayüzü ve sıfır kopya ekleme sayesinde neredeyse yerel ağ performansı sunar. Bununla birlikte, performans yavaşlamaları hala mümkündür ve kullanıcılar slirp4netns kullanmaya devam ederse kesinlikle garanti edilir.

Köksüz Docker: uygulama ve gereksinimler

Docker ayrıca, dockerd daemon ve konteynerlerin ana bilgisayarın kök kullanıcısının ayrıcalıkları olmadan bir kullanıcı ad alanı içinde başlatıldığı tam teşekküllü bir köksüz modu da destekler. Önemli olarak bu, daemonun kendisinin ayrıcalıklı kaldığı eski userns-remap özelliğinden farklıdır.

Güvenlik açısından bakıldığında bu, bir konteyner ihlalinin otomatik olarak ana bilgisayar kök kullanıcı seviyesine yükselmeyeceğini garanti eder. Köksüz modda dockerd'a başarılı bir saldırı olması durumunda, tüm sisteme değil, yalnızca ayrıcalıksız kullanıcının kaynaklarına erişilecektir.

Köklü ve köksüz modlar arasındaki seçim, öncelikle performansı en üst düzeye çıkarmak ve bir ihlal durumunda potansiyel hasarı en üst düzeyde sınırlamak arasındaki bir dengedir.

Sonuçlar ve güçlendirme önerileri

Analiz, konteyner izolasyonunun mimarileri nedeniyle mutlak olmadığını doğrulamaktadır. Konteynerler ana sistemin çekirdeğini paylaştığından, çekirdek veya çalışma zamanı seviyesindeki güvenlik açıkları, tanım gereği, isim alanları arasında "görülebilir" ve beklenen güvenlik sınırlarını ihlal edebilir.

Uygulamada, başarılı saldırıların çoğu bilinen bir güvenlik açığı (kernel/runc) ve zayıf bir yapılandırmanın (root, --privileged, hostPath) birleşimiyle bağlantılıdır.

Güvenilir bir konteyner güvenlik modeli çok katmanlı bir sistem olarak inşa edilmelidir:

• Katman 1 - Segmentasyon: (isim alanları, cgrupları)

• Katman 2 - Politikalar ve Filtreleme: (Seccomp, MAC, Yetenekler)

• Katman 3 - Mimari Ayrıcalık Kısıtlaması: (köksüz mod ve Kullanıcı Ad Alanları aracılığıyla)

Kontrol listesi: Docker ve Podman kapsayıcıları için ana bilgisayar sağlamlaştırma

• Varsayılan Olarak Köksüz

Dahili ve çok kiracılı iş yükleri için varsayılan model olarak Podman veya Docker'ı köksüz modda düşünün.

• Çekirdek Güçlendirme ve Yama

Çekirdeği derhal güncelleyin (Dirty COW, Dirty Pipe ve benzeri CVE'ler neredeyse her zaman yamalarla zaten ele alınmıştır). İyi bir güvenlik yaması geçmişi olan dağıtımları kullanın (RHEL, OpenSUSE, Ubuntu LTS, vb.).

• Uzmanlaşmış Değişmez İşletim Sistemi Dağıtımlarını Benimsemek

Konteyner ortamı güvenliğini artırmak için openSUSE MicroOS veya Flatcar Linux gibi değişmez işletim sistemi dağıtımlarını kullanın. Kök dosya sistemleri varsayılan olarak salt okunurdur ve saldırı yüzeyini önemli ölçüde azaltır. Temel mekanizma atomik güncellemelerdir: yeni bir işletim sistemi görüntüsü oluşturulur ve güncelleme ya tamamen uygulanır ya da tamamen geri alınır, böylece sistemin bozulması önlenir ve kurtarma hızlandırılır.

• En Az Ayrıcalık İlkesi

Son derece uzmanlaşmış, izole ortamlar dışında üretimde --privileged bayrağını asla kullanmayın. Kapsayıcıların içindeki uygulamaları kök kullanıcı olarak çalıştırmaktan kaçının ve salt okunur bir dosya sistemi, minimum Yetenekler kümesi ve katı Seccomp profilleri kullanın.

• MAC Politikaları ve Seccomp

Konteynerler için SELinux\AppArmor'u etkinleştirin ve yapılandırın. Seccomp profillerini, ideal olarak Docker varsayılanlarını değil, uygulamanın gerçek sistem çağrılarını temel alan özel profilleri kullanın.

• Tedarik Zinciri Güvenliği

Konteyner imaj taraması uygulayın. Temel imajların kaynaklarını resmi veya dahili kayıtlarla sınırlandırın ve dağıtımdan önce imaj imzalama ve doğrulamayı etkinleştirin.

• Çalışma Zamanı İzleme

Konteyner kaçış girişimlerini tespit edebilen ve kötü amaçlı komutların yürütülmesini izleyebilen anomali tespit araçları ve konteyner IDS/EDR (Falco, Sysdig Secure veya Aqua Security) kullanın. Atipik ağ trafiğini, beklenmedik sistem çağrılarını ve hassas dosyalara erişimi izleyin.

İzolasyonun geleceği: Kata Containers, gVisor ve Micro-VM'ler

Köksüz mod, ana bilgisayarın tamamen ele geçirilmesi riskini önemli ölçüde azaltır, ancak ana bilgisayar çekirdeğine olan bağımlılıklar devam ettiğinden ve bazı saldırı sınıfları ortadan kaldırılmadığından her şeyi çözmez.

Bu nedenle, kritik iş yükleri için hibrit yaklaşımlar popülerlik kazanmaktadır:

• Kata Konteynerleri: Her bir pod veya konteyner, VM'lerin ve konteynerlerin avantajlarını birleştiren ayrı bir çekirdeğe sahip hafif bir mikro-VM içinde başlatılır.

• gVisor: Uygulama ile gerçek Linux çekirdeği arasında bir ara katman görevi gören, Go dilinde yazılmış bir sandbox çekirdeği.

Bu çözümler, paylaşılan çekirdeğe olan bağımlılığı azaltır ve bizi VM izolasyon modeline yaklaştırırken konteyner orkestratörlerinin bildirimsel doğasını ve rahatlığını korur.

Bu yazıdaki rehberliği bir sonraki dağıtımınızda gerçek dünya güvenliğine dönüştürün.

Bir VPS veya Adanmış Sunucu edinin ve bugün güvenli bir konteyner platformu kurmaya başlayın.

Yapılandırma seçimine devam edin.

Yeni Gönderiler:

Docker ve Podman: Daemonless Konteynerizasyon için Eksiksiz Bir Kılavuz