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.
📋 İçindekiler
-
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.
💡 Bilgi:User Namespaces etkinleştirildiğinde,container içindeki CAP_NET_ADMIN gibi capability’ler namespace’e sınırlı kalır.Yani container kendi network kaynakları üzerinde admin yetkisine sahip olur ama host ağına dokunamaz.Bu yaklaşım,önceden sadece tam privileged container ile mümkün olan bazı kullanım senaryolarını daha güvenli hâle getirir.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:falseekleyip 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?
?Bilgi: User Namespaces etkinleştirildiğinde,`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: falseeklesen 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)
Aşkın KILIÇYazar20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
AZ-305AZ-104AZ-500AZ-400DP-203AI-102İlgili Yazılar
-
İlginizi Çekebilir
Yasemin İ.
Uzun süredir beklenen bir özellikti bu, production cluster’larda root ile çalışmak zorunda kalan iş yüklerini düşününce ne kadar kritik olduğu anlaşılıyor. UID mapping mantığı Linux kernel tarafında zaten vardı ama Kubernetes’in bunu düzgün yönetmesi bambaşka bir şey. Bu arada şu yazınız da güzeldi: GitHub Pull Requests Dashboard: Herkes İçin Açılan Yeni Deneyim — https://www.askinkilic.com.tr/github-pull-requests-dashboard-herkes-icin-acilan-yeni-deney/
Tuğçe R.
Uzun süredir beklenen bir özellikti bu, özellikle multi-tenant cluster çalıştıranlar için ciddi bir rahatlama. Peki mevcut workload’ları bu moda geçirmek ne kadar acı bir süreç, deneyeni var mı?
Yorumlar kapalı.
2 comments