Kepiyé RBAC makarya karo ServiceAccount, lan kepiyé sampeyan ngamanaké cluster Kubernetes?

Question

IT Interview Practice · Accepted Answer

**RBAC (Role-Based Access Control)** ngatur *sapa sing bisa nglakoni apa* ing API. Idin diwènèhaké marang **subyek** (user, grup, **ServiceAccount**) kanthi **ngiket** dhèwèké menyang **Role** sing ndhaptar verb sing diidini ing resource. RBAC iku siji lapisan saka strategi pengerasan cluster sing luwih wiyar.

## Model RBAC

```text
SUBYEK (user / grup / ServiceAccount)
   │  kaiket déning
   ▼
RoleBinding ───────► Role         (namespaced: idin ing SIJI namespace)
ClusterRoleBinding ► ClusterRole  (sacluster, utawa bisa dienggo manèh ing pirang-pirang namespace)

Role/ClusterRole = sakumpulan ATURAN: "VERB iki ing RESOURCE iki"
Binding iku ADITIF lan ORA ana deny — sampeyan mung mènèhi apa sing dibutuhaké.
```

## Conto Role + RoleBinding

```yaml
# Sawijining Role: akses read-only marang Pod ing 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"]
---
# Iket Role iku menyang 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 kanggo Pod

```text
Sawijining ServiceAccount iku IDENTITAS sing dienggo Pod kanggo omong-omongan karo API server.
  → Saben Pod nampa siji (SA namespace "default" yèn ora disebutaké).
  → Token sing diproyeksikaké di-mount menyang Pod; RBAC nemtokaké apa sing bisa dilakoni token iku.
Praktik paling apik: mènèhi saben workload SA-né DHÉWÉ kanthi RBAC least-privilege,
lan setel automountServiceAccountToken: false nalika Pod ora butuh akses API.
```

```yaml
apiVersion: v1
kind: ServiceAccount
metadata: { name: my-app, namespace: app }
automountServiceAccountToken: false   # opt out yèn ora butuh panggilan API
---
apiVersion: apps/v1
kind: Deployment
# ...
spec:
  template:
    spec:
      serviceAccountName: my-app       # njalanaké Pod kanthi identitas iki
```

## Pertahanan berlapis — ngluwihi RBAC

```text
AUTH        → RBAC least-privilege; ServiceAccount saben-workload; audit akses
NETWORK     → NetworkPolicy default-deny (Pod ora bisa omong-omongan kajaba diidini)
WORKLOAD    → securityContext: runAsNonRoot, readOnlyRootFilesystem, mbuang capability
              profil seccomp; Pod Security Admission (restricted) kanggo meksa
SECRET      → enkripsi saat istirahat kanggo etcd; manajer secret eksternal; RBAC ketat ing secret
IMAGE       → scan image, nganggo registry terpercaya, peksa nganggo admission (contoné policy engine)
API/etcd    → watesi & enkripsi etcd; TLS ing endi waé; watesi akses anonim & cluster-admin
RANTÉ PASOK → image sing ditandhatangani, 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 sing bisa dilakoni user saiki?
```

## Kenapa iki penting

Ngamanaké cluster iku tanggung jawab senior, lan RBAC karo ServiceAccount iku pondhasine, mula ngerti loro-loroné yaiku kawruh keamanan sing penting. Model RBAC iku anggun lan pantes diinternalisasi: idin iku **murni aditif tanpa deny**, diwènèhaké kanthi **ngiket subyek** (user, grup, lan utamané **ServiceAccount**) menyang **Role** (namespaced) utawa **ClusterRole** (sacluster) sing nyacahaké **verb sing diidini ing resource** — sing tegesé keamanan sing apik teka saka mènèhi mung apa sing dibutuhaké saben workload (**least privilege**) tinimbang gumantung marang penolakan. Ngerti yèn **ServiceAccount iku identitas sing dienggo Pod kanggo nyeluk API** — yèn saben Pod nampa token, yèn SA `default` iku jebakan over-privilege sing umum, lan yèn sampeyan kudu mènèhi saben workload SA least-privilege-né dhéwé (lan mateni automount token nalika ora butuh akses API) — iku langsung praktis lan sumber salah konfigurasi nyata sing kerep. Sing krusial, insinyur senior ngerti RBAC mung siji lapisan **pertahanan berlapis**: **NetworkPolicy** default-deny, setelan **securityContext** sing dikerasaké (non-root, root filesystem read-only, capability sing dibuang, seccomp), **Pod Security Admission**, **enkripsi saat istirahat** lan manajer eksternal kanggo Secret, scanning lan penandhatanganan image, admission controller (OPA/Gatekeeper, Kyverno), sarta akses etcd/API sing dikunci kabèh nggabung kanggo nglindhungi cluster. Amarga cluster Kubernetes iku target regané dhuwur ing endi siji ServiceAccount sing over-permissioned utawa NetworkPolicy sing mbukak bisa nyebabaké kompromi lengkap, nguwasani RBAC lan toolkit pengerasan sing luwih wiyar iku dhasar kanggo ngoperasi cluster kanthi aman ing production.

Model RBAC

Conto Role + RoleBinding

ServiceAccount: identitas kanggo Pod

Pertahanan berlapis — ngluwihi RBAC

Kenapa iki penting

Pitakon sing gegandhengan