Kubernetes RBAC Güvenlik Açıkları Tüm Kümeyi Ele Geçirme Tehlikesi

1. Kubernetes RBAC Mimarisi ve Kritik Önemi

RBAC, Kubernetes’in temel yetkilendirme modüllerinden biridir. API sunucusuna gelen her istek, ister kubectl komutu olsun ister programatik API çağrısı ya da pod içinden yapılan bir bağlantı, önce kimlik doğrulamasından geçer. Ardından RBAC karar mekanizması devreye girer. Bu yapı Role, ClusterRole, RoleBinding ve ClusterRoleBinding nesneleri üzerinden çalışır. Role namespace bazlı izinleri, ClusterRole küme geneli izinleri, binding yapıları ise bu izinlerin kullanıcı, grup veya servis hesabına bağlanmasını sağlar.

Konteyner teknolojileri yaygınlaştıkça Kubernetes yalnızca web uygulamaları için değil, üretim tesislerinden kamu sistemlerine kadar birçok kritik iş yükü için kullanılmaya başladı. Bu nedenle RBAC hataları sadece teknik bir açık olarak değerlendirilmemelidir. Örneğin üretim hattını yöneten bir pod’a yetkisiz erişim, veri ihlalinin ötesinde fiziksel operasyonları da etkileyebilir. Bu nokta çoğu zaman gözden kaçıyor; Kubernetes güvenliği yalnızca cluster ayakta mı sorusuyla ölçülemez. Düzenli sızma testi hizmetleri bu nedenle RBAC izinlerini, servis hesaplarını ve yetki zincirlerini birlikte ele almalıdır.

Kubernetes API’sinin arka planında etcd veri deposu bulunur. RBAC, kullanıcıların ve servis hesaplarının bu kaynaklara hangi kapsamda erişebileceğini belirler. Ancak aşırı yetkili bir rol, secret’ların okunmasına, pod oluşturulmasına veya node seviyesinde işlem yapılmasına izin verebilir. Gerçek bir saldırıda süreç genellikle düşük yetkili bir servis hesabıyla başlar. Ardından yanlış yapılandırılmış RBAC kuralları incelenir ve yetki yükseltme yolları aranır. Burada en sık yapılan hata, “read-only” gibi görünen yetkilerin saldırı zincirinde nasıl kullanılabileceğini hesaba katmamaktır.

2. Beş Ölümcül Yanlış Yapılandırma Vektörü

Aşağıdaki tabloda, Red Team operasyonlarında sıkça sömürülen beş RBAC hatası ve her birinin teknik etkisi özetlenmiştir. Bu hataların önemli kısmı, geçici çözüm amacıyla verilen fazla yetkilerden veya varsayılan servis hesaplarının unutulmasından kaynaklanır. Pratikte bu durum genelde şöyle karşımıza çıkar: sorun bilinerek açılır, ancak kapatılması kimsenin sorumluluğunda kalmaz.

Vektör 1: Aşırı Yetkili Servis Hesapları
Her namespace’te varsayılan bir “default” servis hesabı bulunur. Bu hesaba yüksek yetkili bir RoleBinding veya ClusterRoleBinding atanırsa, o namespace içinde çalışan her pod bu yetkilerle hareket edebilir. Saldırgan pod’a eriştiğinde /var/run/secrets/kubernetes.io/serviceaccount/token yolundaki token’ı okuyarak API sunucusuna aynı yetkilerle komut gönderebilir. Burada en sık yapılan hata, monitoring veya CI/CD gibi operasyonel namespace’lere fazla güvenmektir. Test kolaylığı için verilen cluster-admin yetkisi, yıllarca fark edilmeden kalabilir.

Vektör 2: Pod Oluşturma Yetkisi ile Token Çalma
Bir kullanıcıya “create pods” ve “get pods” yetkisi verildiğinde, yüksek yetkili servis hesabını kullanan yeni bir pod oluşturması mümkün olabilir. Saldırgan önce hedef namespace içinde servis hesaplarını inceler, ardından daha yüksek yetkili bir ServiceAccount tespit eder. Bu hesabı kullanan bir pod manifest’i oluşturur ve pod ayağa kalktığında token’ı okumaya çalışır. Elde edilen token ile API sunucusuna çok daha geniş yetkilerle istek gönderebilir. Bu vektörün etkisi, kapsamlı penetrasyon testi çalışmaları sırasında mutlaka doğrulanmalıdır.

