Kubernetes RBAC: Least Privilege + Break‑Glass Modeli

Kubernetes RBAC konusu çoğu kurumda iki uçta yaşanır: ya herkes cluster-admin olur (“incident çıkmasın”) ya da çok katı politikalar yüzünden küçük bir müdahale bile saatler sürer. Sağlıklı model, least privilege’ı korurken incident anında “kilitlenmemeyi” de garanti eder: yani break‑glass.

Bu rehber, sahada çalışan bir RBAC tasarımını üç parçaya böler:

1. Rol tasarımı (ürün/operasyon ihtiyaçlarına göre)
2. Kimlik entegrasyonu (gruplar ve sahiplik)
3. Break‑glass (time‑boxed, denetlenebilir acil erişim)

1) Hedef: “Kimin neye ihtiyacı var?” sorusunu netleştir

En çok iş gören rol kümeleri:

• Read‑only: gözlem ve triage için
• Namespace operator: deploy/scale/log/pod restart gibi rutin işler için
• Platform operator: ingress, CNI, storage gibi platform bileşenleri için
• Security: policy/audit odaklı (genelde write yetkisi sınırlı)
• Break‑glass: sadece acil durum, süreli

2) Basit bir rol tasarımıyla başla (örnek)

Aşağıdaki örnekler “kopyala‑yapıştır” değil; hangi kapıların açık/kapalı olacağını anlatan bir şablondur.

2.1 Read‑only (namespace içinde)

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: ns-readonly
  namespace: your-namespace
rules:
  - apiGroups: [""]
    resources: ["pods", "pods/log", "services", "endpoints", "configmaps", "events"]
    verbs: ["get", "list", "watch"]
  - apiGroups: ["apps"]
    resources: ["deployments", "replicasets", "statefulsets", "daemonsets"]
    verbs: ["get", "list", "watch"]

2.2 Namespace operator (kontrollü write)

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: ns-operator
  namespace: your-namespace
rules:
  - apiGroups: ["apps"]
    resources: ["deployments", "statefulsets"]
    verbs: ["get", "list", "watch", "patch", "update"]
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "list", "watch", "delete"]
  - apiGroups: [""]
    resources: ["pods/exec"]
    verbs: ["create"]

3) Kimlik entegrasyonu: “Kullanıcı” değil “grup” bağla

Sürdürülebilir RBAC için iki kural:

1. RoleBinding / ClusterRoleBinding ile kullanıcıyı değil grubu bağla
2. Grup üyeliğini IdP/IAM tarafında yönet (on/off ve audit burada olmalı)

Örnek binding:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: ns-operator-binding
  namespace: your-namespace
subjects:
  - kind: Group
    name: platform:ns-operators
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: ns-operator
  apiGroup: rbac.authorization.k8s.io

4) Break‑glass: Time‑boxed ve denetlenebilir erişim

Break‑glass, “gizli cluster-admin” değildir. Tasarım hedefi:

• Gerektiğinde erişim açılabilsin
• Süreli olsun (1–4 saat gibi)
• Açma/kapama kararı audit edilsin
• Incident bitince otomatik kapanabilsin

4.1 En pratik model: IdP grubuyla süreli üyelik

Kurumsal sahada en az sürtünmeli model:

• platform:breakglass diye bir grup tanımlarsın
• RBAC’ta bu gruba “yüksek ama hedefli” yetki verirsin
• Incident anında kullanıcıyı bu gruba süreli eklersin (time‑boxed)
• IdP audit log’ları + Kubernetes audit log’ları birlikte incelenebilir olur

4.2 Break‑glass rolünü “hedefli” tut

Örnek: her şeyi açmak yerine, operasyonun ihtiyacına göre sınırla:

• kubectl rollout undo / scale gibi müdahaleler
• ingress/service düzeltmeleri
• node cordon/drain gibi platform işlemleri (gerekirse)

5) Hızlı doğrulama: “Bu yetkim var mı?”

İki komut, incident anında çok vakit kazandırır:

kubectl auth can-i get pods -n your-namespace
kubectl auth can-i delete pod -n your-namespace

Bu kontrolleri runbook’a koyun; tartışmayı azaltır.

6) Operasyon checklist’i (kısa)

• RBAC rolleri ürün ekibi ihtiyaçlarına göre tanımlı mı?
• Exec yetkisi ayrı mı, audit ediliyor mu?
• Break‑glass aktive etme/kapatma prosedürü yazılı mı?
• Break‑glass kararı için “kim onaylar?” belli mi?
• Audit log’lar merkezi yerde mi, saklama süresi yeterli mi?

Sonuç

RBAC, güvenlik ekibinin “kısıt koyma” aracı değil; platformun güvenli çalışma modudur. Least privilege + break‑glass birlikte tasarlanırsa, hem güvenlik artar hem de incident anında ekipler “erişim yok” yüzünden daha büyük zarar üretmez.