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.
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
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.
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.
2 comments