Yetki grupları

Kişisel bağlama tek bir kişiye tek bir Kubernetes kimliği atar; RBAC'in kendisini yine elle, cluster'da yazarsınız. Yetki grubu ise ön seçimli bir Kubernetes yetki kümesini (Secret okuma, exec/shell, redeploy, iş yükü oluşturma/silme, node işlemleri…) tanımlar, bunu bir ya da birden çok namespace'e kapsar ve arayüzdeki "RBAC'ı oluştur" düğmesiyle kümede gerçek RBAC nesneleri üretir. Gruba atanan kişiler bu RBAC ile yetkilenir.

Yetki kararının kendisi her zaman kümede kalır — grup bir kısayoldur, RBAC'in yerini alan ikinci bir yetki kaynağı değil (bkz. Sınırlar).

Yetkiler

Yetkiler aile aile gruplanır: Görünürlük, Kod çalıştırma, İş yükü ve yapılandırma, Node ve küme. Kod çalıştırma ailesindeki herhangi bir yetki (kabukla bağlanma, geçici hata ayıklama konteyneri, Job/CronJob çalıştırma, iş yükünü düzenleme ya da oluşturma) grubu daha fazla daraltılamayan bir sınıfa sokar: kod çalıştırabilen bir grup, o kodun okuyabildiği her şeyi zaten okuyabilir. Log ayrı bir yetenek değildir — tek okuma tabanı Kubernetes'in view agregasyonudur ve log akışını içerir.

Kapsam

