Bagaimana RBAC bekerja dengan ServiceAccount, dan bagaimana mengamankan sebuah cluster Kubernetes?

Question

IT Interview Practice · Accepted Answer

**RBAC (Role-Based Access Control)** mengatur *siapa boleh melakukan apa* pada API. Izin diberikan ke **subject** (user, group, **ServiceAccount**) dengan **mengikatnya** ke **Role** yang mendaftar verb yang diizinkan pada resource. RBAC adalah satu lapisan dari strategi cluster-hardening yang lebih luas.

## Model RBAC

```text
SUBJECT (user / group / ServiceAccount)
   │  diikat oleh
   ▼
RoleBinding ───────► Role         (namespaced: izin dalam SATU namespace)
ClusterRoleBinding ► ClusterRole  (cluster-wide, atau dipakai ulang lintas namespace)

Role/ClusterRole = sekumpulan RULE: "VERB ini pada RESOURCE ini"
Binding bersifat ADITIF dan TIDAK ADA deny — Anda hanya memberi yang dibutuhkan.
```

## Contoh Role + RoleBinding

```yaml
# Sebuah Role: akses read-only ke Pod di namespace "app"
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: app
  name: pod-reader
rules:
  - apiGroups: [""]
    resources: ["pods", "pods/log"]
    verbs: ["get", "list", "watch"]
---
# Ikat Role itu ke sebuah ServiceAccount
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: identitas untuk Pod

```text
Sebuah ServiceAccount adalah IDENTITAS yang dipakai Pod untuk bicara ke API server.
  → Setiap Pod mendapat satu (SA "default" namespace jika tak ditentukan).
  → Sebuah projected token di-mount ke Pod; RBAC memutuskan apa yang boleh token itu lakukan.
Best practice: beri tiap workload SA-nya SENDIRI dengan RBAC least-privilege,
dan set automountServiceAccountToken: false ketika Pod tidak butuh akses API.
```

```yaml
apiVersion: v1
kind: ServiceAccount
metadata: { name: my-app, namespace: app }
automountServiceAccountToken: false   # opt out jika tak butuh panggilan API
---
apiVersion: apps/v1
kind: Deployment
# ...
spec:
  template:
    spec:
      serviceAccountName: my-app       # jalankan Pod di bawah identitas ini
```

## Defense in depth — di luar RBAC

```text
AUTH        → RBAC least-privilege; ServiceAccount per-workload; audit akses
NETWORK     → NetworkPolicy default-deny (Pod tak bisa bicara kecuali diizinkan)
WORKLOAD    → securityContext: runAsNonRoot, readOnlyRootFilesystem, drop capabilities
              profil seccomp; Pod Security Admission (restricted) untuk memaksakan
SECRETS     → encryption at rest untuk etcd; manajer secret eksternal; RBAC ketat pada secret
IMAGES      → scan image, pakai registry tepercaya, paksakan dengan admission (mis. policy engine)
API/etcd    → batasi & enkripsi etcd; TLS di mana-mana; batasi akses anonim & cluster-admin
SUPPLY CHAIN→ image bertanda tangan, 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          # apa yang bisa dilakukan user saat ini?
```

## Mengapa ini penting

Mengamankan sebuah cluster adalah tanggung jawab senior, dan RBAC dengan ServiceAccount adalah fondasinya, sehingga memahami keduanya adalah pengetahuan keamanan yang esensial. Model RBAC elegan dan layak diinternalisasi: izin bersifat **murni aditif tanpa deny**, diberikan dengan **mengikat subject** (user, group, dan terutama **ServiceAccount**) ke **Role** (namespaced) atau **ClusterRole** (cluster-wide) yang menyebutkan **verb yang diizinkan pada resource** — yang berarti keamanan yang baik datang dari memberi hanya yang dibutuhkan tiap workload (**least privilege**) alih-alih mengandalkan penolakan. Memahami bahwa sebuah **ServiceAccount adalah identitas yang dipakai Pod untuk memanggil API** — bahwa setiap Pod mendapat token, bahwa SA `default` adalah jebakan over-privilege yang umum, dan bahwa Anda sebaiknya memberi tiap workload SA least-privilege-nya sendiri (dan menonaktifkan automounting token ketika tak butuh akses API) — sangat praktis dan sering menjadi sumber salah konfigurasi di dunia nyata. Yang krusial, insinyur senior tahu RBAC hanyalah satu lapisan dari **defense in depth**: **NetworkPolicy** default-deny, pengaturan **securityContext** yang diperkeras (non-root, root filesystem read-only, capability dibuang, seccomp), **Pod Security Admission**, **encryption at rest** dan manajer eksternal untuk Secret, scanning dan penandatanganan image, admission controller (OPA/Gatekeeper, Kyverno), serta akses etcd/API yang dikunci semuanya bergabung untuk melindungi sebuah cluster. Karena cluster Kubernetes adalah target bernilai tinggi di mana satu ServiceAccount yang terlalu berhak atau satu NetworkPolicy yang terbuka bisa berujung kompromi penuh, menguasai RBAC dan perangkat hardening yang lebih luas adalah fondasi untuk mengoperasikan cluster secara aman di production.

Model RBAC

Contoh Role + RoleBinding

ServiceAccount: identitas untuk Pod

Defense in depth — di luar RBAC

Mengapa ini penting

Pertanyaan terkait