Yetkilendirme ve RBAC

  YEKE kullanıcısı            YEKE'nin kimlik eşlemesi        apiserver
  ────────────────            ───────────────────────        ─────────
  deniz (rol: admin)   ──►    Impersonate-User: deniz@…  ──►  RBAC karar verir
                              Impersonate-Group: yeke:cluster-admins

Hiçbir istek agent'ın kendi kimliğiyle gitmez. Agent bir taşıyıcıdır; isteğe bürünme başlığı ekler ve kararı apiserver verir. Bu bir yapılandırma tercihi değil, üründe tip düzeyinde zorlanan bir değişmez: kimliksiz bir istek core'dan çıkamaz.

Cluster kuralı — herkes

Bir şablon ve sabit bir grup kümesi. Şablonda tanınan iki değişken var: {user.username} ve {user.email}; fonksiyon ve koşul yoktur.

kullanıcı adı şablonu :  {user.username}@ornek.com
sabit gruplar         :  yeke:cluster-admins

Cluster başına en fazla bir kural olur.

Kişisel bağlama — tek kişi

Kuralı ezer ve kişinin YEKE rolünden bağımsızdır: rol değişse bile bağlama aynen geçerli kalır. Kaydederken YEKE apiserver'a sorar ve cevabı satırda gösterir; o yüzden yanlış yazılmış bir ad kayıt anında görünür, ilk operasyonda değil.

Bağlama yazabilen kişi, bürünülebilen her kimliği dağıtabilir. Ekran bunu açıkça yazıyor. Tek istisna: system:masters hiçbir koşulda kabul edilmez — hem YEKE tarafında hem üretilen agent manifestinde ayrı ayrı reddedilir.

Aynı yetkiyi çok sayıda kişiye tekrar tekrar bağlamak yerine tanımlamak isterseniz Yetki grupları sayfasına bakın: arayüzden ön seçimli bir yetki kümesi kurulur, namespace'lere kapsanır ve tek düğmeyle kümede RBAC üretilir.

1Cluster'da RBAC'i yazın

Bu adımı YEKE yapmaz ve yapmaması bilinçlidir: yetki cluster'ın kendi kaydıdır, YEKE ele geçse bile oradan genişletilemez.

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: odeme-nobet
  namespace: odeme
rules:
  # Görebilmek için okuma — ölçeklemek için önce listeyi görmek gerekir.
  - apiGroups: ["apps"]
    resources: ["deployments"]
    verbs: ["get", "list", "watch"]
  # Ölçekleme ALT KAYNAK üzerinden; `deployments` üzerinde `update` VERİLMİYOR,
  # yoksa imaj, env ve prob'lar da değiştirilebilir olurdu.
  - apiGroups: ["apps"]
    resources: ["deployments/scale"]
    verbs: ["get", "update", "patch"]
  # Sonucu görebilmek için pod okuma (opsiyonel ama pratikte gerekli).
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: odeme-nobet
  namespace: odeme
subjects:
  # Buradaki ad, YEKE'de yazacağınız bağlamanın ADIYLA birebir aynı olmalı.
  - kind: User
    name: nobet@ornek.com
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: odeme-nobet
  apiGroup: rbac.authorization.k8s.io

kubectl apply -f odeme-nobet.yaml

2YEKE'de kişisel bağlamayı yazın

Cluster → Kimlik → ilgili kullanıcının satırı:

Kaydet ve doğrulaya bastığınızda satırda apiserver'ın döndüğü kimlik belirir. Belirmiyorsa bir şey tutmamıştır: ad yanlış yazılmış ya da bürünme tavanı o adı kapsamıyordur.

3Tavanı kontrol edin

Agent Kısıtlı moddaysa, bürünülebilecek adlar manifestin içindeki listeyle sınırlıdır. Yeni bir ad kullanacaksanız o listeye eklenmesi ve manifestin yeniden uygulanması gerekir. Tam erişim modunda kullanıcı adı ekseninde tavan yoktur; yeni bir grup kullanacaksanız yine manifest yenilenmelidir.

Doğrulama tahminle değil ölçümle: nöbetçi kullanıcıyla girip odeme dışında bir namespace'te bir yazma deneyin. Beklenen sonuç, planın apiserver tarafından reddedilmesi.

Rol değişimi anında yansır: ikinci bir kayıt yoktur, kimlik her istekte güncel rolden çözülür. Kişisel bağlaması olan kullanıcı bundan etkilenmez.

Politika requireSecondApproval istediğinde onaycılar yeniden belirlenir. Onaycı; plan sahibinden farklı, aktif ve o cluster’da kimliği eşlenmiş bir kullanıcı olmalıdır. requiredApproverGroup varsa bu gruba üyelik de gerekir. YEKE rolünün admin olması şart değildir. Uygun onaycı yoksa uyarı plan hazırlanırken gösterilir. Çift onay ayrıntıları →

Doğrudan modda, kubeconfig'in kimliği apiserver'da tanınıyor ama hiçbir role bağlı değilse ekranda bir düğme belirir. Bastığınızda YEKE bir plan kurar; plan tek bir nesne yaratır:

ClusterRoleBinding/yeke-kubeconfig-user
  subjects: [ User/<kubeconfig kullanıcısı> ]
  roleRef:  ClusterRole/cluster-admin

• Yalnız doğrudan modda görünür. Agent modunda hiç çıkmaz.
• Yalnız yöneticiye görünür; endpoint de aynı kontrolü ayrıca yapar.
• Onay kartından geçer ve çıtası yükseltilmiştir: kaynağın adını yazmanız istenir. YEKE'nin kendi düğmesi de kendi guardrail'inden muaf değildir.
• Verdiği yetki cluster-admin. Daraltmak istiyorsanız yol yukarıdaki örnektir, bu düğme değil.

• YEKE'nin namespace/kaynak ACL'i yoktur. "Bu kullanıcı yalnız şu namespace'i görsün" ayarı aramayın; o karar Kubernetes'in ve cevabı RBAC'tir.
• YEKE cluster'a RBAC yazmaz. Tek istisna yukarıdaki düğmedir: tek nesne, sabit ad, yalnız doğrudan modda, yalnız onaydan geçerek.
• Guardrail politikaları sıkılaştırır, gevşetmez. Bir planı durdurabilirler ama kimseye yetki veremezler; RBAC'in yerine geçmezler.
• system:masters hiçbir yoldan verilemez. İki ayrı kapı reddeder.
• Agent'ın kendi yetkisi yazma içermez. Okuma, keşif ve bürünme; secrets yok.