Kubernetes v1.37, noexec bind mount seçeneklerini ve emptyDir izin modlarını getiriyor

İki alan, uzun süredir süren bir depolama açığını kapatıyor

Kubernetes v1.37, iki depolama güvenliği kontrolü getiriyor: operatörlerin bir container runtime'ının oluşturduğu mount'lara noexec, nosuid ve nodev gibi Linux bayraklarını uygulamasını sağlayan bind mount seçenekleri ve emptyDir volume'lerinde sabit kodlanmış 0777 varsayılanının yerini alan bir izin modu. Resmi Kubernetes v1.37 duyurusunu yeniden aktaran dev.to'daki bir Netics yazısına göre her iki özellik de VolumeBindMountOptions ve EmptyDirVolumeMode feature gate'leri arkasında alpha olarak geliyor; bu gate'lerin API sunucusunda ve kubelet'te etkinleştirilmesi gerekiyor.

Bunların ele aldığı boşluk eskiden beri var. Yazının açıkladığı gibi, Kubernetes'te en yaygın kullanılan yazılabilir volume türü olan emptyDir, 0777 izinleriyle oluşturuluyordu ve volume'ler container'lara herhangi bir noexec bayrağı olmadan bind-mount ediliyordu. Bunun pratik sonucu şuydu: salt-okunur kök dosya sistemine sahip bir container'ın bile yazılabilir ve çalıştırılabilir volume mount'ları vardı. Ele geçirilmiş bir süreç, bir binary'yi scratch alanına bırakabilir, çalıştırılabilir hale getirebilir ve güvenlik modelinin bilerek yazılabilir bıraktığı tek yerden çalıştırabilirdi. Yazı, dış denetçilerin bunu Kubernetes 1.24 Güvenlik Denetimi'nde (NCC-E003660-7HM bulgusu) dile getirdiğini ve takip edilen #48912 numaralı GitHub issue'sunun bu sürüme kadar açık kaldığını belirtiyor.

Her özellik nasıl çalışıyor

volumeMounts'a gelen ilk alan bindMountOptions, KEP-5855'ten geliyor ve pod spec'indeki volumeMounts üzerinde yer alıyor. Kubelet, seçilen seçenekleri CRI Mount mesajı aracılığıyla container runtime'ına iletir; runtime bunları OCI runtime spesifikasyonuna dahil eder ve alt seviye runtime da bunları container içindeki bind mount'a uygular. Alan volumeMounts üzerinde yer aldığı için neredeyse her volume türünü kapsıyor — emptyDir, PersistentVolume'lar, CSI, projected volume'lar, ConfigMap ve Secret'lar; tek istisna image volume'leri — ve bir volume'ü paylaşan kardeş container'lar farklı bayraklar isteyebilir.

KEP-5502'den gelen ikinci alan mode ise emptyDir için geçerli. Operatörler, sticky bit sayesinde her container'ın yazabilip silmeyi yalnızca dosya sahibiyle root'a sınırlandıran paylaşımlı bir çalışma alanı için 01777 belirtebilir; bu, /tmp'nin bir host üzerindeki davranışını yansıtır — ya da bir scratch volume'ü belirli bir gruba kısıtlamak için 0750 gibi daha sıkı bir değer verebilir. Yazıya göre bir init container'dan chmod çalıştırma yöntemi kırılgandı ve denetlenmesi zordu; yeni alan izni bildirimsel (declarative) hale getiriyor.

Etrafında plan yapmaya değer alpha uyarıları

İki özellik sürüm farkı (version skew) altında çok farklı davranıyor ve yazı bu asimetriyi özellikle vurguluyor:

• API sunucusunda EmptyDirVolumeMode gate'i etkinse ama bir düğümün kubelet'inde değilse, mode alanı sessizce yok sayılır ve kubelet 0777'ye geri döner — yani özelliğin var olma amacını oluşturan varsayılana.
• bindMountOptions, Node Declared Features'a dayanıyor; böylece scheduler, runtime desteği olmayan düğümlere pod yerleştirmekten kaçınıyor ve böyle bir pod yine de oraya düşerse kubelet bayrakları sessizce atmak yerine pod'u reddediyor.

İki etkileşim daha var: bir pod'un security context'indeki fsGroup ayarları, Secret ve ConfigMap volume'lerindeki mevcut defaultMode davranışıyla uyumlu şekilde emptyDir modunu geçersiz kılıyor ve her iki alan da yalnızca Linux düğümlerinde geçerli.

Aşamalı bir rollout yolu

Yazı, neredeyse her workload'un dokunduğu volume'lerle başlamayı öneriyor: her iki gate'i tek bir düğümde etkinleştirin, scratch volume'leri noexec ve nosuid ile mount edin ve kök dosya sistemini salt-okunur tutun. Bu ayarlar birlikte, bir saldırganın geçici depolamadan payload indirip çalıştırabileceği yolu kapatıyor. Çok container'lı pod'ların kullandığı paylaşımlı çalışma alanları, örneğin CI build dizinleri, 01777'ye taşınabilir; böylece ele geçirilmiş bir container başkasının artifact'lerini silemez. Stateful workload'lar daha fazla sabır gerektiriyor, çünkü PersistentVolume ve CSI benimsenmesinin yaygınlaşması daha uzun sürecek ve karma sürümlü cluster'lardaki sessiz 0777 geri dönüşü, ekiplerin şimdilik tek başına mode'a garanti olarak güvenemeyeceği anlamına geliyor.

Neden önemli

Yıllardır bir container'ın savunmasındaki en zayıf hedef image'ı değil, yazılabilir volume'ü oldu. Admission politikası bir cluster'a neyin girdiğini denetleyebilir ama bir pod çalışmaya başladıktan sonra bir mount edilmiş volume'ün neye izin verdiğini kontrol edemez; mount bayrakları ve dizin modları tam olarak bu katmanda devreye giriyor. Şimdiye kadar Kubernetes operatörlere bunları yerel bir yolla ayarlama imkânı vermiyordu ve sağlamlaştırılmış pod'ların scratch alanında çalıştırılabilir bir kaçış kapısı bırakıyordu. Bu alpha özellikler o kapıyı kapatıyor ve karma düğüm sürümleri çalıştıran herkes, daha geniş bir rollout'tan önce bunları test etmeye başlamalı.