Kubelet API Yetkilendirmesi GA Oldu: Güvenlik Devrimi

Bakın şimdi, Kubernetes güvenliği tarafında yıllardır can sıkan bir mesele vardı. Monitöring agent’larınıza, log toplayıcılarınıza ya da sadece metrik okuyan bir servise izin vermek istiyorsunuz,. Iş dönüp dolaşıp node üstündeki container’larda — itiraz edebilirsiniz tabi — komut çalıştırabilecek kadar geniş bir yetkiye geliyordu. Saçma değil mi? İşte Kubernetes v1.36 ile bu gariplik nihayet toparlanıyor.

Fine-grained kubelet API authorization özelliği GA seviyesine çıktı. Yanı artık deneysel değil, production’da kullanılır hâle geldi. Bu haberi görünce açık konuşayım, ben de “oh be” dedim; çünkü AZ-500 güvenlik mimarisi çalışmalarımda ve kurumsal müşterilerle Kubernetes güvenliğini konuşurken bu konu hep önümüze düşüyordu.

Bir dakika — bununla bitmedi.

nodes/proxy Sorunu: Neden Bu Kadar Tehlikeliydi?

Durumu biraz açayım. Kubelet, her Kubernetes node’unda çalışan ve pod’ları yöneten temel bileşen. HTTPS üzerinden bir API sunuyor ve buradan pod listeleri, node metrikleri, container logları gibi şeylere erişebiliyorsunuz. Buraya kadar tamam. Ama aynı API üzerinden container içine exec yapabiliyorsunuz; yanı çalışan bir container’ın içine girip istediğiniz komutu çalıştırmak da mümkün.

Eski model nasıl işliyordu? Webhook authorization açıkken kubelet API’sının neredeyse büyük çoğunluk path’leri tek bir subresource’a map ediliyordu: nodes/proxy. Monitöring tool’unuz metrik okuyacak? Peki, nodes/proxy ver. Log toplayacak? nodes/proxy ver. Health check yapacak? Yine nodes/proxy. Biraz fazla toplu iş yapıyordu yanı.

Sorun şu: nodes/proxy izni aynı zamanda node üzerindeki herhangi bir container’da komut çalıştırma yetkisi de veriyor. Hani şöyle düşünün, evin bahçe kapısının anahtarını vermek istiyorsunuz ama o tek anahtar hem bahçeyi hem evi hem de kasayı açıyor. Least privilege prensibine baya ters bir durum (evet, doğru duydunuz)

Bir monitöring agent’ı ele geçiren saldırgan, nodes/proxy izni sayesinde o node’daki tüm container’larda keyfi komut çalıştırabilir. Bu, node seviyesinde superuser etkisine yakın bir yetkidir ve blast radius’u korkunç derecede geniştir.

İlginç olan şu ki, Geçen yıl bir finans kuruluşundaki Kubernetes güvenlik denetiminde tam olarak bunu konuştuk. Müşteri Prometheus agent’larına nodes/proxy vermişti. Ben “bu izin fazla geniş, daraltmamız lazım” dediğimde ekip “ama başka yolu yok ki” demişti. Haklıydılar; o zamanlar gerçekten başka yol yoktu. Şimdi var.

WebSocket ile Gelen RCE Riski: Sandığınızdan Daha Kötü

Ha bu arada, olay ilk bakışta göründüğünden daha sıkıntılıymış meğer. 2026 başında güvenlik araştırmacıları bir şey fark etti ki… Ben de şaşırdım açıkçası.

nodes/proxy GET, yanı sadece okuma izni, tek başına container içinde komut çalıştırmak için yeterli olabiliyor. Evet, yanlış okumadınız. Sadece GET izniyle remote code execution yapılabiliyor.

Nasıl Oluyor Bu?

WebSocket protokolü (RFC 6455) ilk bağlantıyı kurarken HTTP GET isteği kullanıyor. Kubelet bu GET’i RBAC içindeki get verb’üne map ediyor ve isteği onaylıyor. Ama WebSocket bağlantısı kurulduktan — itiraz edebilirsiniz tabi — sonra arkadan gelen yazma işlemi için ayrıca CREATE izni kontrol etmiyor. Yanı method mismatch var; sonuç da pek hoş değil.

