Kubernetes CVE Kayıt Düzeltmesi: Tarayıcılarınız Şaşıracak

⏱️ 11 dk okuma📅 20 Haziran 2026👁️ görüntülenme

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 Outcome-Driven Learning: OpenEnv ve Foundry ile Kurumsal RL yazımıza bakabilirsiniz.

Yukarıda anlattığım o katman ayrımı var ya, işte açık tam oraya basıyor. İnsan ilk anda “policy var ya sorun olmaz” diye düşünüyor (en azından benim deneyimim böyle). Sonra yetki modeliyle servis keşfi birbirine girince tablo değişiyor. Hatta bazen en temiz görünen mimarı bile burada beklenmedik şekilde tökezleyebiliyor.

Bunun fix’i ne olurdu? NetworkPolicy semantiğini komple değiştirmek olurdu ki bunu yapmak kolay değil; yaparsanız onbinlerce production cluster’ı kırarsınız (şaka gibi ama değil) (evet, doğru duydunuz). O yüzden mesele teknik olarak bilinse de operasyonel olarak dokunması zor kalıyor.

Tarayıcılarınız ne diyecek? Bekleyebileceğiniz sürpriz

Peki, bunu yaşayan biri olarak söyleyeyim, Şimdi işin biraz can sıkıcı tarafına gelelim. 1 Haziran’dan sonra şöyle bir tablo çıkabilir: Trivy, Grype, Aqua, Prisma, Defender for Cloud gibi tarayıcılar OSV feed’ını ya da NVD’yi çekiyor olacak ve bu üç CVE için “affected: all versions, no fix” satırını görmeniz çok olası (eh, fena değil). Yanı durum kabaca şu; sistem temiz sanıyorsunuz, ama tarayıcı başka bir şey söylüyor (ve açık konuşayım, bazen asıl kavga da burada başlıyor).

Yanı yamayla kapatamazsınız bunu. Sürüm yükseltmek de pek bir şey değiştirmiyor, işte mesele tam olarak burada düğümleniyor. Peki compliance ekibine ne diyeceksiniz? Bak şimdi, burada “exception management” devreye giriyor; çünkü bazen teknik olarak yapacak fazla şey kalmıyor, (ciddiyim). Kağıt üstünde doğru pozisyonu almak yine de gerekiyor (buna dikkat edin)

Peki neden? Daha fazla bilgi için Copilot Code Review’a AGENTS.md Desteği: Ne İşe Yarayacak? yazımıza bakabilirsiniz.

💡 Bilgi: Eğer ISO 27001, SOC 2 veya benzeri bir denetim sürecindeyseniz, bu üç CVE için “accepted risk with compensating controls” şeklinde bir exception kaydı oluşturmanızı şiddetle öneririm. Denetçiye “Kubernetes projesi bunları fix etmiyor, biz şu kontrolleri uyguluyoruz” diye gösterebileceğiniz bir döküman olsun.

Peki Türkiye’deki kurumsal yapı için bu ne demek?

Türkiye’deki banka, sigorta, telco ve kamu kurumlarındaki müşteri ekipleriyle konuştuğumda şunu görüyorum: vulnerability scanner çıktıları çoğu yerde baya siyah-beyaz okunuyor. Yanı listede bir CVE varsa, kapatılması bekleniyor; başka bir deyişle konu hemen “neden açık kaldı?” seviyesine düşüyor. Üst yönetime gidip “bu açık kapatılamaz, mimarı bir trade-off” demek kolay değil, hatta bazen insanın dili dolanıyor. Söylemeniz lazım, çünkü bu üç CVE 1 Haziran’dan sonra her tarayıcıda görünmeye başlayacak.

Tuhaf ama, Önerim net. Haziran gelmeden önce güvenlik ekibinize kısa ama dolu bir bilgi notu hazırlayın, sonra da bunu bir köşeye atmayın; içinde şu başlıklar olsun:

