Kubernetes, bir kümedeki her işlemin neye erişebileceğini rol tabanlı erişim kontrolü (RBAC) ile belirler. Kubernetes RBAC yetki yükseltme, bu izin modelindeki gevşeklikleri ve tasarım tuzaklarını kullanarak sınırlı yetkili bir konumdan çok daha güçlü bir konuma, çoğu zaman kümenin tamamına hükmeden cluster-admin rolüne tırmanma sürecidir. Saldırının başlangıç noktası genellikle ele geçirilmiş tek bir konteynerdir.

Kubernetes RBAC yetki yükseltme, aşırı verilmiş roller ve zayıf yapılandırmalar üzerinden dar yetkili bir pod’dan kümenin tamamına hükmeden yönetici haklarına tırmanma sürecidir.

Tırmanış Nereden Başlar?

Bir pod içinde çalışan uygulamaya, varsayılan olarak bir hizmet hesabı belirteci (service account token) bağlanır. Saldırgan bir konteyneri ele geçirdiğinde ilk baktığı yer bu belirteçtir; çünkü o hesabın küme üzerinde hangi haklara sahip olduğu, tırmanışın rotasını belirler. Hizmet hesabına gereğinden fazla yetki verilmişse, saldırgan bu belirteçle API sunucusuna konuşarak yeni kaynaklar oluşturmaya, gizli bilgileri okumaya ya da başka hesapların belirteçlerine ulaşmaya başlar.

RBAC’ın kendine özgü tuzakları da bu tırmanışı besler. Örneğin bir kullanıcıya rol atama (bind) yetkisi verilmişse, o kullanıcı kendisine cluster-admin rolünü atayabilir; ya da gizli bilgileri (secrets) okuma izni, aslında başka bir hesabın belirtecini okuyup onun kimliğine bürünmeye açılan bir kapıdır. Bu ilişkiler, rol tabanlı erişim kontrolü modelinin ince ayrıntılarını bilmeyen ekiplerin gözünden kolayca kaçar.

Yaygın Tırmanış Yolları

• Fazla yetkili hizmet hesabı belirtecinin ele geçirilerek doğrudan API çağrılarında kullanılması
• Rol atama (bind/escalate) izninin kötüye kullanılarak kendine yönetici rolü verilmesi
• Gizli bilgi okuma izniyle başka hesapların belirteçlerine ulaşılması
• Ayrıcalıklı bir pod oluşturarak düğüm üzerindeki dosya sistemine ve kubelet’e erişilmesi

Bu yolların ortak noktası, hiçbirinin bir ‘açıktan’ değil, bilerek verilmiş ama fazla geniş izinlerden yararlanmasıdır. Bu yönüyle sorun, uygulama katmanındaki bozuk erişim kontrolü mantığının küme düzeyindeki karşılığıdır: yetki sınırının olması gerekenden geniş çizilmesi.

Nasıl Sınırlandırılır?

En etkili önlem en az ayrıcalık ilkesidir: her hizmet hesabına yalnızca işini yapmak için gereken izinler verilmeli, kullanılmayan varsayılan belirteçlerin pod’lara otomatik bağlanması kapatılmalıdır. Rol atama ve gizli bilgi okuma gibi ‘yükseltmeye açılan’ izinler çok dikkatli dağıtılmalıdır. Bu denetimlerin düzenli aralıklarla gözden geçirilmesi, geniş bir Kubernetes güvenliği programının vazgeçilmez bir parçasıdır.

Bir kümenin gerçek dayanıklılığı ancak saldırganın gözüyle sınandığında ortaya çıkar: ele geçirilmiş bir pod’dan yola çıkıp cluster-admin’e ulaşan bir yol var mı? Bu soru, uygulamalardan bulut altyapısına uzanan genel yetki yükseltme riskinin küme özelindeki halidir ve Privia’nın red team hizmeti bu tırmanış yollarını kontrollü biçimde çıkararak yapılandırma zayıflıklarını görünür kılar.