Bir saldırgan websocat gibi bir WebSocket istemcisi kullanarak kubelet’in /exec endpoint’ine doğrudan bağlanabiliyor:

websocat --insecure \
--header "Authorization: Bearer $TOKEN" \
--protocol v4.channel.k8s.io \
"wss://$NODE_IP:10250/exec/default/nginx/nginx?output=1&error=1&input=1&command=whoami"

Bu komut, default namespace’indeki nginx pod’unda whoami çalıştırıyor. Sadece GET izniyle! İlk gördüğümde “hadi ya, bu kadar basit mi?” dedim (evet, doğru duydunuz). Maalesef öyle.

Tuhaf ama, Peki sonra ne öldü? Geçen ay Logosoft’ta bir müşterimizin staging ortamında bunu test ettik. Sonuç beklediğimiz gibi çıktı; gerçekten çalışıyor. Monitöring agent’ına verilmiş read-only nodes/proxy token’ı ile container’lara exec yapabildik. Ekip o gün biraz gerildi — haklılardı tabii.

Yeni Model: İnce Taneli Yetkilendirme Nasıl Çalışıyor?

Kubernetes v1.36 ile gelen fine-grained kubelet authorization, kubelet API’sının farklı endpoint’lerini ayrı RBAC subresource’larına map ediyor. Artık tek bir nodes/proxy yerine her işlem için ayrı izin tanımlayabiliyorsunuz.

Kubelet API Endpoint	Eski RBAC (v1.31 öncesi)	Yeni RBAC (v1.36+)
/metrics, /metrics/resource	nodes/proxy (get)	nodes/metrics (get)
/stats, /stats/summary	nodes/proxy (get)	nodes/stats (get)
/pods	nodes/proxy (get)	nodes/pods (get)
/healthz, /livez, /readyz	nodes/proxy (get)	nodes/healthz (get)
/configz	nodes/proxy (get)	nodes/configz (get)
/logs	nodes/proxy (get)	> nodes/log (get)
/exec, /attach, /portforward	> nodes/proxy (get)	> nodes/proxy (create) — eskisi gibi ama ayrıştırılmış

Gördünüz mü farkı? Artık Prometheus’a sadece nodes/metrics veriyorsunuz.
Log toplayıcıya sadece nodes/log .
Health checker’a sadece nodes/healthz .
Hiçbirine nodes/proxy vermenize gerek yok.
Exec yapma yetkisi ayrı kalıyor; işte asıl rahatlık burada.

ClusterRole Örneği

Diyelim ki sadece metrik okuma izni vermek istiyorsunuz.
Eskiden şu tehlikeli ClusterRole’u yazmak zorundaydınız:

# ESKİ — TEHLİKELİ
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: monitoring-agent-old
rules:
- apiGroups: [""]
resources: ["nodes/proxy"]
verbs: ["get"]

Dürüst olmak gerekirse, <!– NOTE –> Bu konuyla ilgili AI Agent’larda Sohbet Geçmişi: Nerede Saklamalı? yazımıza da göz atmanızı tavsiye ederim. Daha fazla bilgi için Gemini ile Hayatını Düzenle: 8 Yapay Zeka Destekli İpucu yazımıza bakabilirsiniz.

# YENİ — GÜVENLİ
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: monitoring-agent-new
rules:
- apiGroups: [""]
resources: ["nodes/metrics"]
verbs: ["get"]
- apiGroups: [""]
resources: ["nodes/stats"]
verbs: ["get"]}

Şöyle ki, <!– END –> Daha fazla bilgi için Axios npm Saldırısı: Azure Pipelines’ta Ne Yapmalı? yazımıza bakabilirsiniz.

Türkiye’deki Kurumsal Yapılar İçin Ne Anlama Geliyor?

