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.

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.

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.