SELinux Volume Label Değişikliği: v1.37 Öncesi Hazırlık
Bence, Geçen ay bir finans kuruluşunun Kubernetes kümelerine bakarken, SELinux’un enforcing modda çalıştığı node’larda volume mount sürelerinin gereksiz yere uzadığını fark ettim. Yüz binlerce dosya taşıyan bir persistent volume vardı, Pod kalkarken neredeyse 4 dakika boyunca recursive relabeling yapıyordu, ve işin tuhafı bu yük çoğu zaman kimsenin ilk bakışta aklına bile gelmiyor. Tam o sırada Kubernetes tarafında dolaşan haber geldi: SELinuxMount feature gate’ının v1.37’de varsayılan olarak açılacak olması. Sevindim, ama bir yandan da “bu değişiklik kimin canını yakar?” diye düşündüm.
Yanı, Eğer Kubernetes cluster’larınızda SELinux kullanmıyorsanız, bu yazı size pek dokunmaz. Hatta rahatça geçebilirsiniz. Ama Türkiye’deki kurumsal yapılarda, özellikle bankacılıkta, telekomda ve kamu tarafında, RHEL üstünde SELinux enforcing modda çalışmak çoğu yerde zorunlu; yanı mesele teorik değil, baya sahaya değiyor. Kısacası bu güncelleme sizi doğrudan etkileyebilir, hem de sandığınızdan erken.
SELinux ve Kubernetes: Sorun Tam Olarak Ne?
SELinux, Linux tarafında dosya ve ağ soketlerine etiket bakarak karar veriyor. Kısa hali bu. Bir Pod ayağa kalkınca da container runtime, Pod’un securityContext içinden gelen SELinux etiketini alıyor ve Pod’un görebildiği volume içindeki dosyalara bunu recursive olarak basıyor; yanı 500.000 dosyalık bir NFS paylaşımı varsa, iş biraz uzuyor, hatta bazen insanın sabrı test ediliyor.
Şunu fark ettim: Şimdi işin can sıkıcı kısmı geliyor. Pod’a SELinux etiketi hiç vermeseniz bile runtime bu sefer kendi kafasına göre bir etiket üretiyor, ki bu güvenlik açısından boş değil; sonuçta container’dan kaçan bir proses başka container’ların verisine dadanmasın diye yapılıyor. Ama durun, asıl mesele şu: yine recursive relabeling var. Yanı etiket verin ya da vermeyin, o maliyet bir şekilde karşınıza çıkıyor (kendi tecrübem)
2023’te bir telekom ortamında bunu birebir gördük. Prometheus’un veri volume’ü 2 milyon dosyaya dayanmıştı. Pod restart ettiğimizde SELinux relabeling yüzünden 7-8 dakika bekliyorduk; monitöring gap oluşuyordu, alert’ler gecikiyordu, ekip de hâliyle “bu niye böyle öldü şimdi?” diye birbirine bakıyordu. Açık konuşayım, büyük volume’lerde recursive relabeling baya operasyonel dert çıkarıyor.
Durun, bir saniye.
Eğer bir container subPath kullanıyorsa, sadece o subPath relabel ediliyor — volume’ün tamamı değil. Bu da farklı SELinux etiketlerine sahip iki Pod’un aynı volume’ü farklı subPath’lerle kullanmasına izin veriyor. Güzel detay aslında. Ama çoğu zaman gözden kaçıyor.
Yeni Yaklaşım: Mount Seviyesinde Etiketleme
Tuhaf ama, Kubernetes’in burada yaptığı şey ilk bakışta baya sade dürüyor. Dosyaları tek tek gezip etiket yapıştırmak yerine, volume’ü -o context=<label> seçeneğiyle mount ediyor; kernel de o mount noktasının altındaki inode’lara etiketi kendi dağıtıyor, yanı recursive traversal yok, bekleme yok, uğraş yok. Evet, olay bu kadar net.
Tabi işin bir de ama tarafı var. Bu yöntem her volume tipiyle çalışmıyor; CSI driver’ın bunu desteklemesi gerekiyor (CSIDriver spec içinde seLinuxMount: true olmalı), üstüne Pod’un securityContext tarafında da yeterli SELinux bilgisini vermeniz lazım, mesela spec.securityContext.seLinuxOptions.level gibi. Şey, kağıt üzerinde basit görünüyor ama detayda biraz naz yapıyor.
Aşamalı Geçiş Planı
Kubernetes ekibi bunu bir anda açmamış, iyi de yapmış. Önce dar bir alanda denemişler, sonra yavaş yavaş genişletmişler; hani bazen hızlı gitmek yerine kontrollü gitmek daha az baş ağrıtır ya, tam öyle bir durum. Bir yandan güvenlik kaygısı var, öte yandan uyumluluk derdi var, ikisini aynı sepete atınca işler çorba olabiliyor.
| Feature Gate | Kapsam | Durum |
|---|---|---|
| SELinuxMountReadWriteOncePod | Sadece ReadWriteOncePod volume’ler | v1.28’de varsayılan açık, v1.36’da GA |
| SELinuxMount | Tüm volume tipleri | v1.36’da beta, v1.37’de varsayılan açık bekleniyor |
Bir şey dikkatimi çekti: İlk aşama nispeten risksizdi çünkü ReadWriteOncePod zaten tek bir Pod tarafından kullanılıyor; paylaşım yoksa yan etki ihtimali de düşüyor. Ama ikinci aşama… hmm, orada iş değişiyor biraz. Tüm volume tiplerine yayılınca sürücü desteği, securityContext ayarları ve davranış tutarlılığı aynı anda masaya geliyor; yanı “bir kere açtık tamam” diyebileceğiniz bir alan değil.
Burada, peki neden?
Çünkü mount seviyesinde etiketleme kulağa ufak bir optimizasyon gibi geliyor ama etkisi büyük oluyor. Dosya sistemi içinde dolaşıp her şeyi yeniden — itiraz edebilirsiniz tabi — boyamak yerine etiketi mount anında veriyorsunuz; bu da hem daha temiz dürüyor hem de özellikle büyük hacimli yapılarda gereksiz yükü azaltıyor. Yine de her ortamda aynı sonucu beklemek fazla iyimser olur, açık konuşayım.
Neler Bozulabilir? İşin Karanlık Tarafı
Vallahi, Bakın şimdi, mount-based labeling çoğu iş yükünde baya iş görüyor. Ama “çoğu” ile “hepsi” aynı şey değil, orası önemli. Şu senaryolarda ufak değil, baya can sıkan problemler çıkabiliyor:
Aynı Volume’ü Paylaşan Farklı Etiketli Pod’lar
Bir node üzerinde privileged. Unprivileged iki Pod aynı volume’ü kullanıyorsa — mesela biri spc_t etiketiyle çalışan bir log collector, diğeri standart container_t etiketiyle çalışan uygulama — mount-based yaklaşımda tek bir etiket atanıyor. Yanı iki farklı SELinux dünyası — itiraz edebilirsiniz tabi — aynı mount noktasında çarpışıyor, ve işin aslı burada biraz tökezliyor. Eskiden recursive relabeling her Pod için kendi etiketini uyguluyordu (subPath sayesinde), ama mount seviyesinde bu iş artık öyle rahat yürümüyor. Bu konuyla ilgili azd Hook’larını Python, TypeScript,.NET ile Yazın yazımıza da göz atmanızı tavsiye ederim.
Geçen hafta tam da bu konuyu bir müşteride konuştuk. Fluentd DaemonSet’leri hostPath volume ile /var/log dizinini okuyordu, ama SELinux etiketi uygulama Pod’larından farklıydı; yanı ortada klasik bir “neden şimdi bozuldu bu?” durumu vardı. Mount-based labeling açılınca Fluentd log okuyamaz hâle geldi. Çözüm? seLinuxChangePolicy: Recursive ile eski davranışa dönmek öldü — en azından geçiş döneminde, çünkü bazen yeni yol güzel görünse de eski yol daha az sürpriz çıkarıyor. .NET 10 Data Protection Güvenlik Açığı ve Acil Yama yazımızda bu konuya da değinmiştik.
seLinuxChangePolicy Alanı
Kubernetes bu meseleyi önceden düşünmüş ve Pod spec’ine yeni bir alan eklemiş. Hani şöyle bir şey var: Daha fazla bilgi için Codex Kurumsal Ölçekte: Ne Vaat Ediyor, Ne Eksik? yazımıza bakabilirsiniz.
spec:
securityContext:
seLinuxChangePolicy: MountBased # veya "Recursive"
seLinuxOptions:
level: "s0:c123,c456"Bunu yaşayan biri olarak söyleyeyim, MountBased yeni davranış; hızlı mount ediyor, lafı uzatmıyor. Recursive işe eski yöntem; daha yavaş ama bazı yerlerde hâlâ lazım oluyor. Eğer hiç belirtmezseniz ve SELinuxMount gate açıksa, varsayılan MountBased geliyor. İşte kritik nokta da burada — mevcut Pod tanımlarınızda bu alan yoksa, v1.37’ye geçtiğinizde davranış değişecek. Emin değilim ama sanırım en çok sürpriz de buradan çıkacak.
--feature-gates=SELinuxMount=true ile açıp iş yüklerinizi kontrol edin; sonra v1.37’de varsayılan açık geldiğinde “bu nereden çıktı?” demeyin.
Türkiye’deki Kurumsal Yapılar İçin Ne Anlama Geliyor?
Doğrusu, Türkiye’de, özellikle finans ve kamu tarafında, SELinux enforcing mod kullanımı baya yaygın. BDDK düzenlemeleri var, KVKK gereksinimleri var… Çoğu kurum RHEL tabanlı node’larla ilerliyor ve SELinux’u kapatmak da pek seçenek gibi durmuyor. Yanı bu değişiklik, Türkiye’deki Kubernetes kullanıcılarını doğrudan vuruyor.
Peki neden?
Logosoft’ta danışmanlık verdiğim bir bankacılık projesinde 200’den fazla microservice Kubernetes üzerinde çalışıyordu. Yaklaşık 30 tanesi shared volume kullanıyordu; çoğu config dosyaları ve geçici veri paylaşımı içindi. E peki, sonuç ne öldü? O 30 servisin her birine tek tek bakıp SELinux etiket uyumluluğunu kontrol ettik, biraz uğraştırdı açıkçası, ama v1.37’de production’da patlama yaşamaktan iyidir. SQL Server 2025’te Güvenlik ve MCP: Tek Motor Yeter mi? yazımızda bu konuya da değinmiştik.
Garip gelecek ama, Küçük bir startup’sanız durum başka. 10-15 Pod ile yaşıyorsanız, bu değişikliği muhtemelen pek hissetmezsiniz (ciddiyim). Ama enterprise tarafta yüzlerce Pod, onlarca shared volume. Sıkı güvenlik politikaları varsa, iş değişiyor; şimdiden hazırlığa başlamak lazım. Erken audit’in maliyeti düşük kalıyor, production’da yaşanacak bir incident’ın yanında işe neredeyse yok gibi.
Bir dakika — bununla bitmedi.
Pratik Audit Rehberi: Şimdi Ne Yapmalısınız?
Tamam, teori kısmını geçtik. Şimdi asıl mesele şu: “Ben bunu sahada nasıl yakalarım?” Açık konuşayım, bu audit işini v1.36’dayken yapmanız lazım; v1.37’ye geçip sonra “aa niye bozuldu” demenin pek anlamı yok, çünkü işin kırıldığı yer genelde tam da o geçiş anı oluyor.
Adım 1: SELinux Durumunu Kontrol Edin
Her node üzerinde getenforce komutunu çalıştırın. Enforcing görüyorsanız, evet, bu yazı direkt sizi ilgilendiriyor. Disabled ya da Permissive dönüyorsa… şanslısınız diyeyim, en azından bu başlıkta. Ama yine de göz ucuyla bakmakta fayda var, çünkü bazen ortam sandığınızdan farklı çıkıyor. Azure SDK Nisan 2026: Kritik Güvenlik Yaması ve Yenilikler yazımızda bu konuya da değinmiştik.
Adım 2: Shared Volume Kullanımını Tespit Edin
Şunu söyleyeyim, Aynı PersistentVolume’ü birden fazla Pod’un mount ettiği senaryoları bulun. Hele bir de de farklı SELinux etiketleriyle çalışan Pod’lar varsa, orada bir durup nefes alın derim. Bunu kubectl ile tarayabilirsiniz; aşağıdaki sorgu iş görüyor, hatta ilk bakışta biraz uzun görünse de neyin ne olduğunu hızlıca ortaya çıkarıyor:
# Tüm PVC'leri ve bağlı Pod'ları listele
kubectl get pods --all-namespaces -o json | \
jq -r '.items[] | select(.spec.volumes[]?.persistentVolumeClaim?) |
[.metadata.namespace,.metadata.name,
(.spec.volumes[] | select(.persistentVolumeClaim?) |.persistentVolumeClaim.claimName),
(.spec.securityContext?.seLinuxOptions?.level // "belirtilmemiş")] | @tsv'Adım 3: CSI Driver Uyumluluğunu Kontrol Edin
Burada, garip gelecek ama, Kullandığınız CSI driver’larının seLinuxMount alanını destekleyip desteklemediğine bakın. Azure Disk CSI driver bunu destekliyor, burada sorun yok gibi. Ama bazı üçüncü parti driver’lar için aynı şeyi söyleyemem; hani çalışır gibi durup sonradan sürpriz yapan tipler olur ya, biraz onlar gibi.
Adım 4: Geçiş Stratejisini Belirleyin
- Sorunsuz iş yükleri: Büyük ihtimalle hiçbir şey yapmanız gerekmiyor, otomatik olarak MountBased’e geçecekler — bu da Pod başlatma süresini kısaltıyor.
- Shared volume kullanan iş yükleri:
seLinuxChangePolicy: Recursiveekleyerek eski davranışı koruyun. (bence en önemlisi) - subPath kullanan Pod’lar: Burada biraz temkinli olun, çünkü subPath davranışı mount-based tarafta farklı hissedilebiliyor.
- Privileged container’lar: Bilhassa log collector ve monitöring agent tarafını tek tek gözden geçirin.
Bak şimdi, bir de şunu hatırlatayım: Kubernetes’te Production Debug Güvenliği: Rehber yazımda da benzer güvenlik bağlamlarından söz etmiştim. SELinux etiketleme konusu, debug container’larıyla da kesişiyor. Mesele sadece storage değil, çevrede dolaşan yetkiler de devreye giriyor.
Performans Etkisi: Gerçek Rakamlar
Bak şimdi, Hmm, bir saniye düşüneyim (kendi tecrübem). Evet, lafı dolandırmadan rakam konuşalım. Kendi test ortamımda 100.000 dosya barındıran bir PVC üzerinde ölçüm yaptım, recursive relabeling tam 47 saniye sürdü (evet, yanlış okumadınız), mount-based labeling işe aynı volume’u 0.3 saniyede geçti. 150 kat fark çıkıyor. Büyük volume’lerde bu iş daha da büyüyor.
Bi saniye — Bir finans müşterimizde PostgreSQL’in WAL dosyaları yüzünden volume içinde 800.000+ dosya birikiyordu. Pod restart’ları 3 dakikayı buluyordu — sebep de sadece SELinux relabeling idi (ciddiyim). Mount-based’e geçince süre neredeyse sıfıra indi. Tabiî, bu kadar dramatik sonuç her yerde çıkmaz; küçük volume’lerde farkı bazen zor bile görürsünüz.
Konuyla ilgili Kubernetes Image Promoter Yeniden Yazıldı: Sessiz Devrim yazıma da bakabilirsiniz; Kubernetes tarafında böyle sessiz ama iş gören değişiklikleri takip etmek bence önemli, hatta bazen asıl farkı onlar yaratıyor.
Benim Değerlendirmem: Doğru Yönde Ama Dikkatli Olun
Açık konuşayım — bu değişiklik, yanı SELinux tarafındaki o eski recursive relabeling huyunun bırakılması, bence uzun zamandır gelmesi gereken bir adımdı. Container dünyasında o davranış biraz ters düşüyordu; mount-based yaklaşım daha mantıklı dürüyor, daha az sürtünme çıkarıyor, hatta performans tarafında da fena değil. Evet.
Ama işin bir de diğer yüzü var. Breaking change’leri “varsayılan açık” getirmek genelde ufak bir risk taşıyor, bunu kimse yok sayamaz; Kubernetes topluluğu burada kademeli ilerleyerek bence düzgün bir iş çıkardı,. Türkiye’deki kurumsal müşterilerde versiyon upgrade’leri zaten başlı başına sancılıyken (bir de üstüne test, bakım penceresi, uygulama bağımlılıkları derken) SELinux davranışının değişmesi işleri gereksiz yere karıştırabiliyor. Peki neden?
Az önce “iyi yönde” dedim ama burada küçük bir takılma var: CSI driver tarafındaki seLinuxMount: true gereksinimi. Her driver bunu desteklemiyor, desteklemeyince de eski davranışa dönüyor; sonuçta bazı volume’ler hızlı çalışıyor, bazıları işe aynı ortamda farklı davranıyor. Insanın aklına hemen şu soru geliyor: Bu kadar mı? Keşke kernel tarafında daha ortak, daha düz bir çözüm olsaydı; çünkü şu anki tablo idare eder ama biraz yamalı dürüyor.
Sıkça Sorulan Sorular
SELinux kullanmıyorsam bu değişiklik beni etkiler mi?
Hayır, etkilemez. Kubelet, SELinux devre dışıyken ya da kernel’da hiç yokken tüm SELinux mantığını zaten atlıyor. Mesela Ubuntu gibi varsayılan olarak AppArmor kullanan dağıtımlarda bu değişikliğin sıfır etkisi var.
v1.37’ye geçmeden önce ne yapmalıyım?
Önce v1.36’da SELinuxMount=true feature gate’ını test ortamınızda açın. Sonra shared volume kullanan Pod’ları tespit edin, gerekli olanlara seLinuxChangePolicy: Recursive ekleyin. Açıkçası en çok atlanan kısım şurası: DaemonSet olarak çalışan log collector ve monitöring araçlarını da muhtemelen kontrol edin.
Mount-based labeling tüm volume tipleriyle çalışıyor mu?
Hayır. CSI driver’ın seLinuxMount: true ile bunu desteklemesi gerekiyor. Ayrıca hostPath, emptyDir gibi bazı volume tiplerinde davranış farklı olabiliyor — yanı hepsinin aynı şekilde davranacağını varsaymayın. Bence her volume tipini ayrı ayrı test etmek en sağlıklısı.
Eski davranışa kalıcı olarak dönebilir mıyım?
Evet, dönebilirsiniz. Pod spec’inde seLinuxChangePolicy: Recursive ayarlayarak eski recursive relabeling davranışını koruyabilirsiniz. Ama tecrübeme göre uzun vadede mount-based’e geçmek çok daha mantıklı — performans farkı gerçekten ciddi.
Bu değişiklik AKS veya managed Kubernetes servislerini de etkiliyor mu?
AKS varsayılan olarak Ubuntu node’ları kullanıyor, yanı SELinux enforcing modda değil. Ama RHEL tabanlı node pool kullanıyorsanız ya da custom node image’larınız varsa etkilenebilirsiniz. Aslında en sağlıklısı managed servis sağlayıcınızın feature gate politikasını doğrudan kontrol etmek.
Kaynaklar ve İleri Okuma
Kubernetes Blog: Breaking Changes in SELinux Volume Labeling
Kubernetes Resmî Dokümantasyonu: Security Context Yapılandırması
Kubernetes 1.27: Efficient SELinux Relabeling (Beta) Blog Yazısı
20+ 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.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
2 comments