Şimdi gelelim Türkiye tarafına.
Kurumsal müşterilerimde gördüğüm kadarıyla Türkiye’deki firmalar Kubernetes güvenliği konusunda genelde ikiye ayrılıyor.
Bir tarafta bankalar ve telekom şirketleri var; bunlar BDDK, SPK, BTK gibi kurumların baskısıyla güvenlikte daha temkinli davranmak zorunda.
Diğer tarafta e-ticaret, SaaS ve startup ekipleri var; hız öncelikli gidiyorlar ve güvenliği bazen “sonra bakarız” diye erteliyorlar.

Her iki kamp için de bu özellik önemli.
Neden mi?

Bankacılık sektöründe çalışan bir müşterimiz BDDK denetimine hazırlanırken “Kubernetes cluster’ınızda least privilege uyguluyor musunuz?” sorusuyla karşılaştı.
<snip>

<!– Göç Stratejisi –>

Şunu söyleyeyim, Tamam,[redacted]       

1.  Mevcut RBAC Audit’i Yapın

<redacted>
kubectl get clusterroles -o json | jq '.items[] | select(.rules[]? |.resources[]? == "nodes/proxy") |.metadata.name'
</redacted>

2.  Her Workload İçin İhtiyaç Analizi

3.  Kademeli Geçiş

Bunu daha önce benzer bir geçişte — hani
Ingress-NGINX Göçü:
5 Şaşırtıcı Davranış. Bu ne anlama geliyor? Çözümü
yazımda anlattığım gibi — aşamalı yapmak en güvenli yol.
Bir anda kesmek yerine paralel çalıştırıp sonra eski yapıyı retire etmek daha akıllıca.
Neyse uzatmayayım, konu belli — dürüst olayım, biraz hayal kırıklığı —

Ve işler burada ilginçleşiyor.

EEnterprise vs Startup: Farklı Senaryolar

Enterprise seviyede bir yapıdaysanız,
muhtemelen OPA Gatekeeper veya Kyverno gibi policy engine’ler kullanıyorsunuz.
Bu durumda yeni subresource’ları policy’lerinize de eklemeniz gerekecek.
Mesela “hiçbir namespace’de nodes / proxy izni verilemez” şeklinde bir constraint yazabilirsiniz —
bu artık mümkün ve mantıklı.

Küçük ekipseniz. 2-3 node’lük bir cluster yönetiyorsanız,
işiniz daha kolay.
Doğrudan yeni RBAC kurallarıyla başlayın.
Ama şunu söyleyeyim — bu küçük cluster’larda bile güvenlik ihmal edilmemeli.
Geçen ay bir startup’ta pentest yaparken,
staging cluster’ından production’a lateral movement yapılabildiğini gördük.
Sebebi?
Aşırı geniş
nodes / proxy
izinleri.
Startup diye gevşek davranmayın.

Şöyle ki,
Bir de maliyet boyutu var.
Azure’da AKS kullanıyorsanız ve Microsoft Defender for Containers aktifse,
aşırı geniş RBAC izinleri zaten uyarı üretiyor.
Bu uyarıları kapatmak yerine düzeltmek,
hem güvenlik hem de Defender maliyeti açısından daha verimli.
Sonuçta gereksiz alert’ler de para —
çünkü SOC ekibinin zamanını yiyor.

Ve işler burada ilginçleşiyor.

Kubernetes güvenliği konusunda daha detaylı bilgi için
Kubernetes’te Production Debug Güvenliği:
Rehber
yazıma da göz atmanızı öneririm. Bu konuyla ilgili Cosmos DB’de AI Maliyet Optimizasyonu: 7 Pratik İpucu yazımıza da göz atmanızı tavsiye ederim. Daha fazla bilgi için GitHub Pull Requests Dashboard: Herkes İçin Açılan Yeni Deneyim yazımıza bakabilirsiniz.

Eksikler ve Eleştirilerim

Bence, Her şey güllük gülistanlık mı?
Hayır.
Birkaç şey beni rahatsız ediyor.

