Kubernetes 101: Role-Based Access Control

Role-Based Access Control (RBAC) itu kayak sistem buat ngatur siapa yang bisa ngapain di dalam suatu aplikasi atau sistem. Jadi, dia bakal bantu nentuin apa aja yang boleh dan nggak boleh dilakuin sama user yang udah login.

Pengenalan

Role-Based Access Control (RBAC) itu bagian penting dari sistem keamanan di aplikasi atau sistem yang canggih. RBAC ini bikin cara buat ngatur apa aja yang boleh dan nggak boleh dilakuin setelah user login.

Caranya gimana? RBAC ini pake konsep role atau peran. Tiap peran punya izin atau permission yang beda-beda, dan peran-peran ini yang nantinya diberikan ke para pengguna.

Jadi, misalnya ada role admin, editor, dan viewer. Admin bisa lakuin banyak hal, editor bisa ngedit, dan viewer cuma bisa lihat. Gitu deh cara RBAC ngatur apa yang boleh dan nggak boleh dilakuin sama user di dalam sistem.

Apa Itu RBAC?

RBAC di Kubernetes itu dasarnya punya empat komponen utama, yaitu: Role, ClusterRole, RoleBinding, dan ClusterRoleBinding.

Role

Jadi, Role ini ibarat daftar izin yang berlaku di suatu namespace tertentu. Ini yang nentuin apa aja yang bisa dilakuin di resource di dalam namespace itu. Izin-izin ini ada di dalam yang namanya policy rules. Contohnya, ini ada Role yang bisa dibuat buat baca ConfigMaps di namespace default:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: configmap-reader
rules:
- apiGroups: [""]
  resources: ["configmaps"]
  verbs: ["get", "watch", "list"]

ClusterRole

Jadi, ClusterRole itu mirip kayak Role, yang isinya itu aturan-aturan buat ngatur akses ke berbagai resource. Bedanya, kalo Role cuma berlaku di satu namespace doang, sedangkan ClusterRole ini berlaku di seluruh cluster, bahkan bisa dipake di banyak namespace sekaligus.

ClusterRole itu kayak semacam tiket akses yang punya wewenang buat ngelakuin banyak hal di seluruh cluster, bukan cuma di satu tempat aja. Contohnya, kalo mau bikin ClusterRole yang bisa ngatur resource di level cluster, ini salah satu contohnya:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: secret-reader
rules:
- apiGroups: [""]
  resources: ["secrets"]
verbs: ["get", "watch", "list"]

RoleBinding

RoleBinding itu fungsinya kayak jembatan yang nyambungin Role ke user atau sekelompok user. RoleBinding ini yang bikin aturan-aturan dari Role itu bisa diterapin ke orang-orang yang kamu pilih.

Gampangnya, RoleBinding itu yang ngatur siapa aja yang boleh ngelakuin apa, berdasarkan aturan-aturan dari Role yang udah ada. Contoh RoleBinding:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-configmaps
  namespace: default
subjects:
- kind: User
  name: john
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: configmap-reader
  apiGroup: rbac.authorization.k8s.io

ClusterRoleBinding

Mirip kayak RoleBinding tapi buat ClusterRoles. Ini ngaitin ClusterRole ke satu user atau beberapa user sekaligus. Nih, contoh sederhana dari ClusterRoleBinding:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: read-secrets-global
subjects:
- kind: Group
  name: managers
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

Peran dan Hubungan RBAC dengan Sumber Daya Lainnya

Integrasi RBAC ke strategi manajemen sumber daya yang lebih luas bikin kontrol detail tentang siapa yang bisa akses dan manipulasi berbagai sumber daya Kubernetes. Bayangin kamu punya resource Deployment yang mengatur sekumpulan Pod.

Buat ngatur siapa yang bisa update Deployment, yang nantinya juga ngontrol konfigurasi Pod, kamu bisa bikin Role yang cuma ngizinin operasi tertentu di resource Deployment dalam namespace spesifik.

Role ini bisa kamu kasih ke user atau grup user lewat RoleBinding. Contohnya, begini cara kamu bisa nentuin Role yang cuma bisa get, list, dan watch Deployments di namespace default:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: deployment-reader
rules:
- apiGroups: ["apps"]
  resources: ["deployments"]
  verbs: ["get", "watch", "list"]

Terus kamu bisa bikin RoleBinding buat ngasih John, misalnya, izin dari Role deployment-reader:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-deployments
  namespace: default
subjects:
- kind: User
  name: john
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: deployment-reader
  apiGroup: rbac.authorization.k8s.io

Bikin RBAC Sendiri

Nerapin Role-Based Access Control (RBAC) versi kamu sendiri berarti kamu harus ngerti kebutuhan spesifik-mu dulu, nentuin role yang sesuai, dan ngaitin role ini ke user, grup, atau service account yang pas. Ini langkah- langkah buat bikin dan nerapin RBAC:

Pahami Kebutuhan

Pahami dulu kebutuhan akses dari user atau service kamu. Misalnya, sekelompok developer mungkin butuh akses baca dan tulis ke ConfigMaps dan Secrets di namespace tertentu, sementara grup lain cuma perlu akses baca aja ke resource yang sama.

Tentukan Role

Berdasarkan kebutuhan yang udah lo identifikasi, bikin Role atau ClusterRole yang nyertain izin-izin tersebut. Nih contohnya Role yang ngasih izin baca dan tulis ke ConfigMaps dan Secrets di namespace default:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: config-secret-manager
rules:
- apiGroups: [""]
  resources: ["configmaps", "secrets"]
  verbs: ["get", "watch", "list", "create", "update", "delete"]

Tentukan RoleBindings atau ClusterRoleBindings

Selanjutnya, kaitin role yang udah dibikin ke user, grup, atau service account yang sesuai pake RoleBindings atau ClusterRoleBindings. Ini contoh RoleBinding yang ngasih role config-secret-manager ke user john di namespace default:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: config-secret-manager-binding
  namespace: default
subjects:
- kind: User
  name: john
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: config-secret-manager
  apiGroup: rbac.authorization.k8s.io

Terapkan Roles dan RoleBindings

Sekarang, pake kubectl apply buat bikin resource-resource ini di cluster Kubernetes kamu:

~$ kubectl apply -f role.yaml kubectl apply -f rolebinding.yaml

Verifikasi Akses

Kamu bisa verifikasi akses dengan nyamar jadi user dan coba lakuin operasi yang seharusnya diizinkan oleh role. Misalnya, sebagai john, sekarang kamu harusnya bisa nge-list ConfigMaps di namespace default:

Kamu bisa verifikasi apakah akses udah diberikan dengan benar dengan cara menyamar sebagai user dan coba lakuin operasi yang seharusnya diizinkan oleh role. Misalnya, sebagai john, sekarang kamu harusnya bisa nge-list ConfigMaps di namespace default:

~$ kubectl --as=john get configmaps -n default

Monitor dan Update Akses Terus-Menerus

Pastiin kamu punya sistem buat audit role dan binding secara rutin. Kamu bisa lakuin manual (review berkala semua role dan binding) atau otomatis (pake tools atau script). Selalu update sesuai kebutuhan pas fungsi pekerjaan berubah, atau pas ada user yang ditambah atau dihapus.

Dengan ngikutin langkah-langkah ini, kamu bisa bikin dan nerapan kebijakan RBAC kamu sendiri di Kubernetes dengan efektif. Ingat prinsip least privilege – cuma kasih akses yang bener-bener diperluin buat user atau service biar bisa jalan.