Konteynerler Neden Varsayılan Olarak Root Olarak Çalışmamalıdır?

Konteynerleri root olarak çalıştırmak, üretim ortamlarında en yaygın — ve en tehlikeli — yanlış yapılandırmalardan biridir. Her iş yükünün saldırı yüzeyini sessizce genişletir ve çoğu ekip bir olay meydana gelene kadar bunun farkına varmaz.

"Root Olarak Çalıştırma" Aslında Ne Anlama Gelir

Varsayılan olarak, birçok konteyner görüntüsü (özellikle minimal veya eski olanlar) ana sürecini konteynerin içinde UID 0 olarak çalıştırır. Konteynerler host çekirdeğini diğer konteynerler ve host ile paylaştığı için, bir konteynerin içindeki root, tamamen izole bir sanal makinedeki root ile aynı değildir — ancak yine de olması gerekenden çok daha güçlüdür. Bir saldırgan root sahibi bir konteynerin içinde kod yürütmeyi başarırsa, şunları miras alır:

• Konteynere monte edilen herhangi bir dosyaya tam okuma/yazma erişimi, amaçlanan izinler ne olursa olsun
• Paketleri yükleme, ikili dosyaları değiştirme veya uygulama durumunu sabotaj etme yeteneği
• Bir çekirdek veya çalışma zamanı güvenlik açığı açıksa konteyner kaçışına doğru çok daha kolay bir yol
• Monte edilmiş Docker soketi veya host dosya sistemi yolu gibi yanlış yapılandırılmış hacimlerle birleştirildiğinde artan kaldıraç

Bir çekirdek açıkdan bile olmaksızın, konteynerin içindeki root erişimi herhangi bir uygulama seviyesi güvenlik açığının (SSRF, deserialization hataları, keyfi dosya yazma, vb.) etki alanını dramatik olarak artırır.

Bu Neden Düzenlenmiş Ortamlarda Daha Önemlidir

Kubernetes kümelerinde, root konteyner aşırı Linux yetenekleri veya müsamaha kâr bir güvenlik bağlamı ile birlikte bir saldırganı şunları yapmasına izin verebilir:

• /proc veya /sys değerlerini host'u etkileyen şekillerde değiştirme
• hostPID, hostNetwork veya hostIPC etkinse ayrıcalıkları yükseltme
• Küme genelinde yanal hareket için monte edilmiş bir hizmet hesabı belirtecini kötüye kullanma
• privileged: true ayarlanmışsa veya SYS_ADMIN gibi tehlikeli yetenekler verilmişse düğüme kaçış

Root kullanıcı kendisi her zaman güvenlik açığı değildir — kapsanan bir uzlaşmayı küme genelinde bir açığa dönüştüren root artı aşırı cömert çekirdek yetenekleri, host bağlantıları veya ad alanı paylaşımının kombinasyonudur.

Pratik Sertleştirme Adımları

1. Görüntüde Non-Root Kullanıcı Ayarlayın

Defaults'a güvenmek yerine Dockerfile'da açıkça non-root kullanıcı tanımlayın:

FROM node:20-slim
RUN useradd --uid 10001 --shell /usr/sbin/nologin appuser
USER appuser

2. Bunu Orkestratör Düzeyinde Uygulayın

Görüntüye güvenmeyin — politikayı çalışma zamanında uygulayın. Kubernetes'te securityContext kullanın:

securityContext:
  runAsNonRoot: true
  runAsUser: 10001
  allowPrivilegeEscalation: false
  readOnlyRootFilesystem: true
  capabilities:
    drop: ["ALL"]

runAsNonRoot: true görüntü UID 0 olarak çalışmaya çalışırsa pod'un kabul sırasında başarısız olmasına neden olur, en iyi çaba kuralı yerine sert bir garantiye sahip olursunuz.

3. Gereksiz Yetenekleri Kaldırın

Çoğu uygulama konteynerlere verilen varsayılan Linux yeteneklerinden hiçbirine ihtiyaç duymaz. Her şeyi kaldırın ve yalnızca kesinlikle gerekli olanı geri ekleyin (düşük portlara bağlanma gibi nadir durumlar NET_BIND_SERVICE gerektirebilir).

4. Ayrıcalıklı Modu ve Host Ad Alanı Paylaşımından Kaçının

privileged: true, hostNetwork: true ve hostPID: true çok spesifik altyapı iş yükleri için (belirli CNI veya izleme aracıları gibi) ayrılmalıdır — asla genel uygulama konteynerleri için değil.

5. İlke Araçları ile Tarayın ve Uygulayın

Bu kuralları ihlal eden dağıtımları otomatik olarak reddetmek için kabul denetleyicileri veya ilke altyapıları (örn. Kyverno, OPA/Gatekeeper) kullanın, manuel kod incelemesine güvenmek yerine. Bunu, root-user görüntülerini bir kümeye ulaşmadan önce yakalamak için CI'da görüntü taraması ile birleştirin.

Katmanlı, Mükemmel Olmayan Bir Savunma

Non-root olarak çalıştırmak riski tamamen ortadan kaldırmaz — çekirdek seviyesi konteyner kaçışları konteynerin içindeki kullanıcıdan bağımsız olarak mevcuttur — ancak düşük çaba ayrıcalık yükseltmesi ve yanal hareket tekniklerinin muazzam bir sınıfını ortadan kaldırır. Salt okunur dosya sistemleri, kaldırılan yetenekler ve kısıtlayıcı ağ politikaları ile birlikte, savunma derinliğinde bir konteyner güvenliği stratejisinin en ucuz ve en etkili katmanlarından birini oluşturur.

Bulut-yerel iş yüklerinin sertleştirilmesi hakkında daha derine inmek mi istiyorsunuz? Savunma derinliği stratejinizin geri kalanını oluşturmak için Korra Studio'da Cloud güvenliği ve DevOps boru hattı sertleştirmesi hakkında ilgili bölümleri keşfedin.