Birincisi,
bu özelliğin GA olması çok uzun sürdü.
İlk issue 2019’da açılmış (
kubernetes/kubernetes#83465
),
KEP 2021’de yazılmış,
alpha 2024’te gelmiş,
GA 2026’da.
7 yıl!
Bu süre zarfında kaç cluster bu açıktan etkilendi,
bilemiyorum ama muhtemelen az değildir.

İkincisi —
feature gate kilitli olması iyi bir şey ama geriye dönük uyumluluk konusunda endişelerim var.
Eski
nodes / proxy
izinleri hâlâ çalışıyor mu?
Evet,
çalışıyor —
ama yeni subresource’lar da artık kontrol ediliyor.
Bu geçiş döneminde karmaşık RBAC senaryolarında beklenmedik davranışlar olabilir.
Hmm,
bir düşüneyim…
Evet,
özellikle custom admission webhook’larsanız dikkatli olun.

Üçüncüsü,
kubelet API güvenliği sadece RBAC ile çözülecek bir problem değil.
Network policy’ler,
pod security standards,
node isolation —
hepsinin birlikte ele alınması gerekiyor.
Bu özellik tek başına sihirli değnek değil,
ama önemli bir parça.
Bakın bir de şunu söyleyeyim:
Kubernetes’te AI Agent Sandbox:
Pratik Rehber
yazımda da benzer izolasyon konularına değinmiştim —
oradaki prensipler burada da geçerli.

}

Sıkça Sorulan Sorular

Fine-grained kubelet authorization’ı kapatabilir mıyım?

Hayır, kapatamıyorsun. Kubernetes v1.36’da KubeletFineGrainedAuthz feature gate’i kilitli — yanı her zaman açık geliyor. Bu artık GA bir özellik, aslında kapatma seçeneği de yok zaten. Mevcut RBAC kurallarını yeni modele göre uyarlamak gerekiyor.

Evet, doğru duydunuz.

Peki mevcut nodes/proxy izinlerim çalışmaya devam eder mi?

Evet, devam ediyor. Mevcut nodes/proxy izinleri (söylemesi ayıp) geriye dönük uyumlu çalışıyor, merak etme (ki bu çoğu kişinin gözünden kaçıyor) (bu beni çok şaşırttı). Ama bence güvenlik açısından bu izinleri yeni fine-grained subresource’lara (nodes/metrics, nodes/stats, nodes/log vb.) taşımak çok daha mantıklı — açıkçası bu adımı ertelemezdim.

AKS’te bu özellik ne zaman geliyor?

Size bir şey söyleyeyim, AKS, Kubernetes v1.36’yı desteklemeye başladığında otomatik olarak aktif olacak (evet, doğru duydunuz). Tecrübeme göre Microsoft’un Kubernetes sürüm desteği upstream release’den genellikle 1-2 ay sonra geliyor. AKS release notes’larını takip etmeni öneririm.

Bu değişiklik Prometheus ve Grafana kurulumumu etkiler mi?

Büyük ihtimalle evet. Prometheus kubelet’ten metrik çekiyorsa — ki çekiyordur — mevcut nodes/proxy izni artık yetmeyebilir. Yanı nodes/metrics ve nodes/stats izinlerini ayrıca tanımlaman gerekiyor. Helm chart’larındaki RBAC şablonlarını güncellemeyi de sakın atlama.

WebSocket exec açığı sadece kubelet’e doğrudan erişimde mi geçerli?

Bunu yaşayan biri olarak söyleyeyim, Evet, sadece kubelet’in 10250 portuna doğrudan erişimde geçerli (bizzat test ettim). API server üzerinden gelen exec istekleri zaten ayrı RBAC kontrollerinden geçiyor, hani orada sorun yok. Ama şunu da atlamayalım: node ağına erişebilen herhangi bir pod bu porta ulaşabiliyor — bu yüzden network policy’ler de bir o kadar kritik.

Kaynaklar ve İleri Okuma

Kubernetes Blog: Fine-Grained Kubelet API Authorization GA Announcement

KEP-2862: Fine-Grained Kubelet Authorization Enhancement Proposal

Microsoft Docs: AKS Security Concepts