Kubelet Fine-Grained Authorization GA: nodes/proxy Devri

Bana kalırsa burada kritik nokta şu: nodes/proxy neredeyse tamamen ortadan kalkmıyor. Evet, duruyor. Çünkü komut çalıştırma gıbı gerçekten node seviyesinde yetki isteyen işler hâlâ oradan geçiyor. Ama monitoring ve observability tarafı artık kendi dar alanına çekilebiliyor. Peki neden önemli? Çünkü geniş yetkiyi azaltıyorsun, sonra da “bir şey ölür mu” diye gece uykun kaçmıyor. Daha fazla bilgi için Ubuntu 26.04 ve .NET 10: Resolute Raccoon ile Yeni Dönem yazımıza bakabilirsiniz.

Böyle yazınca Prometheus için ne değişiyor?

Eskiden şöyle bir ClusterRole yazmak zorundaydık: (kendi tecrübem)

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: prometheus-old
rules:
- apiGroups: [""]
resources: ["nodes/proxy"] # 😱 her şey bu
verbs: ["get"]

Baya kaba bir çözümdü aslında. Çalışıyordu, evet. Biraz fazla genişti, hatta dürüst olayım, token yanlış ellere geçerse iş büyüyordu (özellikle de /exec, /run, benzeri kapılar aynı çatı altındayken). Neyse, şimdi v1.36 ile bunu daha temiz kurabiliyoruz:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: prometheus-scoped
rules:
- apiGroups: [""]
resources: ["nodes/metrics", "nodes/stats"]
verbs: ["get"]
# nodes/proxy YOK. /exec'e ulaşamıyor. RCE riski yok.

Evet, fark ince görünüyor. Ama etkisi öyle değil. Prometheus token’ı çalınsa bile saldırgan en fazla node metriklerini okuyabiliyor; container içinde komut çalıştırmaya kadar gidemez. Hani bazen “küçük değişiklik” dersin ya, işte burada küçük değil, baya anlamlı bir güvenlik sıkıştırması var (ciddiyim) Daha fazla bilgi için Azure MCP Server Artık MCPB Paketi: Runtime Derdi Bitti yazımıza bakabilirsiniz. Bu konuyla ilgili Gateway API v1.5: Stable’a Taşınan Özellikler ve Notlarım yazımıza da göz atmanızı tavsiye ederim.

Tam da öyle.

Türkiye’deki kurumsal yapılar açısından durum

Bunu Türkiye’deki şirketler tarafından düşününce, ilk aklıma finans, sigorta ve telekom geliyor (yanlış duymadınız). Çünkü bu alanlarda KVKK ve sektörel kurallar (BDDK, EPDK) yüzünden “least privilege” artık sadece güzel bir prensip değil, resmen denetim konusu. Ben geçen yıl bir telekom operatöründe iç denetim hazırlığı yaparken, monitoring stack’imizdeki nodes/proxy izni bayağı sorun çıkarmıştı; risk kabul formu doldurduk, uğraştık da uğraştık. Şimdi o form işi çöpe gidiyor gıbı, çünkü direkt çözüm var (ki bu çoğu kişinin gözünden kaçıyor)

Aslında — hayır dür, daha doğrusu, Logosoft’ta danışmanlık verdiğim müşterilerin çoğu hâlâ AKS 1.30-1.32 bandında geziyor. Yanı v1.36’ya geçiş (söylemesi ayıp) bir anda ölmüyor, biraz zaman alacak. Ama AKS Kubernetes versiyon roadmap’ine bakınca şunu görüyorsunuz: GA olan şeyleri Microsoft genelde 2-3 ay içinde production AKS tarafına taşıyor (tabi bazen ufak sürprizler de oluyor). O yüzden 2026 yaz aylarında AKS’te de görmeye başlayacağız bu özelliği diye düşünüyorum. Şimdiden hazırlanmak fena olmaz.

Kurumsal vs startup yaklaşımı

Küçük bir ekipseniz ve cluster’ınızda 10-15 node varsa, açık konuşayım, muhtemelen bu özelliği aktif kullanmanız gerekmeyecek. Çünkü monitoring agent’larınızın token işini yönetmek zaten çok zor değil; bir de network tarafında izolasyon kurunca olay büyük ölçüde kapanıyor. Standart Helm chart’larla idare edersiniz, hatta çoğu zaman hiç el sürmeden devam edersiniz.

Ve işler burada ilginçleşiyor.

Ama kurumsal yapıdaysanız — yanı 100+ node, çok takımlı cluster, üstüne regülasyon baskısı. Security team’in sürekli soru sorması varsa — iş değişiyor. Bu özellik burada baya iş görüyor. Helm chart’larınızın values.yaml dosyalarını tek tek kontrol edip RBAC bloklarını yeni subresource’lara göre elle güncellemeniz gerekecek; çünkü çoğu chart bunu henüz otomatik yapmıyor, neyse uzatmayalım.

Geçiş için pratik adımlar

