Hari 38: RBAC Auditing — Dedicated SA Least Privilege

Kubesec dari Day 32 terus bilang: "Service accounts restrict Kubernetes API access and should be configured with least privilege". Hari ini fix. Audit RBAC, buat dedicated ServiceAccount, Role dengan resourceNames, dan update deployment.

Tooling: krew + rakkess Discovery

Tutorial pakai rakkess binary. Tapi pas cek GitHub repo rajat-saxena/rakkess — 404 Not Found. Repo sudah deleted/archived. Ternyata rakkess sekarang menjadi access-matrix plugin di krew (kubectl plugin manager). Solusi: install krew, kemudian install access-matrix + who-can plugins.

# Install krew v0.5.0 (darwin_arm64)
cd /tmp && curl -sL -o krew.tar.gz "https://github.com/kubernetes-sigs/krew/releases/download/v0.5.0/krew-darwin_arm64.tar.gz"
tar -xzf krew.tar.gz && ./krew-darwin_arm64 install krew
export PATH="${KREW_ROOT:-$HOME/.krew}/bin:$PATH"

# Install plugins
kubectl krew install access-matrix who-can

Audit Before: default SA, No RBAC

# Pods pakai SA apa?
$ kubectl get pods -n securebank -o jsonpath='{.items[*].spec.serviceAccountName}'
default default  # shared SA, no accountability

# Role/RoleBinding?
$ kubectl get role -n securebank
No resources found

# who-can create pods?
$ kubectl who-can create pods -n securebank
No subjects found with permissions to create pods assigned through RoleBindings
(only system controllers + cluster-admin)

# access-matrix for default SA
$ kubectl access-matrix -n securebank --sa default
NAME    LIST  CREATE  UPDATE  DELETE
        ✖     ✖       ✖       ✖  # all denied (good, but shared SA)

Problem: default SA is shared — semua Pod tanpa serviceAccountName pakai default. Kalau Pod compromise, attacker pakai default identity. Tidak bisa audit siapa yang akses apa.

Fix: 3 RBAC Resources

1. ServiceAccount — dedicated SA, no token automount:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: securebank-api
  namespace: securebank
automountServiceAccountToken: false

2. Role — least privilege with resourceNames:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: securebank-api-role
  namespace: securebank
rules:
  - apiGroups: [""]
    resources: ["configmaps"]
    verbs: ["get"]
    resourceNames: ["securebank-config"]

resourceNames adalah kunci least privilege. Tanpa ini, SA bisa get ALL configmaps. Dengan resourceNames: ["securebank-config"], SA hanya bisa get configmap itu saja — tidak bisa get configmap lain, tidak bisa list/create/update/delete.

3. RoleBinding — bind SA to Role:

subjects:
  - kind: ServiceAccount
    name: securebank-api
    namespace: securebank
roleRef:
  kind: Role
  name: securebank-api-role

Deployment Update

# Before (Day 33):
spec:
  automountServiceAccountToken: false
  # no serviceAccountName — uses default SA

# After (Day 38):
spec:
  serviceAccountName: securebank-api  # dedicated SA
  automountServiceAccountToken: false

Verify: Least Privilege Confirmed

$ kubectl auth can-i get configmaps/securebank-config -n securebank --as=system:serviceaccount:securebank:securebank-api
yes  # can get specific configmap ✅

$ kubectl auth can-i get configmaps/other-config -n securebank --as=system:serviceaccount:securebank:securebank-api
no   # cannot get other configmaps ✅

$ kubectl auth can-i list pods -n securebank --as=system:serviceaccount:securebank:securebank-api
no   # cannot list pods ✅

$ kubectl auth can-i create pods -n securebank --as=system:serviceaccount:securebank:securebank-api
no   # cannot create pods ✅

$ kubectl auth can-i get secrets -n securebank --as=system:serviceaccount:securebank:securebank-api
no   # cannot get secrets ✅

Perfect least privilege: hanya get pada securebank-config, nothing else.

Before vs After

Aspek	Before (Day 37)	After (Day 38)
ServiceAccount	default (shared)	securebank-api (dedicated)
Accountability	❌ No	✅ Yes (auditable)
Role	None	get configmap securebank-config only
RoleBinding	None	SA → Role
Kubesec score	11	12 (+1 ServiceAccountName)
Kubesec advise	3 (AppArmor, SA, Seccomp)	2 (AppArmor, Seccomp)
Checkov passed	88	101 (+13 for RBAC resources)
Checkov failed	0	0

3 RBAC Audit Tools, 3 Use Cases

Tool	What it shows	Best for
kubectl who-can <verb> <resource>	Who can perform a verb on a resource type	Finding overprivileged subjects
kubectl access-matrix --sa <name>	Matrix of all resources x verbs for a SA	Overview of SA permissions
kubectl auth can-i <verb> <resource> --as=<sa>	Yes/No for specific action	Verifying least privilege (most precise)

kubectl auth can-i paling precise — bisa test exact resource + resourceName. who-can dan access-matrix bagus untuk overview, tapi tidak handle resourceNames restriction.

Pelajaran Hari Ini

default SA = shared, no accountability. Semua Pod tanpa serviceAccountName pakai default SA. Dedicated SA = explicit, auditable. Kalau Pod compromise, attacker pakai SA identity — dengan dedicated SA, bisa audit dan revoke.

resourceNames = true least privilege. Role tanpa resourceNames allow verb pada ALL resources of that type. Dengan resourceNames: ["securebank-config"], SA hanya bisa akses configmap itu saja.

automountServiceAccountToken: false + dedicated SA = defense in depth. Token tidak di-mount (Pod tidak bisa talk to K8s API), TAPI Role tetap dibuat untuk "if needed" — kalau future feature butuh akses API, SA sudah punya least privilege Role.

rakkess repo 404 → access-matrix krew plugin. Selalu cek status repo sebelum install. Kalau 404, cari fork atau plugin replacement di krew index.

Repo

Semua code dan dokumentasi ada di: https://github.com/stayrelevantid/chalange-devsecops

Kesimpulan

RBAC auditing selesai. Dedicated ServiceAccount securebank-api dengan least privilege Role (get configmap only, resourceNames restricted). Kubesec score 11 → 12, Checkov 101/0. rakkess repo 404 → access-matrix krew plugin. Besok Day 39 — Falco Setup, runtime security monitoring.