Kubernetes'ta escalate ve bind fiilleri RBAC yetki yükseltme korumalarını sessizce devre dışı bırakıyor

Kubernetes'taki rol tabanlı erişim kontrolü (RBAC) yerleşik bir güvenlik mekanizmasıyla gelir: API sunucusu normalde bir kullanıcının, o kullanıcının zaten sahip olmadığı yetkileri veren bir Role yazmasını reddeder. dev.to'da yayımlanan güncel bir teknik kılavuz, bu güvenlik mekanizmasını bilerek devre dışı bırakan iki fiile — escalate ve bind — dikkat çekiyor ve her ikisinin de verilmesinin kendi başına bir risk incelemesini hak ettiğini savunuyor.

Atlama mekanizması nasıl çalışıyor

Yazıda atıf yapılan Kubernetes dokümantasyonuna göre escalate, bir kullanıcının yazıcının mevcut haklarıyla karşılaştırma yapılmaksızın herhangi bir izni içeren roller oluşturmasına veya güncellemesine izin veriyor. bind ise bir kullanıcının, izinleri bağlayanın kendi izinlerini aşan bir role RoleBinding eklemesine olanak tanıyor. İkisinin de meşru kullanım alanları var: başkaları adına roller tanımlayıp atayan bir politika yöneticisi tam olarak bu yeteneklere ihtiyaç duyar. Sorun, yazarın belirttiği gibi, aynı fiillerin geniş bir gruba, bir uygulama kimliğine veya her operatöre verilen pratik bir role eklenmesini engelleyen bir şeyin olmamasıdır. Bu durumlarda görünüşte sınırlı bir namespace rolü, cluster yönetimine giden bir basamak taşına dönüşür.

Namespace sınırları bunu içeremez

Yazı, namespace izolasyonunun burada güvenilir bir kapsayıcı olmadığını açıkça belirtiyor. Pod oluşturma yetkisi olan bir service account, farklı ve daha ayrıcalıklı bir service account altında çalışan bir workload planlayabilir ya da daha fazla yetki taşıyan bir token mount edebilir. Admission webhook'larını veya API aggregation kontrollerini değiştirebilen biri, birçok namespace'te aynı anda davranışı etkileyebilir. Yazının atıf yaptığı Kubernetes RBAC iyi uygulamalar kılavuzu da escalate, bind, impersonate ve pod ya da service account'lar üzerindeki create izinlerini, etkileri tek bir namespace'i aşan izinler olarak işaretliyor. Yazarın vardığı sonuç şu: bir politikada adı geçen kaynak, risk analizinin yalnızca bir parçasıdır.

Halihazırda verilen yetkileri denetlemek

Önerilen başlangıç noktası bir envanter: RBAC kaynaklarında escalate, bind veya wildcard fiilleri taşıyan her Role ve ClusterRole, ardından bu rollere atıf yapan her RoleBinding ve ClusterRoleBinding. Her binding için subject'i, namespace'ini ve subject'in kaynağını kaydedin. Yazı, system:unauthenticated grubu ile varsayılan service account'ları, çoğu zaman kimsenin farkına varmadan geniş binding'ler alan subject'ler olarak öne çıkarıyor. Aggregated ClusterRole'lar ekstra inceleme gerektirir; çünkü aggregation controller kuralları etiketlerden toplar ve bir rolün etkili izin seti, görünen kural listesinin öne sürdüğünden daha büyük olabilir. Makale ayrıca RBAC kaynaklarında escalate ve bind birleştiren örnek bir ClusterRole gösteriyor; bunu önerilen bir atama değil, hassas bir örnek olarak sunuyor.

Ortaya çıkma penceresini daraltmak

Risk azaltma konusunda yazı, politikayı inceleme yeteneğini dağıtma yeteneğinden ayırmayı ve rol tanımlarının incelenen bir değişiklik sürecinden geçmesini öneriyor. Bir uygulamanın dağıtım sırasında gerçekten yükseltilmiş izinlere ihtiyacı olduğunda, tek bir amaca hizmet eden bir service account'a ve tek bir namespace içindeki özel bir role bağlayın, ardından dağıtım adımı tamamlandığında veriyi silin. Paylaşılan cluster-admin binding'leri bir başlangıç kısayolu olarak kullanılmamalıdır. Service account token'larının kendileri de ayrıcalıklı nesneler olarak ele alınmalıdır: platform bound projected token destekliyorsa audience ve ömürlerini sınırlayın ve başka bir hesabın kimlik bilgisini açığa çıkarabilecek secret okumalarını izleyin.

API sunucusuna karşı doğrulama

Doğrulama, yönetici bağlamından değil, fiili subject olarak ve ilgili kaynaklar, subresource'lar ve namespace'ler üzerinde kubectl auth can-i ile yapılmalıdır. Yazı, her hassas kurala sorulması gereken soruları listeliyor: subject, kendi sahip olmadığı kurallar içeren bir Role yazabilir mi, kullanamayacağı bir rolü bind edebilir mi, workload'ları daha güçlü bir service account altında başlatabilir mi, aggregated rolleri veya admission kontrol yollarını değiştirebilir mi. API sunucusu denetim kayıtları RBAC yazmalarını kapsamalı ve ClusterRole, RoleBinding ve ClusterRoleBinding değişikliklerinde uyarı vermelidir — özellikle çağıran tarafın normalde yalnızca workload'lara dokunuyorsa. Yazarın notuyla, ayrıcalıklı bir binding oluşturma girişimi reddedilse bile bu, keşif veya yanlış yapılandırmanın değerli bir kanıtıdır.

Neden önemli

Çoğu operatör, RBAC'ın yetki yükseltme önlemeyi sistemin sabit bir özelliği olarak görür; oysa belirli fiiller bunu sessizce devre dışı bırakır. escalate ve bind bir rol tanımında sıradan dizeler gibi göründüğünden, politika editörü rollerine, wildcard kurallarına veya pratik verilere kimsenin değişikliği işaretlemesi farkında olmadan sızabilir ve ortaya çıkan atlama, biri bunu kullanana kadar görünmez kalır. Bunları denetlemek ucuz ve mekaniktir; alternatifi ise — kendi cluster-admin izinlerini üretebilen bir uygulama kimliği — çok kiracılı bir cluster'ın yaşayabileceği en yıkıcı arızalardan biridir. Yazının pratik kuralı net: bu iki fiil az sayıda, açıkça adlandırılmış yönetici kimliğine aittir ve güncel bir operasyonel ihtiyaçla gerekçelendirilemeyen her binding kaldırılmalı ve uygulama yeniden test edilmelidir.