RBAC, ServiceAccount'larla nasıl çalışır ve bir Kubernetes cluster'ını nasıl güvenli hale getirirsiniz?

Question

IT Interview Practice · Accepted Answer

**RBAC (Role-Based Access Control)**, API üzerinde *kimin ne yapabileceğini* yönetir. İzinler, izin verilen fiilleri kaynaklar üzerinde listeleyen **Role**'lere **bağlanarak (binding)** **öznelere** (kullanıcılar, gruplar, **ServiceAccount**'lar) verilir. RBAC, daha geniş bir cluster sertleştirme stratejisinin bir katmanıdır.

## RBAC modeli

```text
ÖZNE (kullanıcı / grup / ServiceAccount)
   │  bağlanan
   ▼
RoleBinding ───────► Role         (namespace'li: TEK bir namespace içindeki izinler)
ClusterRoleBinding ► ClusterRole  (cluster çapında veya namespace'ler arası yeniden kullanılabilir)

Role/ClusterRole = bir KURAL kümesi: "bu KAYNAKLAR üzerinde bu FİİLLER"
Binding'ler EKLEMELİDİR ve deny YOKTUR — yalnızca gerekeni verirsiniz.
```

## Role + RoleBinding örneği

```yaml
# Bir Role: "app" namespace'inde Pod'lara salt-okunur erişim
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: app
  name: pod-reader
rules:
  - apiGroups: [""]
    resources: ["pods", "pods/log"]
    verbs: ["get", "list", "watch"]
---
# O Role'ü bir ServiceAccount'a bağla
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: app
  name: read-pods
subjects:
  - kind: ServiceAccount
    name: my-app
    namespace: app
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io
```

## ServiceAccount'lar: Pod'lar için kimlik

```text
Bir ServiceAccount, bir Pod'un API server ile konuşmak için kullandığı KİMLİKTİR.
  → Her Pod bir tane alır (belirtilmezse "default" namespace SA'sı).
  → Pod'a bir projected token mount edilir; RBAC o token'ın ne yapabileceğine karar verir.
En iyi pratik: her workload'a KENDİ en-az-ayrıcalıklı RBAC'li SA'sını ver
ve Pod API erişimine ihtiyaç duymadığında automountServiceAccountToken: false ayarla.
```

```yaml
apiVersion: v1
kind: ServiceAccount
metadata: { name: my-app, namespace: app }
automountServiceAccountToken: false   # API çağrısı gerekmiyorsa devre dışı bırak
---
apiVersion: apps/v1
kind: Deployment
# ...
spec:
  template:
    spec:
      serviceAccountName: my-app       # Pod'ları bu kimlik altında çalıştır
```

## Katmanlı savunma — RBAC'ın ötesinde

```text
AUTH        → en-az-ayrıcalıklı RBAC; workload başına ServiceAccount; erişimi denetle
NETWORK     → varsayılan-reddet NetworkPolicy'ler (Pod'lar izinsiz konuşamaz)
WORKLOAD    → securityContext: runAsNonRoot, readOnlyRootFilesystem, capability'leri düşür
              seccomp profilleri; zorlamak için Pod Security Admission (restricted)
SECRETS     → etcd için rest halinde şifreleme; harici secret yöneticileri; secret'larda sıkı RBAC
IMAGES      → image'ları tara, güvenilir registry kullan, admission ile zorla (örn. policy engine'ler)
API/etcd    → etcd'yi kısıtla & şifrele; her yerde TLS; anonim & cluster-admin erişimini sınırla
SUPPLY CHAIN→ imzalı image'lar, admission control (OPA/Gatekeeper, Kyverno)
```

```bash
kubectl auth can-i list pods --as=system:serviceaccount:app:my-app -n app
kubectl auth can-i --list -n app          # mevcut kullanıcı ne yapabilir?
```

## Neden önemli

Bir cluster'ı güvenli hale getirmek senior bir sorumluluktur ve ServiceAccount'larla RBAC onun temelidir; bu yüzden ikisini de anlamak elzem bir güvenlik bilgisidir. RBAC modeli zariftir ve içselleştirmeye değer: izinler **tamamen eklemelidir, deny yoktur**, izin verilen **kaynaklar üzerindeki fiilleri** sıralayan **Role**'lere (namespace'li) veya **ClusterRole**'lere (cluster çapında) **özneleri bağlayarak** (kullanıcılar, gruplar ve özellikle **ServiceAccount**'lar) verilir — bu da iyi güvenliğin, reddetmelere güvenmek yerine her workload'ın yalnızca ihtiyaç duyduğunu vermekten (**en az ayrıcalık**) geldiği anlamına gelir. Bir **ServiceAccount'ın bir Pod'un API'yi çağırmak için kullandığı kimlik olduğunu** anlamak — her Pod'un bir token aldığını, `default` SA'nın yaygın bir aşırı-ayrıcalık tuzağı olduğunu ve her workload'a kendi en-az-ayrıcalıklı SA'sını vermeniz gerektiğini (ve API erişimi gerekmediğinde token automount'unu kapatmanız gerektiğini) — doğrudan pratiktir ve gerçek dünyada sık bir yanlış yapılandırma kaynağıdır. Kritik olarak, bir senior mühendis RBAC'ın **katmanlı savunmanın** yalnızca bir katmanı olduğunu bilir: varsayılan-reddet **NetworkPolicy**'ler, sertleştirilmiş **securityContext** ayarları (non-root, salt-okunur root filesystem, düşürülen capability'ler, seccomp), **Pod Security Admission**, Secret'lar için **rest halinde şifreleme** ve harici yöneticiler, image tarama ve imzalama, admission controller'lar (OPA/Gatekeeper, Kyverno) ve kilitlenmiş etcd/API erişimi bir cluster'ı korumak için birleşir. Bir Kubernetes cluster'ı, tek bir aşırı-yetkili ServiceAccount'ın veya açık bir NetworkPolicy'nin tam ele geçirmeye yol açabileceği yüksek değerli bir hedef olduğundan, RBAC'a ve daha geniş sertleştirme araç setine hâkim olmak cluster'ları production'da güvenli işletmenin temelidir.

RBAC modeli

Role + RoleBinding örneği

ServiceAccount'lar: Pod'lar için kimlik

Katmanlı savunma — RBAC'ın ötesinde

Neden önemli

İlgili sorular