Vektör 3: RBAC Kaynaklarını Değiştirme (bind/escalate)
Kubernetes’te “bind” fiili, kullanıcının rol bağlamaları oluşturmasına izin verir. “Escalate” fiili ise mevcut rolün yetkilerini artırmaya kapı açar. Bu iki yetkiden biri yanlış kişiye veya servis hesabına verilirse, saldırgan kendisini cluster-admin rolüne yaklaştıracak RoleBinding veya ClusterRoleBinding oluşturabilir. Pratikte bu durum genelde şöyle karşımıza çıkar: özel oluşturulan bir rol, güvenli olduğu düşünülerek yayına alınır ama içinde bind ya da escalate yetkisi unutulur.

Vektör 4: Joker Karakter (*) Kullanımı
Kubernetes RBAC’ta resources ve verbs alanlarında kullanılan “*” karakteri, mevcut ve ileride eklenecek kaynaklar için geniş bir yetki anlamına gelir. Örneğin bir ClusterRole tanımında “resources: [“*”]” ve “verbs: [“*”]” varsa, bu rol secrets, pods, nodes ve custom resource definitions dahil çok geniş bir alanda işlem yapabilir. Bu durum çoğu zaman admin yetkisine oldukça yakındır. Bu nokta çoğu zaman gözden kaçıyor; wildcard yalnızca bugünkü kaynakları değil, yarın eklenecek kaynakları da kapsayabilir.

Vektör 5: Kimliğe Bürünme (Impersonate)
“Impersonate” yetkisi, bir kullanıcının API isteklerinde başka bir kullanıcı veya grup adına hareket etmesini sağlar. Bu özellik denetim ve hata ayıklama için kullanılabilir. Ancak geniş gruplara verilirse ciddi bir yetki yükseltme yoluna dönüşür. Örneğin “system:authenticated” gibi geniş bir gruba impersonate yetkisi tanımlanırsa, saldırgan farklı kimliklerle hareket etmeyi deneyebilir. Burada en sık yapılan hata, impersonate yetkisini operasyonel kolaylık için açıp denetim kapsamına almamaktır.

3. Gerçek Dünya Vaka Analizleri ve Sızma Testi Araçları

Vaka 1: Büyük bir lojistik firmasında RBAC ihlali
2023 yılında gerçekleştirilen bir sızma testinde, müşterinin Kubernetes kümesinde geliştirme namespace’i içinde yer alan “default” servis hesabının cluster-admin’e bağlı olduğu tespit edildi. Senaryo kontrollü şekilde ilerletildi. Önce zafiyetli bir web uygulaması üzerinden pod içinde komut çalıştırma yetkisi alındı. Ardından servis hesabı token’ı okunarak API sunucusuna cluster-admin yetkisiyle erişildi. Bu erişimle tüm namespace’lerdeki secret’lar görüntülenebildi, yeni yüksek yetkili pod’lar oluşturulabildi ve kripto madenciliği senaryosu simüle edildi. Burada en sık yapılan hata, geliştirme ortamındaki gevşek yetkilerin üretimle aynı cluster üzerinde bulunmasını normal kabul etmektir.

Vaka 2: Bir kamu kurumunda wildcard yetkisi
Bir kamu bilişim merkezinde yapılan penetrasyon testinde, ön muhasebe uygulamasının çalıştığı namespace içinde bir Role tanımında “resources: [“*”]” ve “verbs: [“*”]” kullanıldığı görüldü. İlk bakışta bu yetki yalnızca ilgili namespace ile sınırlı görünüyordu. Ancak daha sonra bu Role’ün geniş bir kimlik grubuna bağlandığı anlaşıldı. Bu yapı, kuruma giriş yapan birçok kullanıcının söz konusu namespace üzerinde tam kontrole sahip olması anlamına geliyordu. Pratikte bu durum genelde şöyle karşımıza çıkar: yetki namespace ile sınırlı sanılır, ancak bağlı olduğu kimlik grubu fazla geniştir.

Sızma Testinde Kullanılan Araçların Karşılaştırması
Aşağıdaki tabloda, RBAC zafiyetlerini tespit etmek için kullanılan temel araçların yetenekleri karşılaştırılmıştır. Otomatik araçlar hızlı görünürlük sağlar; ancak etki doğrulaması ve gerçek saldırı zinciri için manuel değerlendirme gerekir.

