Bu haftaki bakım planında Linux çekirdeğini öne almak için somut bir gerekçe var: CISA, aktif istismar kanıtıyla iki çekirdek açığını, ayrı bir duyuruyla da üçüncüsünü KEV kataloğuna aldı. Altyapı tarafında ise özellik adlarından çok varsayılan davranışlara bakmak gerekiyor; Kubernetes Memory QoS duyurusu bunun iyi bir örneği. Yama durumunu kesinleştirmeyi, yeni özellikleri denemekten önceye koyardım. Sonrasında depolama izinleriyle bellek politikalarını küçük bir düğüm grubunda sınamak için zaman ayırmak yerinde olur. Erişim yetkilerini veya bellek kullanımını değiştiren işlerde de başarı ölçütünü baştan yazmak lazım. Bir işlemin tamamlanmasıyla beklenen kısıtlamanın gerçekten uygulanması arasındaki fark, bu sayının bakım önerilerini belirliyor.
Linux KEV kayıtları: dağıtım paketini ve çalışan çekirdeği eşleştirin
CISA'nın 18 Eylül duyurusu, Linux Kernel için CVE-2025-39964 yarış durumunu ve CVE-2026-53266 sınır dışı yazma açığını aktif istismar kanıtıyla listeliyor. Aynı gün yayımlanan diğer kayıt CVE-2025-39682 için de aynı gerekçeyi veriyor. Bu, yama sırasını değiştirmek için yeterli; belirli bir sunucunun ele geçirildiği sonucunu çıkarmak için değil.
Üç kaydın teknik kapsamı farklı: Ubuntu'nun CVE-2025-39964 açıklaması AF_ALG soketine eşzamanlı yazmayı, Linux CNA'nın CVE-2026-53266 kaydı ebtables SNAT içindeki ARP adresi yeniden yazımını, Debian'ın CVE-2025-39682 kaydı ise kernel TLS tarafındaki sıfır uzunluklu kayıtların işlenmesini tarif ediyor. Hepsini aynı erişim koşuluna sahip tek bir saldırı gibi değerlendirmeyin.
Yama kararında dağıtımın paket tablosunu esas almak gerekiyor: Ubuntu, AF_ALG açığı için linux paketinin 24.04 dalında 6.8.0-90.91'i düzeltilmiş sürüm olarak gösteriyor; Debian ise TLS açığı için bookworm linux kaynak paketinde 6.1.153-1'i listeliyor. Bunlar farklı açıkların, farklı dağıtım dallarındaki düzeltmeleri; evrensel bir asgari çekirdek sürümü değil.
Linux sunucuları ve konteyner düğümleri işleten ekipler, her CVE'yi kullanılan paket çeşidiyle ayrı eşleştirmeli. Bakım kaydına kurulu paketin yanında çalışan çekirdeği de ekleyin. Yeniden başlatma veya canlı yama kararını bu eşleşmeyle kapatın; yalnızca güncelleme işinin başarılı dönmesini yeterli kabul etmeyin.
Kubernetes depolaması: manifestteki izin, düğümdeki izin olmayabilir
Kubernetes'in 16 Eylül yazısına göre v1.37'de bindMountOptions ve emptyDir mode alanları alpha düzeyinde; kullanım için API sunucusunda ve kubelet üzerinde VolumeBindMountOptions ile EmptyDirVolumeMode kapılarının açılması gerekiyor. Aynı resmî açıklama, alanlar belirtilmezse eski varsayılanların korunduğunu söylüyor. Sürüm yükseltmesini tek başına sıkılaştırma çalışması olarak işaretlemeyin.
Paylaşılan geçici dizinleri olan çok konteynerli pod'lar ve salt okunur kök dosya sistemi kullanan uygulamalar bu değişikliği incelemeli: yeni alanlar, konteyner içindeki bind mount üzerinde noexec gibi seçenekleri ve emptyDir oluşturma izinlerini tanımlamaya yarıyor. Ancak noexec açıklaması doğrudan çalıştırmayı engellemekle sınırlı; bunu her türlü kod çalıştırmanın önlendiği şeklinde raporlamayın.
Burada sürüm uyumsuzluğu özellikle dikkat istiyor: EmptyDirVolumeMode API sunucusunda açık, kubelet'te kapalıysa mode kabul edilmesine rağmen yok sayılabiliyor ve 0777'ye dönülüyor. Bind mount tarafında ise runtime'ın CRI mount_options desteği gerekiyor; uyumsuz düğüme ulaşan pod kubelet tarafından reddediliyor.
İlk denemeyi küçük bir düğüm grubunda yapın. Kabul testinde manifesti okumakla yetinmeyin; konteyner içindeki mount bayraklarını kontrol edin, geçici dizinden doğrudan çalıştırma girişimini sınayın. Paylaşılan dizin için de dosya sahibinden farklı bir kullanıcıyla silme testi ekleyin. Aynı sırada uygulamanın normal işini tamamlayabildiğini de kontrol edin.
Memory QoS: beta kapısı açık, bellek politikası sizin kararınız
Kubernetes'in 14 Eylül duyurusunda Memory QoS, v1.37 için varsayılan açık beta özellik olarak tanımlanıyor. Ancak varsayılan kubelet yapılandırması memory.high, memory.min veya memory.low değerlerini yazmıyor. Özelliğin açık olmasıyla kısıtlama ya da rezervasyon uygulanmasını ayrı kontrol maddeleri olarak ele alın.
Eski alpha ayarlarıyla çalışan ekiplerin ayrıca bakması gereken bir değişiklik var: memoryThrottlingFactor varsayılanı 0.9'dan null'a geçti; açıkça tanımlanmış değer korunurken eski varsayılana güvenen yapılandırma artık memory.high ayarlamıyor. Yükseltme öncesindeki etkin kubelet yapılandırmasını saklayın; sonrasıyla karşılaştırırken bu alanı özellikle kontrol edin.
Rezervasyon seçeneğini açarken düğümün bütününü düşünmek gerekiyor: TieredReservation düğümdeki tüm pod'lara uygulanıyor, tek tek pod seçilemiyor ve koruma konteyner cgroup'una yazılan page cache'i de kapsıyor. Aynı düğümde farklı bellek davranışları olan servisleri çalıştıranlar için bu sınır, özellik durumundan daha önemli olabilir.
Deneme düğümünde temsili yük çalıştırın; bellek baskısı sırasında uygulama gecikmesini ve OOM olaylarını birlikte izleyin. Hedef, yalnızca daha az OOM görmek olmamalı. Kabul edilebilir gecikme sınırını da baştan yazın; aksi hâlde değişikliğin uygulamaya yarayıp yaramadığına karar vermek zorlaşır. Geri dönüşte hangi kubelet alanlarını kaldıracağınızı bakım planına ekleyin.
Workers erişimi: dağıtım token'ını tek uygulamayla sınırlayın
Cloudflare, 15 Eylül duyurusunda kullanıcı ve API token erişiminin belirli bir Worker ile sınırlandırılabildiğini söylüyor. Şirketin Editor rolü tanımı içerik ve ayar değişikliğine izin verirken kaynak oluşturma ve silmeyi dışarıda bırakıyor. Birden fazla uygulama dağıtan CI sistemleri için incelenmeye değer ayrım bu.
Günlük dağıtım ile alan adı yönlendirmesini de ayırabilirsiniz: Cloudflare'a göre route veya Custom Domain değişikliği hem Worker üzerinde Editor hem ilgili zone üzerinde Workers Routes izni gerektiriyor; mevcut bağlantıyı değiştirmeyen yeni sürüm dağıtımı zone erişimi olmadan yapılabiliyor. Her pipeline'a hesap genelinde geniş bir yetki vermek yerine, dağıttığı Worker için ayrı token tanımlamayı değerlendirin.
Gözlemleme yapan bir ajana kod erişimi vermek zorunda değilsiniz: şirketin Metadata Read-Only rolü metrik, log ve trace erişimini kaynak kodu erişiminden ayırıyor. Yine de log içeriğini hassas veri açısından ayrıca inceleyin. Yetki rolünün adını, ajanın okuyacağı verinin güvenlik sınıflandırması yerine kullanmayın.
Geçişi bir deneme Worker'ıyla sınayın: izin verilen dağıtım başarılı olsun, başka Worker'a erişim ve silme isteği reddedilsin. Duyuru, eski roller için kaldırılma tarihi vermiyor ve D1, R2, KV tarafındaki kaynak düzeyi genişlemeyi gelecek çalışma olarak anlatıyor. Bu ürünlerde aynı kapsamın şimdiden bulunduğunu varsayarak erişim tasarlamayın.
Pingora bellek tasarrufu: asıl örnek, geçişin nasıl yapıldığı
Cloudflare, 18 Eylül yazısında Pingora tabanlı yönlendirme servisindeki değişikliklerle küresel ölçekte 100 TB'ın üzerinde RAM'i geri kazandığını belirtiyor. Bu sayı şirketin kendi ölçümü; küçük bir kurulum için tasarruf tahmini değil. Yazı, performans ekibi olmayan altyapı ekipleri için de yararlı bir devreye alma örneği içeriyor.
Şirketin teknik anlatımında hash noktalarının depolanması sekiz bayttan altı bayta indiriliyor ve sunucu başına üretilen hash sayısı yüzde 90 azaltılıyor. Kendi servisinizde benzer bir değişikliği düşünüyorsanız önce belleği hangi veri yapısının tuttuğunu ölçün; buradaki tasarruf oranını hedef olarak almayın.
Geçişte eski ve yeni hash halkaları bir süre birlikte tutulmuş, seçim istek hash'ine göre kararlı yapılmış ve trafik oranıyla veri merkezi kapsamı ayrı ayrı ilerletilmiş. Cloudflare, halkanın topluca değiştirilmesinin önbellek içeriğini büyük ölçüde işlevsiz bırakıp origin trafiğini artıracağını anlatıyor.
Benzer bir yönlendirme veya önbellek değişikliğinde yalnızca süreç belleğini başarı ölçütü yapmayın. Origin yükünü de kabul koşuluna ekleyin. Eski veri yapısını kaldırmadan önce geri dönüş yolunu deneyin. Bu testin sonucunu görmeden dağıtım kapsamını genişletmezdim.
Bu hafta neye bakmalı?
- Linux envanterinde üç CVE'yi dağıtım ve paket çeşidiyle eşleştirin; çalışan çekirdeğin düzeltme durumunu bakım kaydına yazın.
- Kubernetes depolama pilotunda hem başarılı uygulama çalışmasını hem reddedilmesi gereken dosya işlemlerini sınayın. API sunucusu ile kubelet kapılarını ayrı kontrol edin.
- Memory QoS için yükseltme öncesi ve sonrası etkin ayarları karşılaştırın; rezervasyon denemesine gecikme kabul sınırı koyun.
- Bir Workers pipeline'ını uygulamaya özel token'a geçirin. Başka Worker'a erişimin reddedildiğini doğrulamadan kapsam daraltma işini kapatmayın.
- Bellek optimizasyonu planlıyorsanız trafik ve geri dönüş testini aynı değişiklik kaydına ekleyin; yalnız RAM grafiğiyle karar vermeyin.
