Kubernetes CVE Kayıt Düzeltmesi: Tarayıcılarınız Şaşıracak
Geçenlerde Kubernetes Security Response Committee’den (SRC) gelen bir duyuru, sahada uzun zamandır konuştuğumuz bir şeyi nihayet resmileştirdi: bazı eski CVE kayıtlarında “fixed version” alanı var. Açık aslında kapanmamış. Yanı kâğıt üstünde “düzeltildi” yazıyor, gerçekte işe öyle değil. Şaşırdım mı? Pek sayılmaz. Uzun süredir küme yöneten biriyseniz, bu üç dört CVE’nın zaten biraz “design trade-off” koktuğunu bilirsiniz; ama tarayıcıların buna göre rapor basması ayrı bir meseleydi, işte asıl gürültü de oradan çıktı.
Dürüst olmak gerekirse, 1 Haziran 2026 itibarıyla SRC bu kayıtları düzeltecek. Evet, tarih net. Sonuç da biraz sert olacak: vulnerability scanner’larınız bir sabah kalktığında, dün “temiz” dediği kümelerde aniden açık göstermeye başlayacak. Kısacası, peki neden? Çünkü ortamda yeni bir şey patlamıyor; sadece kayıtlar nihayet gerçeğe yaklaşıyor. Kafa karıştırıcı mı? Biraz.
Bu yazıda hem teknik tarafı anlatacağım hem de Türkiye’deki kurumsal müşteri tarafında bunun ne anlama geldiğini, hangi mitigasyonlarla yola devam edebileceğinizi paylaşacağım. Azure Kubernetes Service (AKS) kullananlar için de ayrıca not düşeceğim. Orada işin rengi biraz değişiyor, hani her zaman olduğu gibi.
Olay tam olarak nedir?
Kısa cevap şu: Kubernetes ekibi, OSV (Open Source Vulnerabilities) formatında resmî feed üretirken bazı eski CVE kayıtlarının yanlış işaretlendiğini fark etti. Mesela CVE-2020-8561, CVE-2020-8562 ve CVE-2021-25740 için kayıtlarda bir “fixed version” görünüyor. Ama işin aslı, bu açıklar o klasik anlamda kapatılmadı; hatta kapatılmaya çalışılsa, Kubernetes’in temel davranışı bozulurdu.
Bakın, burayı atlarsanız yazının kalanı anlamsız kalır.
SRC şimdi bu kayıtları “tüm sürümleri etkiler, fix yok” diye güncelliyor. Bir de CVE-2020-8554 var; onun durumu zaten doğruydu, sadece versiyon gösterimi biraz daha standart hâle gelecek. Evet, mesele bu kadar sade. Ama kafa karıştıran tarafı da tam burada başlıyor.
Burada altı çizilmesi gereken şey şu: Bu açıklar yeni değil. Yıllardır biliniyor. Sadece kayıt sistemindeki bir tutarsızlık düzeltiliyor. Yanı ortamınız bugünden yarına daha “güvensiz” hâle gelmiyor — sadece tarayıcılarınız artık doğru bilgiyi görecek.
Neden “fix” yok? Bu nasıl bir mantık?
Küçük bir detay: Açık konuşayım: Bazı güvenlik sorunlarını kod değiştirerek kapatamazsınız. Çünkü ortadaki şey, (belki yanılıyorum ama) kodun yapması gereken meşru bir davranışın yan etkisi oluyor; yanı kötü görünen kısım, aslında başka bir senaryoda işe yarayan mekanizmanın kendisi. Klasik örnek de şu: HTTP redirect takip etme. kube-apiserver, admission webhook’larla konuşurken HTTP redirect’leri izliyor, bunu kaldırırsanız dünya genelinde baya fazla meşru entegrasyon kırılır (ve sonra herkes size dönüp bakar), ama bu davranış yerinde durdukça da AdmissionWebhookConfiguration’ı yapılandırabilen biri sunucuyu iç ağdaki adreslere yönlendirebilir.
Yanı, İşte mesele burada düğümleniyor. Bu yüzden bu açıklar “architectural trade-off” tarafında dürüyor. Çözüm kodda değil; idarede, yetki yönetiminde ve network policy’lerinde (kendi tecrübem). Yanı top biraz sizin sahada. Peki, peki neden? Çünkü böyle durumlarda asıl iş, sistemi nasıl kullandığınızda bitiyor.
Şey… aslında şaşırtıcı değil.
Üç açığı tek tek konuşalım
CVE-2020-8561: kube-apiserver webhook redirect
Severity: Orta (4.1). Hikâye kabaca şu: kube-apiserver, admission webhook’a istek atarken, webhook bir HTTP 3xx redirect dönerse önü izliyor. Kulağa küçük bir detay gibi geliyor, ama değil; saldırgan AdmissionWebhookConfiguration tarafına erişim alırsa, API server’ı iç ağdaki başka bir endpoint’e çevirebiliyor. Yanı işin özü SSRF’e çıkıyor.
Bunu yaşayan biri olarak söyleyeyim, Sahada bunu en çok şu durumda dert ediyoruz: multi-tenant kümelerde, namespace seviyesinde yetki verilmiş bir kullanıcının ValidatingWebhookConfiguration oluşturma hakkı da varsa. İlk bakışta “eh, sadece webhook” diyorsunuz. Sonra olay dönüp dolaşıp iç servislere kadar gidiyor (inanın bana). Açık konuşayım, insanı en çok şaşırtan kısım da bu oluyor.
Mitigasyon tarafında ben üç şeye bakıyorum. Birincisi, API server log level’ını 10’un altında tutun; çünkü yoksa response body’ler de log’a düşebiliyor. Redirect ile çekilen iç servis cevapları ortalıkta gezmeye başlıyor. İkincisi, --profiling=false bayrağını açın; bunu kapatmadan rahat etmek zor. Üçüncüsü de AdmissionWebhookConfiguration oluşturma yetkisini RBAC’te baya sıkı kısıtlayın, (evet, doğru duydunuz). Bunu cluster-admin gibi düşünmek daha doğru oluyor.
Ve işler burada ilginçleşiyor.
Evet.
CVE-2020-8562: TOCTOU ile proxy bypass
Eh, Bu açık biraz daha sinsi. Severity düşük (3.1), ama insanın kafasını kurcalıyor; Time-of-Check to Time-of-Use yarış koşulu var burada. API server proxy önce hostname’i çözüyor, “tamam bu izinli IP” diyor, sonra isteği gönderiyor. O aradaki birkaç milisaniyede DNS cevabı değişirse check edilen IP ile kullanılan IP farklı hâle gelebiliyor.
Nasıl desem, exploit etmek öyle kolay değil. Ama zaten tam da bu yüzden fix’i de rahat olmuyor; DNS davranışını kökten değiştirmek gerekiyor ve bu da başka yerleri bozabiliyor (özellikle mevcut cluster alışkanlıklarını). Peki bunu neden söylüyorum? Yanı çözüm var ama fiyatı biraz can sıkıyor.
Vallahi, Ben burada mitigasyon olarak API server’ın ağ erişimini sıkı tutmayı tercih ederim. AKS kullanıyorsanız private cluster ile dedicated subnet ikilisi fena iş görmüyor, hatta çoğu senaryoda yeterince rahatlatıyor diyebilirim.
Bi saniye — Daha açık söyleyeyim, peki neden?
CVE-2021-25740: Endpoint slice’lar üzerinden NetworkPolicy bypass
Buradaki mesele şu: Bir kullanıcı başka bir namespace’teki servise yönelik Service veya Endpoint oluşturabiliyorsa, NetworkPolicy’leri pratikte devre dışı bırakabiliyor. Çünkü policy tarafı genelde label selector mantığıyla ilerliyor; ama Service/Endpoint eşlemesi ayrı bir katman ve orada işler biraz kayıyor. Daha fazla bilgi için
Evet.
Pratik bir RBAC örneği
Webhook yetkilerini kısmak için tipik bir ClusterRole şöyle dürüyor, basit. Etkili; create/update/delete vermeyince işin şekli değişiyor (özellikle admission tarafında), çünkü sadece okuma izni olan biri gidip config’i kafasına göre oynayamıyor:
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: webhook-config-restricted
rules:
- apiGroups: ["admissionregistration.k8s.io"]
resources: ["validatingwebhookconfigurations", "mutatingwebhookconfigurations"]
verbs: ["get", "list", "watch"]
# create, update, delete YOK — bilinçli olarak.
Sonra create/update yetkisini yalnızca dedicated bir “platform-admin” grubuna verirsiniz. Tahmin eder mısınız? Az önce başka şeyler anlattım ama burada asıl mesele şu: bu ayrım CVE-2020-8561’in sömürülmesini pratikte epey zorlaştırıyor; kod yazmadan, sürüm yükseltmeden — dümdüz RBAC ile hallediyorsunuz işi.
Peki neden?
Bu kararı nasıl değerlendiriyorum?
Açık konuşayım, SRC burada bence doğru bir yere basıyor. Yıllardır “fixed version” alanına bakıp içinden “bu biraz yamuk dürüyor” diyen. Tarayıcı çıktısı temiz gelince rahatlayan ekipler vardı; işte o rahatlık şimdi bozuluyor (bu konuda ikircikliyim). Rahatsız edici mi? Evet. Ama dürüstçe söyleyeyim, güvenlik tarafında yanlış pozitif can sıkar, yanlış negatif işe daha kötü vurur.
Bir eksik var tabiî. SRC, mitigasyon dokümantasyonunu daha sert ve görünür biçimde duyurmalı bence. Sadece bir blog post ile geçiştirmek yetmez, yanı en azından bana yetmez gibi geliyor; Kubernetes docs içinde, “Security” sekmesinde, bu üç CVE için tek yerde duran kalıcı bir rehber sayfası olmalı. Şu anki yapı biraz dağınık dürüyor, hani aradığını buluyorsun ama iki dakika sonra “nerede kalmıştı bu?” diye tekrar bakıyorsun.
Hani, Konuyu biraz açmışken, Kubernetes ekosistemindeki diğer yazılarıma da göz atmak isterseniz: SIĞ Storage’ı Tanımak: Kubernetes’te Veri Kalıcılığının Mutfağı ve genel güvenlik tarafında Copilot Autofix Azure DevOps’ta: Alert Yığını Bitiyor mu? yazılarımı öneririm. Bir de DevSecOps tarafında ilgi çekici bulduğunuz olursa CodeQL 2.25.6 ile Sessiz Ama Güçlü Güvenlik Sıçraması yazısı da konuyla yakından ilgili; şey, orada da bazı küçük detayların aslında ne kadar çok şey değiştirdiğini anlatmaya çalışmıştım.
Bunu biraz açayım.
1 Haziran öncesi yapılacaklar listesi
Lafı uzatmadan, somut bir aksiyon listesi:
- Vulnerability scanner ürünleriniz OSV feed’i ne sıklıkla çekiyor, bunu bir kontrol edin. Çoğu günlük çekiyor, ama bazısı gecikiyor; işte orası can sıkıyor.
- Güvenlik ve compliance ekibinize ön bilgilendirme yapın. “Haziran başında 3 yeni CVE alarmı göreceksiniz, bunlar yeni değil, kayıt güncellemesi” diye söyleyin; yoksa sabah kahvesi daha bitmeden panik başlıyor. — ciddi fark yaratıyor
- Mevcut RBAC yapılandırmaunuzu gözden geçirin. AdmissionWebhookConfiguration yetkilerini denetleyin, çünkü küçük bir boşluk sonra gereksiz bir sürü soru çıkarabiliyor.
- API server
--profilingbayrağının false olduğunu doğrulayın. Evet, basit görünüyor. - Log level’ı kontrol edin. AKS’te default hali fena değil, ama özelleştirme yapıldıysa bir bakın derim; bazen sessizce şişip gidiyor.
- Audit log’larda anormal admission webhook trafiğine yönelik bir uyarı kuralı yazın. Hani şu ilk bakışta gereksiz gibi duran ama sonra “iyi ki koymuşuz” dedirten tipten bir kural var ya, işte o.
- Exception kaydı şablonunuzu hazırlayın — denetimlere hazırlıklı olun. Bu kısmı son güne bırakınca işler biraz çorba olabiliyor.
Bu listeyi hafta sonu oturup 2-3 saatte bitirirsiniz. Sonra Haziran’da rahat olursunuz; yanı en azından sürpriz sayısı ciddi biçimde azalır.
Sıkça Sorulan Sorular
Bu CVE’ler benim kümem için gerçek bir risk mi?
Doğrudan exploit açısından düşük-orta seviye riskler bunlar. Hepsi ya çok yüksek yetki istiyor (mesela AdmissionWebhookConfiguration oluşturabilmek gibi) ya da çok spesifik koşullara bağlı (TOCTOU yarış koşulu gibi). Ama açıkçası, compensating control’leri uygulamadıysanız ve üstüne bir de multi-tenant küme işletiyorsanız, bence bunları ciddiye almanız gerekiyor.
Kubernetes’i en son sürüme yükseltsem bu CVE’ler gider mi?
İtiraf edeyim, Hayır, gitmez. İşin püf noktası da zaten bu. Bu açıklar mimarı trade-off olarak işaretleniyor — — ki bu tartışılır — yanı Kubernetes projesi bunları kapatmama kararı aldı, çünkü kapatmak temel davranışı bozardı. Kayıtlar “tüm sürümleri etkiler” şeklinde güncellenecek (inanın bana)
AKS, EKS, GKE arasında bu CVE’ler açısından fark var mı?
Upstream Kubernetes davranışı olduğu için temelde pek fark yok. Ama managed servis sağlayıcısının default konfigürasyonu burada gerçekten belirleyici oluyor. Tecrübeme göre AKS’te private cluster + Azure RBAC + Defender for Containers kombinasyonu, mitigasyon tarafında hatırı sayılır bir avantaj sağlıyor. EKS ve GKE’de de benzer kontroller var, yanı sadece kurulum yöntemi farklılaşıyor.
Tarayıcı çıktımda bu CVE’ler göründüğünde compliance denetiminde sorun yaşar mıyım?
Doğru dokümantasyonla hayır, yaşamazsınız. “Accepted risk” exception kaydı oluşturup uyguladığınız compensating control’leri belgelerseniz, ISO 27001, SOC 2, PCI DSS gibi denetimlerde sorun çıkmıyor. Anahtar nokta şu: Denetçiye “biliyoruz, şu kontrolleri uyguluyoruz” diyebilmek. Görmezden gelmek işe bence hiç iyi bir strateji değil.
OSV feed’i ile NVD arasında fark olacak mı?
Olabilir, hani her zaman senkronize gitmiyorlar. NVD güncellemeleri OSV kadar hızlı yansımıyor. Tarayıcınız hangi feed’i kullanıyorsa o belirleyici oluyor zaten. Kubernetes resmî CVE Feed ve OSV güncellemeleri 1 Haziran’da yapılacak; NVD’ye yansıması işe birkaç hafta sürebilir. Neden önemli bu? Trivy, Grype gibi OSV-first tarayıcılarda etkiyi çok daha hızlı görüyorsunuz.
Kaynaklar ve İleri Okuma
Kubernetes Blog: Reconciling the Past — Correcting Records for Unfixed Kubernetes CVEs
Kubernetes Official CVE Feed Dokümantasyonu
Open Source Vulnerabilities (OSV) Schema
Doğrusu, Azure Kubernetes Service Güvenlik Kavramları — Microsoft Learn
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.
3 comments