RBAC #

Role-Based Access Control (RBAC) adalah mekanisme Kubernetes untuk mengontrol siapa boleh melakukan apa terhadap resource apa di cluster. Tanpa RBAC yang dirancang dengan baik, setiap komponen di cluster berpotensi mengakses dan memodifikasi resource yang seharusnya tidak mereka sentuh — termasuk Secret, Deployment, dan bahkan node cluster itu sendiri. RBAC adalah fondasi keamanan cluster yang tidak boleh diabaikan.

Tiga Komponen RBAC #

RBAC di Kubernetes dibangun dari tiga komponen yang bekerja bersama:

Subject (Siapa):
  User        — manusia yang autentikasi ke cluster (via kubeconfig)
  Group       — kumpulan user (misalnya: semua developer di tim tertentu)
  ServiceAccount — identitas untuk Pod dan proses yang berjalan di cluster

Role (Boleh apa di mana):
  Role        — permission yang berlaku di satu namespace
  ClusterRole — permission yang berlaku di seluruh cluster

RoleBinding (Hubungkan keduanya):
  RoleBinding        — bind Subject ke Role (namespace-scoped)
  ClusterRoleBinding — bind Subject ke ClusterRole (cluster-scoped)

Role vs ClusterRole #

# Role — hanya berlaku di namespace tertentu
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-reader
  namespace: production     # ← berlaku hanya di namespace ini
rules:
- apiGroups: [""]           # "" = core API group
  resources: ["pods"]
  verbs: ["get", "list", "watch"]

---
# ClusterRole — berlaku di seluruh cluster
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: node-reader         # tidak ada field namespace
rules:
- apiGroups: [""]
  resources: ["nodes"]      # nodes hanya bisa diakses via ClusterRole
  verbs: ["get", "list", "watch"]

Kapan gunakan mana:

Role (namespace-scoped):
  → Akses ke resource dalam satu namespace
  → Developer yang hanya boleh akses namespace-nya sendiri
  → Service yang hanya butuh baca ConfigMap di namespace-nya

ClusterRole:
  → Resource yang tidak punya namespace (nodes, PersistentVolumes, namespaces)
  → Permission yang sama perlu berlaku di SEMUA namespace
  → Monitoring agent yang perlu scrape metrik dari semua namespace

RoleBinding dan ClusterRoleBinding #

# RoleBinding — bind ServiceAccount ke Role di namespace tertentu
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: api-pod-reader
  namespace: production
subjects:
- kind: ServiceAccount
  name: api-service-account
  namespace: production
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

---
# ClusterRoleBinding — bind User ke ClusterRole di seluruh cluster
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: cluster-admin-binding
subjects:
- kind: User
  name: [email protected]
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: cluster-admin        # built-in ClusterRole paling tinggi
  apiGroup: rbac.authorization.k8s.io

Trik: ClusterRole bisa di-bind ke namespace tertentu via RoleBinding biasa. Ini memungkinkan reuse ClusterRole yang sama di banyak namespace:

# RoleBinding menggunakan ClusterRole, tapi scope-nya namespace "production"
kind: RoleBinding
metadata:
  namespace: production      # ← berlaku hanya di sini
roleRef:
  kind: ClusterRole          # ← referensi ClusterRole
  name: pod-reader

ServiceAccount untuk Pod #

Setiap Pod berjalan dengan identitas ServiceAccount. Secara default menggunakan ServiceAccount default yang ada di setiap namespace — tapi ini buruk untuk keamanan karena semua Pod berbagi identitas yang sama.

# Buat ServiceAccount khusus per aplikasi
apiVersion: v1
kind: ServiceAccount
metadata:
  name: api-service-account
  namespace: production
automountServiceAccountToken: false   # jangan auto-mount token kecuali dibutuhkan

---
# Gunakan ServiceAccount di Deployment
spec:
  template:
    spec:
      serviceAccountName: api-service-account
      automountServiceAccountToken: false   # redundant tapi eksplisit lebih baik
      containers:
      - name: api
        image: my-api:v2

# Beri permission minimal yang dibutuhkan
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: api-role
  namespace: production
rules:
- apiGroups: [""]
  resources: ["configmaps"]
  resourceNames: ["app-config"]   # ← hanya ConfigMap tertentu, bukan semua
  verbs: ["get"]
- apiGroups: [""]
  resources: ["secrets"]
  resourceNames: ["db-credentials", "api-keys"]
  verbs: ["get"]

