Bagaimana RBAC berfungsi dengan ServiceAccount, dan bagaimana anda menyelamatkan sebuah cluster Kubernetes?

Question

IT Interview Practice · Accepted Answer

**RBAC (Role-Based Access Control)** mentadbir *siapa boleh buat apa* pada API. Kebenaran diberi kepada **subjek** (pengguna, kumpulan, **ServiceAccount**) dengan **mengikat (binding)** mereka kepada **Role** yang menyenaraikan verb yang dibenarkan pada sumber. RBAC ialah satu lapisan dalam strategi pengukuhan (hardening) cluster yang lebih luas.

## Model RBAC

```text
SUBJEK (user / kumpulan / ServiceAccount)
   │  diikat oleh
   ▼
RoleBinding ───────► Role         (bernamespace: kebenaran dalam SATU namespace)
ClusterRoleBinding ► ClusterRole  (seluruh cluster, atau boleh guna semula merentas namespace)

Role/ClusterRole = satu set RULE: "VERB ini pada RESOURCE ini"
Binding bersifat TAMBAHAN dan TIADA deny — anda beri hanya apa yang diperlukan.
```

## Contoh Role + RoleBinding

```yaml
# Satu Role: akses baca-sahaja kepada Pod dalam 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 kepada satu 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: identiti untuk Pod

```text
Sebuah ServiceAccount ialah IDENTITI yang digunakan sebuah Pod untuk bercakap dengan API server.
  → Setiap Pod dapat satu (SA "default" namespace jika tidak dinyatakan).
  → Satu token projected dilekapkan ke dalam Pod; RBAC memutuskan apa token itu boleh buat.
Amalan terbaik: beri setiap workload SA SENDIRI dengan RBAC keistimewaan-terkecil,
dan set automountServiceAccountToken: false apabila Pod tidak perlukan akses API.
```

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

## Pertahanan berlapis — melangkaui RBAC

```text
AUTH        → RBAC keistimewaan-terkecil; ServiceAccount setiap-workload; audit akses
NETWORK     → NetworkPolicy default-deny (Pod tak boleh bercakap melainkan dibenarkan)
WORKLOAD    → securityContext: runAsNonRoot, readOnlyRootFilesystem, buang capability
              profil seccomp; Pod Security Admission (restricted) untuk kuatkuasa
SECRETS     → encryption at rest untuk etcd; pengurus secret luaran; RBAC ketat pada secret
IMAGES      → imbas imej, guna registry dipercayai, kuatkuasa dengan admission (cth. policy engine)
API/etcd    → hadkan & sulitkan etcd; TLS di mana-mana; hadkan akses anonymous & cluster-admin
SUPPLY CHAIN→ imej ditandatangani, 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 pengguna semasa boleh buat?
```

## Mengapa ia penting

Menyelamatkan sebuah cluster ialah tanggungjawab senior, dan RBAC dengan ServiceAccount ialah asasnya, jadi memahami kedua-duanya ialah pengetahuan keselamatan yang penting. Model RBAC anggun dan berbaloi dihayati: kebenaran adalah **tambahan tulen tanpa deny**, diberi dengan **mengikat subjek** (pengguna, kumpulan, dan terutamanya **ServiceAccount**) kepada **Role** (bernamespace) atau **ClusterRole** (seluruh cluster) yang menyenaraikan **verb yang dibenarkan pada sumber** — bermakna keselamatan yang baik datang daripada memberi hanya apa yang setiap workload perlukan (**keistimewaan-terkecil**) dan bukan bergantung pada penafian. Memahami bahawa **ServiceAccount ialah identiti yang digunakan sebuah Pod untuk memanggil API** — bahawa setiap Pod dapat satu token, bahawa SA `default` ialah perangkap keistimewaan-berlebihan yang biasa, dan bahawa anda patut beri setiap workload SA keistimewaan-terkecil sendiri (dan lumpuhkan automounting token apabila tiada akses API diperlukan) — adalah amat praktikal dan punca salah konfigurasi dunia nyata yang kerap. Secara kritikal, seorang jurutera senior tahu RBAC hanyalah satu lapisan **pertahanan berlapis**: **NetworkPolicy** default-deny, tetapan **securityContext** yang diperkukuh (bukan-root, root filesystem baca-sahaja, capability dibuang, seccomp), **Pod Security Admission**, **encryption at rest** dan pengurus luaran untuk Secret, imbasan dan penandatanganan imej, admission controller (OPA/Gatekeeper, Kyverno), dan akses etcd/API yang dikunci ketat semuanya bergabung untuk melindungi sebuah cluster. Kerana sebuah cluster Kubernetes ialah sasaran bernilai tinggi di mana satu ServiceAccount yang terlebih kebenaran atau satu NetworkPolicy terbuka boleh membawa kepada kompromi penuh, menguasai RBAC dan kit alat pengukuhan yang lebih luas adalah asas untuk mengendalikan cluster dengan selamat di production.

Model RBAC

Contoh Role + RoleBinding

ServiceAccount: identiti untuk Pod

Pertahanan berlapis — melangkaui RBAC

Mengapa ia penting

Soalan berkaitan