Kubernetes v1.36 User Namespaces GA: Root Artık Gerçek Root Değil
Açık konuşayım, yıllardır beklenen şey sonunda geldi. Kubernetes v1.36 ile User Namespaces desteği GA seviyesine çıktı. Bunu duyunca ilk tepkim, hiç süslemeden söyleyeyim, “nihayet be!” oldu; çünkü bu özelliği alpha günlerinden beri uzaktan izliyordum (buna dikkat edin). Tahmin eder misiniz? Her sürümde içimden aynı cümle geçiyordu: “Belki bir sonraki sürümde gelir.” Ama artık iş değişti, production’da kullanılacak seviyeye geldi.
Kısa bir not düşeyim buraya.
İlginç olan şu ki, Logosoft’ta danışmanlık verdiğim kurumsal müşterilerin çoğunda pod security standartlarına bakıyorum (en azından benim deneyimim böyle). Gördüğüm tablo pek değişmiyor:container’ların büyük kısmı hâlâ root olarak koşuyor (şaşırtıcı ama gerçek). Neden? Çünkü “uygulama öyle istiyor” ya da “dockerfile’a dokunmaya vakit yok” denip geçiliyor.User Namespaces bu bahaneyi baya zayıflatıyor — uygulama içeride root gibi devam edebilir. Host tarafında artık root olmuyor.
Durun,bir saniye.
Şahsen,bilhassa KVKK ve BDDK denetimleri açısından bakınca container breakout senaryolarına karşı koruma sağlamak artık lüks değil. Bir bankacılık projesinde güvenlik denetçisi bana “container’dan host’a erişim mümkün mü?” diye sorduğunda User Namespaces’i göstermek insana ayrı bir rahatlık veriyor; çünkü cevap daha net hâle geliyor.
Enterprise vs Startup: Kim Nasıl Yaklaşmalı?
Bir şey dikkatimi çekti:Küçük bir ekipseniz. 5-10 pod çalıştırıyorsanız bence (söylemesi ayıp) çok uzatmayın;bugün hostUsers:false ekleyip deneyin.Test edin,çalışıyorsa — ki büyük ihtimalle çalışacak — production’a alın. Burada filozofi yapmaya pek gerek yok.
Peki neden?Daha fazla bilgi için AI Agent’larda Sohbet Geçmişi:Nerede Saklamalı?
| Kriter | Startup / Küçük Ekip | Enterprise / Büyük Kurum | ||||||
|---|---|---|---|---|---|---|---|---|
| Önce kritik workload’lardan başla, aşamalı geçiş yapTest süresi1-2 gün yeterli olurEn az 2 hafta staging ortamında test etMaliyet etkisiNeredeyse yokEğer eski kernel kullanıyorsan node yükseltmesi gerekebilirSorun izlemeAUDIT loglarında UID mapping’i kontrol et | Test süresi1-2 gün yeterli olurEn az 2 hafta staging ortamında test etMaliyet etkisiNeredeyse yokEğer eski kernel kullanıyorsan node yükseltmesi gerekebilirSorun izlemeAUDIT loglarında UID mapping’i kontrol et | 1-2 gün yeterli olurEn az 2 hafta staging ortamında test etMaliyet etkisiNeredeyse yokEğer eski kernel kullanıyorsan node yükseltmesi gerekebilirSorun izlemeAUDIT loglarında UID mapping’i kontrol et | En az 2 hafta staging ortamında test etMaliyet etkisiNeredeyse yokEğer eski kernel kullanıyorsan node yükseltmesi gerekebilirSorun izlemeAUDIT loglarında UID mapping’i kontrol et | Maliyet etkisi | Neredeyse yok | Eğer eski kernel kullanıyorsan node yükseltmesi gerekebilir | Sorun izleme | AUDIT loglarında UID mapping’i kontrol et |
| Test süresi1-2 gün yeterli olurEn az 2 hafta staging ortamında test etMaliyet etkisiNeredeyse yokEğer eski kernel kullanıyorsan node yükseltmesi gerekebilirSorun izlemeAUDIT loglarında UID mapping’i kontrol et | 1-2 gün yeterli olurEn az 2 hafta staging ortamında test etMaliyet etkisiNeredeyse yokEğer eski kernel kullanıyorsan node yükseltmesi gerekebilirSorun izlemeAUDIT loglarında UID mapping’i kontrol et | En az 2 hafta staging ortamında test etMaliyet etkisiNeredeyse yokEğer eski kernel kullanıyorsan node yükseltmesi gerekebilirSorun izlemeAUDIT loglarında UID mapping’i kontrol et | Maliyet etkisi | Neredeyse yok | Eğer eski kernel kullanıyorsan node yükseltmesi gerekebilir | Sorun izleme | AUDIT loglarında UID mapping’i kontrol et | |
| Maliyet etkisi | Neredeyse yok | Eğer eski kernel kullanıyorsan node yükseltmesi gerekebilir | Sorun izleme | AUDIT loglarında UID mapping’i kontrol et | ||||
| Sorun izleme | AUDIT loglarında UID mapping’i kontrol et |
Name Space Edilmiş Capability Meselesi Ne Oluyor?
`hostUsers:false<;/code> işaretlenmiş konteйneplerde verilen capability'ler namespace içinde sınırlı kalır.
`apiVersion: "v1"
kind: "Pod"
metadata:`name: "isolated-workload"
spec:`hostUsers: false
containers:
->
name:"app"
image:"fedora42"
securityContext:
runAsUser:"0"
-
`Kernel sürümü kontrol et:<;/span>
Çok konuştum, örnekle göstereyim.
`Container runtime doğrula:<;/span>
`
Sıkça Sorulan Sorular
User Namespaces için container image’ımı değiştirmem gerekiyor mu?
Hayır, hiçbir image değişikliğine gerek yok (ciddiyim). Pod spec’ine hostUsers: false eklesen yeterli. Uygulama container içinde yine root olarak çalışıyor, yani aslında hiçbir şey değişmemiş gibi görünüyor — ama host tarafında yüksek bir UID’ye map ediliyor.
Windows container’larında da çalışıyor mu?
Hayır, çalışmıyor. Bu büyük ölçüde Linux’a özgü bir şey — yani Linux kernel’ındaki user namespace mekanizmasına dayanıyor. Windows node’larınız varsa bu pod’ları Linux node’larına yönlendirmeniz gerekiyor.
ID-mapped mounts için minimum kernel sürümü ne olmalı?
Bak şimdi, Teknik olarak Linux 5.12 ile geldi ama sonraki sürümlerde ciddi iyileştirmeler yapıldı. Tecrübeme göre pratikte 5.15 LTS veya üzerini kullanmak çok daha mantıklı. Eski kernel’larda beklenmedik davranışlarla karşılaşabiliyorsunuz — açıkçası gereksiz bir risk (inanın bana)
User Namespaces açınca performans düşer mi?
Hayır, düşmüyor. ID-mapped mounts sayesinde volume erişiminde herhangi bir kayıp yaşanmıyor — yani O(1) operasyon. Genel çalışma zamanında da bence ölçülebilir bir fark göremiyorsunuz. Hatta eski yöntemdeki recursive chown’la kıyaslandığında mesela performans kazancı bile sağlıyor.
Mevcut pod’larıma hostUsers: false eklersem ne olur?
Pod yeniden oluşturulacağı için bir restart yaşanıyor. Uygulama genelde sorunsuz çalışıyor, yani büyük bir sorun beklemiyorum — ama yine de volume erişimlerini ve dosya izinlerini staging ortamında test etmek şart. En çok da hostPath volume kullanan pod’larda dikkatli olun, aslında orada sürprizler çıkabiliyor.
Kaynaklar ve İleri Okuma
Kubernetes v1.36: User Namespaces GA Duyuru Yazısı
Kubernetes User Namespaces Resmî Dokümantasyonu
Linux User Namespaces Man Page (man7.org)







2 comments