Verbs dan Resources #

Verbs yang tersedia:
  get       — baca satu resource
  list      — baca semua resource (kembalikan daftar)
  watch     — watch perubahan real-time (streaming)
  create    — buat resource baru
  update    — update resource yang ada (PUT)
  patch     — update sebagian resource (PATCH)
  delete    — hapus resource
  deletecollection — hapus banyak resource sekaligus

Perhatikan perbedaan:
  "get" tidak berarti "list" — harus keduanya jika butuh keduanya
  "list" pada secrets berarti bisa lihat SEMUA secret — sangat berbahaya
  "watch" memungkinkan melihat perubahan real-time — hampir sama sensitif dengan "list"

# Contoh permission untuk operator yang butuh watch Deployment
rules:
- apiGroups: ["apps"]
  resources: ["deployments"]
  verbs: ["get", "list", "watch"]     # semua tiga jika butuh watch

# Batasi dengan resourceNames jika memungkinkan
- apiGroups: [""]
  resources: ["secrets"]
  resourceNames: ["specific-secret"]  # bukan verbs: ["list"] tanpa filter!
  verbs: ["get"]

Audit dan Verifikasi RBAC #

# Test apakah service account bisa melakukan aksi tertentu
kubectl auth can-i get pods \
  --as=system:serviceaccount:production:api-service-account \
  -n production
# Output: yes / no

# Test sebagai user tertentu
kubectl auth can-i delete deployments \
  --as=[email protected] \
  -n production
# Output: yes / no

# Lihat semua permission yang dimiliki service account
kubectl auth can-i --list \
  --as=system:serviceaccount:production:api-service-account \
  -n production

# Lihat semua RoleBinding dan ClusterRoleBinding yang ada
kubectl get rolebindings,clusterrolebindings -A

# Cari binding yang memberikan akses ke secrets
kubectl get rolebindings -A -o json | \
  jq '.items[] | select(.roleRef.name | contains("secret"))'

Built-in ClusterRoles #

Kubernetes menyediakan beberapa ClusterRole bawaan yang sering digunakan:

cluster-admin:
  → Akses penuh ke semua resource di seluruh cluster
  → Gunakan dengan sangat hemat — hanya untuk cluster operator

admin:
  → Akses penuh di satu namespace (via RoleBinding)
  → Bisa baca/tulis hampir semua resource kecuali ResourceQuota dan namespace itu sendiri

edit:
  → Bisa baca dan modifikasi resource (Deployment, Service, ConfigMap, dll)
  → Tidak bisa baca Secret atau mengubah RBAC

view:
  → Read-only untuk semua resource di namespace
  → Tidak bisa baca Secret

# Contoh: berikan akses edit ke tim developer di namespace mereka
kind: RoleBinding
metadata:
  name: dev-team-edit
  namespace: development
subjects:
- kind: Group
  name: dev-team          # semua user dalam group ini
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: edit              # built-in ClusterRole
  apiGroup: rbac.authorization.k8s.io

Ringkasan #

  • Tiga komponen RBAC — Subject (siapa), Role/ClusterRole (boleh apa), RoleBinding/ClusterRoleBinding (hubungkan keduanya); semua tiga harus ada agar permission berlaku.
  • Role untuk namespace, ClusterRole untuk cluster-wide — resource tanpa namespace (nodes, PV) hanya bisa diakses via ClusterRole; ClusterRole bisa di-bind ke namespace via RoleBinding biasa.
  • ServiceAccount per aplikasi, bukan pakai default — default ServiceAccount berbagi antara semua Pod di namespace; buat yang terpisah dan matikan auto-mount token kecuali dibutuhkan.
  • resourceNames untuk batasi ke resource spesifik — jangan berikan akses ke semua Secret, batasi ke Secret yang benar-benar dibutuhkan; ini perbedaan besar dalam blast radius jika terjadi compromise.
  • Verbs list dan watch pada secrets sangat berbahaya — list secrets berarti baca semua secret di namespace; gunakan get dengan resourceNames sebagai gantinya.
  • kubectl auth can-i --list — cara cepat audit semua permission yang dimiliki service account atau user tertentu; gunakan secara rutin untuk security review.

← Sebelumnya: Anti-Pattern Deployment   Berikutnya: Pod Security →

About | Author | Content Scope | Editorial Policy | Privacy Policy | Disclaimer | Contact