Bir ya da birden çok namespace, ya da "Tüm namespace'ler". Küme kapsamlı nesneler (node, PersistentVolume, CustomResourceDefinition, namespace'in kendisi) namespace kapsamının DIŞINDA kalır: seçiliyse, seçili-namespace kipinde bile ayrı bir küme-geneli bağlamayla verilir. Sistem namespace'leri (kube-system ve benzerleri) kapsama hiç giremez.

Üyeler

YEKE kullanıcısı ya da dizin grubu eklenir. Bir üye, grubun yetkisini yalnızca grup bir kümeye UYGULANDIKTAN sonra kazanır — uygulanana kadar üyeliğin etkisi yoktur. admin rolündeki bir kullanıcı gruba eklendiğinde admin yetkisi grupla DARALTILMAZ; ekran bunu ayrıca uyarır.

Küme durumu

Kümedeki gerçek durumun ölçümü ve "RBAC'ı oluştur / güncelle" düğmesi yalnızca kümenin owner'ındadır — grup tanımı ve üyelik her admin'e açıkken, kümeye uygulamak owner'a özeldir. Bu sekme uygulanmış/bekliyor/kayma/hata durumunu ve varsa sürüklenmeyi (istenen RBAC ile kümede ölçülen arasındaki fark) gösterir.

Kayıt, kümeye uygulamak değildir. Yetkiler ya da Kapsam sekmesinde bir değişiklik kaydedince ekran otomatik olarak Küme durumu sekmesine geçer ve kapanmayan bir uyarı gösterir: kapsanmış bir küme varsa "Değişiklik kaydedildi ama kümeye henüz uygulanmadı — kümede eski yetkiler geçerli. RBAC'ı güncelleyin.", henüz hiçbir kümede yürürlükte değilse "Grup henüz hiçbir kümede yürürlükte değil — yetkiler, RBAC kümeye uygulanınca geçerli olur." RBAC'ı yalnızca owner uygulayabilir; owner değilseniz uyarı yine görünür.

• Bir özne. Grup kümede yeke:g:<slug> adlı bir Group öznesi olarak var olur.
• Ana rol ve ek roller. yeke:g:<slug> için ana rol (Kubernetes'in view agregasyonu + seçilen ek kurallar); küme kapsamlı kurallar üçüncü bir role gider ve o rol HER ZAMAN bir ClusterRoleBinding ile bağlanır — namespace kapsamlı kalan kurallardan bağımsız olarak.
• Namespace başına bağlama. Seçili-namespace kipinde her namespace kendi RoleBinding'ini alır; "Tüm namespace'ler" kipinde tek bir ClusterRoleBinding yeterlidir.
• Secret anahtar yeteneği seçiliyse ikinci bir özne. Kümede ayrıca yeke:gs:<slug> ve ona bağlı, tek kurallı bir rol üretilir; bu özne yalnız YEKE'nin Secret ekranında, yalnız o istek için bürünülür (aşağıda).
• Yazma yine TEK yoldan geçer. Dry-run → onay kartı → apply — yöneticinin KENDİ kimliğiyle. Agent'ın ServiceAccount'ı bu yazma yoluyla RBAC yazma yetkisi kazanmaz.

Enterprise — secret-keys (E6, "Erişim ve Secret yönetimi"). Bu yetenek 0.58.0'a kadar bayraksız, yani Community'de ücretsizdi. Bu sürümden itibaren gruba EKLEMEK ve yeteneği taşıyan bir grubun RBAC planı (oluşturma/güncelleme) lisans ister; yeteneği ÇIKARMAK ve grubun RBAC'ını kaldırmak lisans istemez. Yetki gruplarının temeli — tanım, üyelik, şablon, namespace kapsamı, RBAC üretimi — Community'de kalmaya devam eder.

Bir grup Secret anahtar yeteneğini taşısa bile ana özne (yeke:g:<slug>) kümede Secret için hiçbir RBAC kuralı almaz. Kural ikinci özneye (yeke:gs:<slug>) gider ve o özne yalnızca YEKE'nin Secret ekranındaki istekler için, yalnızca o istek boyunca bürünülür. Kümenin genel yollarında (kaynak tarayıcısı, tarayıcı kabuğu, izleme/watch, AI araçları) aynı kullanıcı Secret için yine 403 alır.

Kuralları yazan yer Erişim sekmesidir: grubun namespace kapsamındaki her Secret için anahtar × grup bir matris çizer, her hücre tek tek işaretlenir:

Matrisin "Tüm anahtarlar" satırı o grup için o an listede olan bütün anahtarları tek seferde aynı düzeye çeker — bu bir joker DEĞİLDİR: sonradan eklenen bir anahtar yine "Gizli" başlar, "Tüm anahtarlar" satırını yeniden kaydetmek gerekir.

Grup düzeyi joker kurallar: Secret kuralları

Gerçek bir joker, matriste DEĞİL, Kapsam sekmesindeki küme kartının "Secret kuralları" bölümündedir — kural küme başınadır ve yalnız o kümedeki kapsamın içinde geçerlidir. Namespace, Secret adı ve anahtar için * yazılabilir, yalnız SONEK olarak: namespace "Tüm namespace'ler" ise Secret ve anahtar alanı da kapanır; Secret "tüm Secret'lar" ise anahtar alanı kapanır. "Kapsamdaki bütün Secret'lar:" ön ayarı grubun varsayılan düzeyini tek satırda belirler.

Öncelik anahtar > Secret > namespace > grup varsayılanı — grubun İÇİNDE en özgül kural kazanır, seviyeden bağımsız: grup varsayılanı "Düzenler" olsa bile tek bir anahtara yazılan "Gizli" o anahtarı kapatır. Gruplar ARASINDA ise en geniş seviye kazanır — bir üye birden çok grubun üyesiyse, bir grubun "Gizli"si başka bir grubun verdiği "Görür"ü geri almaz. "Gizli" artık açıkça yazılabilir; yalnız bir joker kuralı daraltmak için. Kapsam dışındaki bir namespace'e joker yazımı reddedilir.

Bir üye, kuralı olan bir Secret'ı açtığında YEKE'nin Veri sekmesinde anahtar–değer tablosunu görür: "Görür" ya da "Düzenler" işaretli anahtarların değeri satır başına Göster/Kopyala ile açılır, "Gizli" işaretli anahtarın yalnız parmak izi görünür. "Düzenler" yetkisi olan bir anahtarda değişiklik yine "Yeni değer" alanıyla bir plan oluşturur ve onay kartından geçer — üyenin kendisi kümeye doğrudan yazmaz.

Bu düzeyler kurulum çapındaki Secret görünürlüğü tavanıyla (YEKE_SECRET_DISPLAY) BİRLİKTE uygulanır, onun yerine geçmez: etkin görünürlük ikisinin daha kısıtlayıcı olanıdır — bu grupta bir anahtar "Görür" işaretli olsa bile tavan masked/hiddenken değer maskeli kalır ve Veri sekmesinde Göster/Kopyala çizilmez. Aynı sınır Secret sürümlerinden geri yüklerken de geçerlidir: "Düzenler" erişimiyle geri yükleme yalnız VAR OLAN bir anahtarın değerini değiştirebilir.

Erişim matrisinde miras hücreler

Bir anahtarın bu Secret'a özel bir kuralı yoksa, matris hücresi grubun Secret kurallarından düşen en özgül jokeri kesikli çerçeveyle gösterir — hücre SEÇİLİ değildir, yalnız hangi düzeyin şu an geçerli olduğunu söyler. Miras kaynağı Secret kuralı, namespace kuralı ya da grup varsayılanı olabilir; jokeri olmayan grupta hücre boş kalır ve anahtar "Gizli" başlar. Kesikli hücrede bir düzey seçmek bu anahtara ÖZEL, ayrı bir kural yazar — miras zincirini değiştirmez.

• RBAC yasak koymaz, yalnız ekler. Yetki grupları kümeye yeni bir kısıtlama katmanı değildir; verdiği her şey gerçek bir RBAC nesnesidir ve kümenin kendi kararına tabidir — bir grubu kapatmak apiserver'ın zaten verdiği bir izni geri alan ikinci bir yasak üretmez.
• admin rolü gruba üyelikle daraltılamaz. Kişisel bağlama gibi, admin de yetki grubu ekseninin dışındadır.
• Redeploy ile imaj değiştirme RBAC'te ayrılamaz. İş yükünü düzenleme yeteneği ikisini de aynı yazma kuralı üzerinden verir; biri açıkken öteki kapatılamaz.
• Kod çalıştırabilen bir grupta anahtar gizlemesi bir sınır değildir. Grup kabukla bağlanma, geçici hata ayıklama konteyneri, Job/CronJob çalıştırma ya da iş yükü düzenleme/oluşturma taşıyorsa, pod'un içinden çalışan kod bağlı her Secret'ı zaten okuyabilir — ekran bu birleşimi katlanamaz bir uyarıyla gösterir, kaydı reddetmez.