Bu araçların yanında yapay zeka destekli saldırı simülasyon ajanları da RBAC analizlerinde kullanılmaya başladı. Örneğin bir ajan, RBAC politikalarını okuyarak en kısa ayrıcalık yükseltme yolunu önerebilir. Yine de gerçek ortamda en etkili sonuç, otomatik analiz ile manuel testin birlikte yürütülmesiyle alınır. Bu tür çalışmalar, geniş kapsamlı Red Team operasyonları içinde daha gerçekçi saldırı senaryolarıyla desteklenmelidir.

4. NIST, ISO 27001 ve KVKK Uyumunda RBAC’nin Yeri

Kubernetes RBAC güvenliği yalnızca teknik bir kontrol değildir. Aynı zamanda yasal uyum, erişim yönetimi ve denetlenebilirlik açısından da kritik bir başlıktır. Türkiye’de faaliyet gösteren kamu kurumları, üretim tesisleri ve özel sektör kuruluşları için KVKK ve uluslararası standart denetimlerinde RBAC yapılandırması sıkça gündeme gelir. Bu nokta çoğu zaman gözden kaçıyor; RBAC hatası yalnızca cluster problemi değil, aynı zamanda denetim bulgusudur.

NIST SP 800-207 (Zero Trust Mimarisi)
NIST’in Zero Trust yaklaşımı, “asla güvenme, her zaman doğrula” prensibiyle çalışır. Kubernetes RBAC, bu prensibin uygulanmasında temel mekanizmalardan biridir. Her servis hesabı, pod ve kullanıcı için en az ayrıcalık ilkesi işletilmelidir. RBAC hataları, Zero Trust yaklaşımının doğrudan ihlali anlamına gelir. NIST’in Kubernetes güvenliğiyle ilgili referanslarında RBAC’nin düzenli denetlenmesi, aşırı yetkili rollerin taranması ve binding’lerin periyodik olarak gözden geçirilmesi önerilir.

ISO 27001 Ek A Kontrolü A.9 (Erişim Kontrolü)
ISO 27001:2022’nin erişim kontrolüyle ilgili hükümleri, ayrıcalıklı erişim haklarının sınırlandırılmasını ve düzenli gözden geçirilmesini gerektirir. Kubernetes ortamında bu, cluster-admin gibi kritik yetkilerin iş gerekliliğiyle açıkça ilişkilendirilmesi anlamına gelir. Ayrıca erişim hakları belgelenmeli, periyodik olarak test edilmeli ve gereksiz yetkiler kaldırılmalıdır. Burada en sık yapılan hata, RBAC tanımlarını YAML dosyası olarak saklayıp gerçek ortamda neye karşılık geldiğini düzenli ölçmemektir.

KVKK ve Veri Sorumlusunun Yükümlülükleri
KVKK’nın 12. maddesi, kişisel verilerin güvenliği için uygun teknik ve idari tedbirlerin alınmasını zorunlu kılar. Kubernetes kümesinde RBAC hatası nedeniyle yetkisiz bir kişinin secret’lara, veritabanı bağlantı bilgilerine veya kişisel veri içeren pod loglarına erişmesi, veri ihlali riski doğurabilir. Bu nedenle RBAC denetimi, KVKK uyumluluğunun teknik güvenlik tarafında önemli bir kontrol alanıdır. Pratikte bu durum genelde şöyle karşımıza çıkar: kişisel veri uygulama içinde korunur, ancak o veriye erişim sağlayan secret geniş yetkili hesaplar tarafından okunabilir.

Remediation Stratejileri ve Nesil Teknoloji Çözümleri
RBAC hatalarını düzeltmek için şu adımlar uygulanır:

• Otomatik RBAC tarayıcı ile mevcut rollerin ve bağlamaların envanteri çıkarılır.
• En az ayrıcalık ilkesine göre yeni roller tanımlanır. Örneğin bir CI/CD aracı için yalnızca ihtiyaç duyduğu namespace ve kaynaklara yönelik sınırlı rol oluşturulur.
• Varsayılan servis hesapları “automountServiceAccountToken: false” yaklaşımıyla yeniden yapılandırılır.
• OPA Gatekeeper kullanılarak RBAC politikaları kod haline getirilir ve admission control ile ihlaller engellenir.
• Düzenli aralıklarla kapsamlı sızma testi yapılır.

RBAC hardening çalışmaları, yalnızca tek seferlik düzeltme olarak görülmemelidir. Yeni namespace’ler, yeni servis hesapları ve yeni CI/CD süreçleri eklendikçe yetki haritası değişir. Bu nedenle Kubernetes güvenliği, kurumsal siber güvenlik hizmetleri içinde sürekli izlenen bir başlık olarak ele alınmalıdır.

Sık Sorulan Sorular