Bu üç CVE’nın SRC tarafından “unfixed” olarak işaretleneceği.
Sebebin mimarı trade-off olduğu.
Uyguladığınız compensating control’ler (RBAC kısıtlamaları, private cluster, audit logging, network policy stratejisi).
Exception kaydının nasıl ve nerede tutulacağı. (bence en önemlisi)

Bu notu önceden hazırlamak, 1 Haziran sabahı koşturmaktan çok daha mantıklı. Hani bazen tarama sonuçları otomatik mail olarak üst yönetime düşer ya, işte tam orada işler karışıyor; bir anda CIO “bu üç açık ne, neden hâlâ açık?” diye soruyor. Peki neden? Çünkü hazırlıksız yakalanınca açıklama yapmak da zorlaşıyor, karar vermek de. Şey, açık konuşayım, sahada bunu sık görüyorum.

AKS tarafında bakmanız gereken kontroller

Kendi deneyimimden konuşuyorum, Azure Kubernetes Service kullanıyorsanız, işiniz bir tık daha rahatlıyor (buna dikkat edin). Çünkü AKS bazı şeyleri zaten fena olmayan bir şekilde ayarlıyor. Ama durun, her şeyi default’a bırakınca olay bitmiyor; ben kendi müşterilerimde şu checklist’i neredeyse standart gibi uyguluyorum:

Private cluster: API server’ı public internete açık bırakmayın. Bu, CVE-2020-8562’nın sömürülme alanını ciddi biçimde daraltıyor.
Azure RBAC entegrasyonu: Native Kubernetes RBAC yerine Azure RBAC kullanın. AAD üzerinden audit trail de daha derli toplu oluyor, açık konuşayım.
AdmissionWebhookConfiguration için custom rol: Bunu sadece platform ekibinin oluşturabileceği şekilde kısıtlayın. Namespace admin’lere bu yetkiyi vermek bence gereksiz risk.
Azure Policy for AKS: Gatekeeper tabanlı policy’lerle hangi webhook’ların kabul edileceğini sıkı sıkıya kontrol edin.
Microsoft Defender for Containers: Audit log’larda anormal redirect davranışlarını yakalamak için baya iş görüyor.
NetworkPolicy enforcement: Calico ya da Cilium kullanın. AKS’in default’u olan Azure NPM bana kalırsa biraz fazla temel kalıyor.

Bir de şu var: AKS’in API server log level’ı default hâlde makul sayılır, ama sahada debug diye açılıp unutulmuş yapılandırmalar gördüm, hani insan şaşırıyor; “sorunu çözelim” diye verbosity’i 10’a çekip orada bırakmak CVE-2020-8561 açısından gereksiz bir kapı aralıyor, sonra kimse dönüp bakmıyor bile (ben de ilk duyduğumda şaşırmıştım) Daha fazla bilgi için RDBMS’ten Cosmos DB’ye Geçiş: AI Asistanı Ne Kadar İşe Yarar? yazımıza bakabilirsiniz. Binlog MCP Server: Build Sorunlarını Copilot’a Çözdürmek yazımızda bu konuya da değinmiştik.

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. Bu konuyla ilgili Copilot Usage Metrics API’ye ai_credits_used Geldi: FinOps İçin Ne Anlama Geliyor? yazımıza da göz atmanızı tavsiye ederim.

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 --profiling bayrağı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

Senaryo	Önce	1 Haziran sonrası
Kubernetes 1.28 cluster	“Temiz” (yanlış)	3 CVE listelenecek
AKS 1.30	“Temiz” (yanlış)	3 CVE listelenecek
En son sürüm Kubernetes	“Temiz”		3 CVE listelenecek

Aşkın KILIÇYazar

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.

AZ-305AZ-104AZ-500AZ-400DP-203AI-102

Bu içerik işinize yaradı mı?

Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.

X / Twitter LinkedIn YouTube GitHub

Kubernetes CVE Kayıt Düzeltmesi: Tarayıcılarınız Şaşıracak