İlk kurcaladığımda bir hata patladı, anlatayım: test cluster’ında v1.33 beta açıp Prometheus RBAC tarafını biraz fazla sıkılaştırmıştım, sonra /metrics/cadvisor endpoint’ine erişim 403 dönmeye başladı. Bir saat uğraştım; meğer nodes/metrics verb’ü için /metrics/cadvisor path’ını de kapsayan ekstra bir attribute kontrolü gerekiyormuş, yanı iş sandığımdan biraz daha ince ayarlıymış. Çözüm de kubelet authorization webhook’unu --authorization-mode=Webhook,Node ile birlikte düzgün konfigüre etmekti.

Lafı gevelemeden, geçişte ben olsam şu sırayla giderdim:

1. Inventory çıkarın. Hangı service account’lar nodes/proxy kullanıyor? Mesela kubectl get clusterrolebindings -o yaml | grep -B5 "nodes/proxy" ile başlayabilirsiniz; basit duruyor ama ilk tabloyu görmek çoğu zaman yarım işi çözüyor.
2. Her birini sınıflandırın. Bu agent gerçekten /exec‘e ihtiyaç duyuyor mu, yoksa sadece metrik mi okuyor? Çoğu yerde cevap “sadece metrik” oluyor, ama araya bir iki sürpriz de çıkabiliyor.
3. Test cluster’da deneyin. v1.36 öncesi bir cluster’da bile KubeletFineGrainedAuthz beta’da açıktı; yanı v1.33+ herhangi bir ortamda deneme yapabilirsiniz. Ben olsam önce küçük bir köşede denerim, sonra yayarım.
4. Aşamalı rollout yapın. Önce non-critical workload’lardan başlayın. DataDog gıbı büyük agent’ları sona bırakın; çünkü sorun çıkarsa en çok gürültüyü onlar yapıyor, açık konuşayım.
5. Audit log’ları izleyin. Geçiş sonrası 401/403 hatalarını yakından takıp edin. Burada küçük bir detay var: bazen hata sayısı az ölür ama etkisi beklediğinizden büyük olabilir, o yüzden gözünüz açık olsun.

Eğer henüz Kubernetes Prod Debug Güvenliği: JIT Erişim Rehberi yazımı okumadıysanız, JIT (Just-In-Time) erişim modelini fine-grained authorization ile yan yana kullanmak için iyi bir başlangıç noktası olabilir. İkisi birbirini güzel tamamlıyor dersem abartmış olmam sanırım; biri erişimi zamana bağlıyor, diğeri yetkiyi daraltıyor. Sonuçta elinizde daha kontrollü bir yapı kalıyor. GPT-5.5 Geldi: Gerçekten Daha Akıllı mı, Hype mı? yazımızda bu konuya da değinmiştik.

AKS özelinde bir not

Peki AKS tarafında durum ne? Azure Monitör for Containers (Container Insights) agent’ı şu anda nodes/proxy kullanıyor; yanı burada top tamamen Microsoft’ta. Bu davranışın güncellenmesi gerekiyor. Bekleyişimiz o yönde tabii, ama ben yine de “yarın kesin gelir” demem (ben de ilk duyduğumda şaşırmıştım). AKS preview kanallarında v1.36 görünmeye başladığında resmî dokümantasyonda da bir güncelleme göreceğiz gıbı duruyor — gözünüz orada olsun.

Maliyet ve operasyonel etki

Garip gelecek ama, Azure tarafında bu değişikliğin doğrudan bir maliyeti yok, sonuçta konuştuğumuz şey RBAC değişikliği. Ama işin bir de dolaylı yüzü var; TL bazında bakınca tablo biraz can sıkıyor, çünkü bir security incident’ın ortalama maliyeti Türkiye’de KVKK cezası dahil 2-5 milyon TL bandına çıkabiliyor (kaynak: 2025 IBM Cost of Data Breach raporu, MEA bölgesi). Cluster’ınızda 50+ pod varsa ve bunlardan biri PII işliyorsa, fine-grained authz’a geçiş bence baya sigorta primi gıbı duruyor. Bu konuyla ilgili Ingress’ten Gateway API’ye Geçiş: 1.0 Rehberi yazımıza da göz atmanızı tavsiye ederim.

Operasyonel tarafta işe olay öyle tek tıkla bitmiyor. Geçiş sırasında 1-2 hafta süren bir (belki yanılıyorum ama) “hardening sprint” planlamanız gerekecek; büyük cluster’larda bu süre uzayabiliyor, hatta bazen beklediğinizden daha fazla uzuyor. Ama bir kere yaptığınızda, audit raporlarında “least privilege uygulanıyor” diyebiliyor olmak güzel hissettiriyor, security team’inizle aradaki havayı da yumuşatıyor. İnanın, böyle küçük görünen şeyler bile fark yaratıyor.

Eksik kalan ne var?

Bilmem anlatabiliyor muyum, Kağıt üstünde her şey fena görünmüyor, ama işin içinde hâlâ birkaç pürüz var. Kısaca bakınca şunlar göze çarpıyor:

