Geçen hafta bir bankacılık müşterisindeydim. Adamlar Kubernetes cluster’larını yeni bir vulnerability scanner ile taratmaya başlamışlar. Bizi aradılar: “Aşkın bey, daha önce hiç görmediğimiz üç tane CVE çıktı taramada, bunlar yeni mi?” Açıp baktım — CVE-2020-8561, CVE-2020-8562. CVE-2021-25740. Yeni değildi. 2020’den, 2021’den kalma. Sadece kayıtları yeni güncellenmiş.
İşte Kubernetes Security Response Committee (SRC) tam da bunu duyurdu: 1 Haziran 2026’dan itibaren bazı eski CVE kayıtlarındaki fixed version alanları temizleniyor. Yani “şu sürümde düzeltildi” yazıyordu ya, o yanlışmış meğer. Bu açıklar aslında pek tam anlamıyla kapatılmadı; kapatılması da pek mümkün değil. Mimarı bir tercih meselesi, biraz da işin doğası.
Çok konuştum, örnekle göstereyim.
Tuhaf ama, Bu yazıda ne olduğunu, neden böyle olduğunu ve sahada bizim ne yapmamız gerektiğini lafı uzatmadan anlatayım (bizzat test ettim)
Önce şunu netleştirelim: “Unfixed CVE” ne demek?
Şöyle söyleyeyim, Açık konuşayım, “düzeltilemeyen bir güvenlik açığı” cümlesi kulağa sert geliyor. Müşteriye anlatırken ilk tepki hep aynı oluyor: “Yani bu sistem güvensiz mi?” Hayır, öyle değil.
Şunu söyleyeyim, Bazı açıklar var ki kodla oynayıp düzeltmeye kalkarsanız Kubernetes’in temel davranışını kırıyorsunuz. HTTP redirect’leri yok mu sayalım? O zaman onlarca legitimate integration patlar. DNS çözümlemesini sertleştirelim mi? Eee o zaman normal proxy davranışı bozulur, sonra herkes bana bakar. Bu yüzden ekip “biz bunu kapatmayacağız, mimarı bir trade-off bu” demiş — ama yıllar önce CVE kaydına “fixed in X” yazılmış. Şimdi o hata düzeltiliyor işte.
Kısacası: Kod değişmiyor, sadece kağıt üzerindeki kayıt gerçekle uyumlu hâle getiriliyor. Ama bunun pratikte ciddi bir sonucu var — taramalar bundan sonra bu açıkları size tekrar tekrar göstermeye başlayacak.
Neden şimdi düzeltiliyor?
Kubernetes ekibi son birkaç yıldır Open Source Vulnerabilities (OSV) formatına geçiş yapıyor. OSV dosyalarını üretirken fark etmişler ki bazı CVE kayıtları yalan söylüyor gibi duruyor; yani “fixed in v1.20” diyor. Gerçekte hiçbir zaman fixlenmemiş. Modern vulnerability scanner’lar (Trivy, Grype, Snyk, Defender for Containers — neyse ne) bu alanı temel alıyor. Yanlış bilgi = false negative = sahte güven duygusu.
Ve işler burada ilginçleşiyor.
Bir şey dikkatimi çekti: Bence bu doğru yönde atılmış bir adım. Geç kalınmış olabilir ama atılmış sonuçta. Şeffaflık adına +1.
Etkilenen üç CVE — sahadan teknik analiz
CVE-2020-8561: kube-apiserver Webhook Redirect’i
Severity: Orta (4.1). Mesele şu: kube-apiserver, admission webhook’larıyla konuşurken HTTP redirect’leri takıp ediyor. Yani webhook “git şuraya bak” diyorsa API server gidip oraya bakıyor; basit gibi duruyor ama biraz kurcalayınca iş karışıyor. AdmissionWebhookConfiguration tanımlayabilen biri — ki bu genelde cluster-admin yetkisi gerektirir — API server’ı internal network’e, private endpoint’lere yönlendirebilir.
Tuhaf ama, Niye fixlenmiyor? Çünkü redirect davranışını kapatırsanız standart HTTP client davranışı bozulur. Dünyanin yarısının webhook entegrasyonu çöker. Trade-off dediğim şey tam olarak bu.
Mitigation: API server log level’ı 10’un altında tutun (response body’ler log’a düşmesin), --profiling=false yapın ki kimse runtime’da log level’ı değiştirip kurcalamasın.
CVE-2020-8562: DNS TOCTOU ile Proxy Bypass
Severity: Düşük (3.1). TOCTOU — Time-of-Check to Time-of-Use — race condition var burada. API server proxy, kullanıcının verdiği hostname’i bir kere resolve ediyor (kontrol için), sonra ikinci kere resolve ediyor (kullanmak için). Arada DNS cevabını değiştirebilen biri varsa, kontrol aşamasında “ben temizim” dedirtip kullanım aşamasında “aslında 169.254.169.254 metadata endpoint’i” gösterebilir.
Burada, bir şey dikkatimi çekti: Niye fixlenmiyor? Çünkü DNS’i tek seferde resolve edip kilitlemek için ciddi bir refactor gerekiyor; üstelik bu da başka problemleri tetikliyor gibi duruyor. Daha fazla bilgi için AKS Fleet Manager Cross-Cluster Networking: Saha Notları yazımıza bakabilirsiniz.
CVE-2021-25740: Endpoint manipülasyonu ile cross-namespace forwarding
Şöyle söyleyeyim, Bu daha sinsi geliyor bana. Endpoint veya EndpointSlice oluşturma yetkisi olan bir kullanıcı, başka bir namespace’deki Service’in trafiğini kendi pod’una yönlendirebiliyor. Service mesh kurmadıysanız ve namespace izolasyonuna güveniyorsanız, can sıkıcı bir senaryo bu.
Mitigation tarafında en sağlıklı yaklaşım şu: Endpoint/EndpointSlice yazma yetkilerini sıkı RBAC ile sınırlayın. Hatta benim önerim — bu kaynakları doğrudan kullanıcıya açmayın; sadece controller’lar yazsın.
Bonus: CVE-2020-8554
Bu da unfixed zaten. ExternalIPs üzerinden MITM meselesi var burada. Kaydı aslında doğruymuş (“affects all — ki bu tartışılır — versions”), ama version format’ı standartlaştırılıyor şimdi. Sahada en sık karşılaştığım açık bu diyebilirim. Multi-tenant cluster’da ExternalIP yetkisini kontrol altına almazsanız başınız ağrır, açık konuşayım. GA4’ü Bırakıp Next.js + Supabase’e Geçmek: Neden? yazımızda bu konuya da değinmiştik.
Özet tablo: Neye dikkat edeceğiz?
| CVE | Severity | Tıp | Mitigation Özeti |
|---|---|---|---|
| CVE-2020-8554 | Medium | ExternalIP MITM | ExternalIP yetkisini RBAC ile kıs, admission policy yaz |
| CVE-2020-8561 | Medium (4.1) | Webhook redirect | Log level < 10, profiling kapalı, webhook config yetkisi kısıtlı |
| CVE-2020-8562 | Low (3.1) | DNS TOCTOU proxy bypass | Meteadata endpoint’lere network policy uygula, IMDSv2 kullan |
| CVE-2021-25740 | Medium |
Taramalar değişecek — ekibi şimdiden hazırlayın
Geçen yıl bir telekomda buna benzer bir şey yaşamıştık. Bir CVE’nın scoring’i değişmişti, severity “Low”d an “High”a çıkmıştı. SOC ekibi gece yarısı — ki bu tartışılır — bizi aradı: “Production’da High severity açık var!” Halbuki açık aynı açıktı, sadece NVD scoring’i güncellenmişti. O geceyi unutmam; saat 03 :00 ‘te Teams’te slide hazırlıyordum, baya dağıldık yani.
Şimdi gelelim işin can alıcı noktasına. .NET ve .NET Framework Mayıs 2026 Güncellemeleri: Saha yazımızda bu konuya da değinmiştik.
Bu sefer benzer bir kaos yaşamamak için şimdiden hazırlanmak lazım:
- Compliance ve SOC ekiplerini bilgilendirin. 1 Haziran sonrası bu üç CVE’nın tarama raporlarında “yeni” görünebileceğini, ama yeni olmadığını yazılı olarak iletin.
- Bir “accepted risk” registry’si tutun. Bu unfixed CVE’leri buraya ekleyin, mitigation’larınızı dokümante edin. Denetim zamanı bu doküman canınızı kurtarır, hani öyle boşuna söylemiyorum.
- Scanner’larınızın suppression policy’sını güncelleyin. Trivy’de
.trivyignore, Grype’ta config dosyası var. Ama “ignore” değil, “acknowledged with mitigation” olarak işaretleyin — fark önemli gerçekten. (bence en önemlisi) - Mitigation’ları teknik olarak uygulamış mısınız, kontrol edin.
Çoğu cluster’da
“şu CVE’y i pas geç”
“
denir ama mitigation hiç uygulanmamıştır.
Çıplaksınız yani.
Trivy kullanıyorsanız,
ile filtreleyip bu Medium/Low CVE’leri raporun dışında bırakabilirsiniz.
Ama tavsiye etmem —
görmezden gelmek yerine açıkça ”
kabul edildi,
mitigate edildi”
diye etiketlemek daha sağlıklı.
Audit’te fark eder.
Türkiye perspektifi:
Kurumsal müşterilerde gerçek hayat
Kendi deneyimimden konuşuyorum,
Bunu Türkiye’deki şirketler açısından değerlendirirsem,
durum biraz farklı.
Çoğu kurumsal Kubernetes kurulumunda gördüğüm tablo şu:
Cluster AKS veya OpenShift üzerinde,
RBAC default seviyede konfigüre edilmiş,
namespace izolasyonu var ama derinlikli policy yok.
Webhook configuration yetkisi kimde?
Genelde DevOps ekibinin tamamında.
Endpoint yazma yetkisi?
Servis hesaplarına alabildiğine açık. Docker İmajını Küçültmek: 1,58 GB’dan 186 MB’a yazımızda bu konuya da değinmiştik.
Yani bu CVE’lerin mitigation’ları kâğıt üzerinde basit görünüyor ama sahada uygulamak zaman alıyor.
Bir finans kuruluşunda RBAC sıkılaştırma projesi yapmıştık —
3 ay sürdü,
14 takımla görüşüldü,
en az 200 ServiceAccount audit edildi.
Kolay değil yani.
Küçük ekipseniz,
bir startup’sanız —
bence şu adımları yapın yeter:
ExternalIP’y i
veya
ile kısıtlayın,
webhook configuration için cluster-admin dışındaki kimseye yetki vermeyin,
IMDSv2’y i açın (
cloud’daysanız).
Bu üçü %80 riski kapatır,
fazlasını sonra konuşuruz.
Enterprise tarafındaysanız,
bu işin yapısal bir parçası olması lazım. Yıllık güvenlik review döngünüze bu unfixed CVE’leri ekleyin. Kubernetes ekosistemi yaşadıkça bu liste değişecek;
kim bilir gelecek yıl başka 3 tane daha çıkar. Süreç kurun,
tek seferlik aksiyon olmasın bu. Neyse uzatmayayım,
mesele biraz da disiplin işi.
Pratik bir Kyverno politikası örneği
ExternalIP kısıtlaması için en hızlı yol bu galiba.
Şöyle bir policy yazabilirsiniz: Bu konuyla ilgili Azure IaaS Performans: Sistem Düzeyli Yaklaşımın Gücü yazımıza da göz atmanızı tavsiye ederim.
apiVersion:
kyverno.io/v1
kind:
ClusterPolicy
metadata:
name:
block-external-
ips spec :
validationFailureAction :
Enforce rules :
-
name :
no-external-
ips match :
any :
-
resources :
kinds :
-
Service validate :
message : "
External IPs yasak —
CVE-
2020 -
8554 mitigation"
pattern :
spec :
X(externalIPs) : "
null"
Bu policy’yi production’a koymadan önce Audit mode’da bir hafta çalıştırın. Görünen o ki bazı legacy uygulamalar External IP kullanıyor olabilir ; onları bulup migrate etmeniz lazım. Ben ilk denediğimde 4 tane uygulama bu yüzden patladı, geri sarmak zorunda kaldım. Sonra audit mode’la başladım, çok daha temiz oldu.
Bu olay bize ne söylüyor?
Şunu söylüyor:
CVE veritabanları kutsal değil.
Yıllarca yanlış bir kayıtla yaşamışız.
Bu da gösteriyor ki güvenlik taramalarınızı kör güvenle takıp etmek doğru değil —
her açığı anlamak,
mitigation’ı bilmek,
“kabul edilen risk” ile “&düzeltmesi gereken risk”
arasındaki farkı görmek lazım.
Bir de şunu öğrendik:
Kubernetes ekibi şeffaflık konusunda samimi.
”
Eski kayıtlarımız yanlıştı,
düzeltiyoruz”
demek kolay değil.
Çoğu vendor bunu yapmaz.
Bu yüzden ben Kubernetes’in security süreçlerine güveniyorum ;
kusursuz değil ama dürüst.
İlgili konularda daha önce yazdıklarım var, bakanlara şöyle bırakayım: “>Kubernetes v1.
Ço;k cluster yön;e t e n ekipler içi nAKS Fleet Manager Cross-Cluste r Networking:
Sıkça Sorulan Sorular
Bu CVE’ler cluster’ımı gerçekten tehlikeye atıyor mu?
Aslında doğrudan internete açık bir API server’ınız yoksa. RBAC’ınız da makul sıkılıktaysa, bunları exploit etmek oldukça zor. Ama multi-tenant bir cluster işletiyorsanız durum farklı — özellikle CVE-2021-25740 (Endpoint cross-namespace) ve CVE-2020-8554 (ExternalIP) bence gerçekten ciddiye alınması gerekenler. Mitigation’ları uygulayın, geçin.
Vulnerability scanner’ım bunları “fixed” gösteriyordu, şimdi ne yapacağım?
1 Haziran 2026 sonrası scanner’ınızın veritabanı güncellenince bu CVE’ler tüm Kubernetes versiyonlarınızda görünmeye başlayacak. Panik yapmayın — yani yeni bir açık değil bu, sadece kayıt düzeltildi (bizzat test ettim). Mitigation’larınızı dokümante edip “accepted risk” olarak işaretlemeniz yeterli.
Bir dakika — bununla bitmedi.
Mitigation uygulamayı atlarsam ne ölür?
Açıkçası çoğu durumda hiçbir şey olmaz,. Bu açıkları exploit etmek belli yetkiler gerektiriyor — mesela webhook config oluşturma, endpoint yazma gibi şeyler (ilk duyduğumda inanamadım). Ama o yetkiler kötü niyetli birine geçerse — ki insider threat veya ele geçirilmiş bir credential ile pekâlâ olabilir — lateral movement için kapı açılıyor. Yani savunma derinliği prensibine göre yine de mitigate edin, tecrübeme göre bu tür “düşük ihtimalli” şeyler en kötü zamanda başınıza geliyor.
AKS, EKS, GKE gibi managed servisler de etkileniyor mu?
Evet, etkileniyor. Çünkü açıklar hani Kubernetes core’unda var. Managed servislerin kendi katmanlarında bazı default mitigation’lar olabiliyor — mesela AKS’te API server. Internal endpoint’lere erişimi kontrol ediyor. Ama yine de kendi RBAC, NetworkPolicy ve admission policy’lerinizi uygulamanız şart (kendi tecrübem). Cloud provider sızı tam kurtarmıyor, bunu sakın unutmayın.
OSV formatı CVE’nın yerini mi alıyor?
Almıyor, tamamlıyor. OSV daha makine-okunabilir bir format ve open-source projelere aslında çok daha uygun. CVE/NVD ile paralel çalışıyor. Kubernetes gibi projelerin OSV feed’lerini doğrudan kullanmak, NVD’nın gecikmeli güncellemelerini beklemeye kıyasla çok daha hızlı sonuç veriyor — bence bu geçişi erkenden yapmaya değer.
Kaynaklar ve İleri Okuma
Kubernetes Blog: Reconciling the Past — Correcting Records for Unfixed Kubernetes CVEs
Kubernetes Resmî CVE Feed Dokümantasyonu
Ne yalan söyleyeyim, Open Source Vulnerabilities (OSV) Schema
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.