• Helm chart çevrei geride. Topluluk chart’larının çoğu hâlâ nodes/proxy kullanıyor. Bu durum 6-12 ay içinde toparlanır gıbı duruyor, ama o zamana kadar araya elle girmeniz gerekecek; yanı otomatik sandığınız yer bir anda yarı manuel çalışabiliyor. — ciddi fark yaratıyor
• Dokümantasyon biraz dağınık. KEP-2862, blog post ve resmî doküman arasında tam bir senkron yok. Hatta bazı subresource isimleri bir yerde başka, öbür tarafta başka geçiyor; insan “hangisi doğru şimdi?” diye kısa bir duraksıyor.
• WebSocket fix’i ayrı bir mesele. Fine-grained authz, nodes/proxy‘yi daraltıyor ama WebSocket handshake’ının GET olarak değerlendirilmesi sorunu yerinde duruyor. Yanı nodes/proxy GET verebileceğiniz alanlarda temkinli olun; bu kısım bence ayrı bir KEP başlığı bile ister.

Bence bu özellik doğru tarafa atılmış sağlam bir adım, ama eksik duran parça hâlâ WebSocket protokol-RBAC mapping konusu. SIĞ Auth bunu da çözerse, kubelet güvenliği baya daha modern bir seviyeye çıkacak; açık konuşayım, asıl rahatlama orada geliyor.

Şunu fark ettim: Neyse, çok dağıtmadan söyleyeyim: Kubernetes ekosistemindeki diğer güvenlik iyileştirmelerini de takıp ediyorsanız, SELinux Volume Label Değişiklikleri GA: v1.37’de Neler yazısı da işinize yarayabilir — bütüncül bir security baseline kurarken iyi gidiyor.

Sıkça Sorulan Sorular

Fine-grained kubelet authorization’ı kullanmak için ne yapmalıyım?

Kubernetes v1.36 cluster’ın varsa aslında bir şey yapmana gerek yok, özellik zaten varsayılan olarak açık geliyor (yanlış duymadınız). Tek yapman gereken şey şu: monitoring/log/health agent’larının RBAC’ını nodes/proxy‘den nodes/metrics, nodes/stats, nodes/log, nodes/healthz gıbı daha dar kapsamlı subresource’lara güncellemek. v1.33+ cluster’larda da KubeletFineGrainedAuthz feature gate’i açarak beta olarak deneyebilirsin.

Eski nodes/proxy izinli RBAC’larım çalışmaya devam edecek mi?

Şahsen, Evet, nodes/proxy hâlâ geçerli. Yanı backward compatibility konusunda sıkıntı yok. Hani /exec, /run gıbı komut çalıştırma endpoint’leri için zaten kullanılmaya devam ediyor. Peki bunu neden söylüyorum? Ama bence gerçekten exec yetkisine ihtiyaç duymayan workload’lardan bu izni kaldırman şart — least-privilege prensibi gereği açıkçası bunu ertelememeni tavsiye ederim.

AKS’te ne zaman kullanabileceğim?

v1.36 GA öldü, yanı AKS roadmap’ine göre 2-3 ay içinde preview kanallarında görmeye başlayabiliriz. Sonrasında stable AKS versiyonlarına geliyor. Bir de şu var: Microsoft’un Container Insights agent’ını da yeni subresource’larla uyumlu hâle getirmesi gerekiyor. Bu konuda resmî açıklamayı beklemekte fayda var, acele etme (kendi tecrübem)

WebSocket RCE riski tamamen ortadan kalktı mı?

Açıkçası hayır, tam olarak değil. Fine-grained authz, nodes/proxy‘nın kapsamını daralttığı için saldırı yüzeyini ciddi ölçüde azaltıyor — bu iyi bir şey. Ama mesela bir agent’a hâlâ nodes/proxy GET veriyorsan, WebSocket handshake üzerinden RCE riski teorik olarak durmaya devam ediyor. Bu konuda ayrı bir KEP çalışması devam ediyor, tecrübeme göre bu tür şeyler tamamen kapanmadan rahatlamak erken ölür.

Helm chart’larım eski izinleri kullanıyor, ne yapmalıyım?

Şu an çoğu popüler chart henüz güncellenmedi,. Prometheus, Loki, Fluent Bit gıbı araçları kullanıyorsan bu durumla karşılaşıyorsun. Geçici çözüm olarak chart’ın values.yaml‘ında extraClusterRoleRules veya benzeri bir alan varsa oradan yeni subresource’ları ekleyip eski nodes/proxy binding’ını manuel kaldırabilirsin. Upstream PR’ları takıp et, bence 6 ay içinde çoğu chart güncellenmiş olacak (kendi tecrübem)

Kaynaklar ve İleri Okuma

Kubernetes v1.36: Fine-Grained Kubelet API Authorization Graduates to GA — Resmî Blog

Dürüst olmak gerekirse, KEP-2862: Fine-grained Kubelet API Authorization

Kubernetes Resmî Dokümantasyonu: Kubelet Authentication & Authorization

GitHub Issue #83465: Original nodes/proxy Discussion