Menambahkan Role pada User Kubernetes

Apa itu RBAC

RBAC adalah keamanan yang membatasi akses ke sumber daya berdasarkan peran yang dimiliki pengguna, oleh karena itu namanya Role-based Access Control. Untuk memahami pentingnya dan perlunya memiliki kebijakan RBAC, mari pertimbangkan sistem yang tidak menggunakannya. Katakanlah kita memiliki solusi manajemen Kemanusiaan, tetapi satu-satunya ukurannya adalah terkait dengan akses keamanan yang digunakan adalah pengguna harus mengotentikasi diri mereka sendiri melalui nama pengguna dan kata sandi. Setelah memberikan kredensial mereka, pengguna mendapatkan akses penuh ke setiap modul dalam sistem (rekrutmen, pelatihan, kinerja staf, gaji, dll.). Sistem yang sedikit lebih aman akan membedakan antara akses pengguna biasa dan akses “admin”, dengan yang terakhir memberikan hak istimewa yang berpotensi merusak. Misalnya, pengguna biasa tidak dapat menghapus modul dari sistem, sedangkan administrator dapat. Namun tetap saja, pengguna tanpa akses admin dapat membaca dan memodifikasi data modul terlepas dari apakah pekerjaan mereka saat ini memerlukan melakukan hal ini.

Jika kita bekerja sebagai administrator Linux untuk waktu yang lama, kita menghargai pentingnya memiliki sistem keamanan yang mengimplementasikan matriks keamanan akses dan otoritas. Di masa lalu Linux dan UNIX, kita bisa menjadi pengguna “normal” dengan akses minimal ke sumber daya sistem, atau kita dapat memiliki akses “root”. Akses root secara virtual memberi kita kendali penuh atas mesin sehingga kita dapat secara tidak sengaja menjatuhkan seluruh sistem. Tak perlu dikatakan bahwa jika penyusup bisa mendapatkan akses ke akun root ini, seluruh sistem kita berisiko tinggi. Oleh karena itu, sistem RBAC diperkenalkan.

Dalam sistem yang menggunakan RBAC, sangat minim penyebutan “superuser” atau administrator yang memiliki akses ke semuanya. Sebagai gantinya, ada lebih banyak referensi ke tingkat akses, peran, dan hak istimewa. Bahkan administrator dapat dikategorikan berdasarkan persyaratan pekerjaan mereka. Jadi, administrator pencadangan harus memiliki akses penuh ke alat yang mereka gunakan untuk melakukan pencadangan penuh, inkremental, dan diferensial. Tetapi mereka seharusnya tidak dapat menghentikan server web atau mengubah tanggal dan waktu sistem, misalnya.

Objek API RBAC

Kontrol akses berbasis peran (RBAC) adalah metode untuk mengatur akses ke komputer dan sumber daya jaringan berdasarkan peran pengguna individu dalam suatu perusahaan. Kita dapat menggunakan kontrol akses berbasis Peran pada semua sumber daya Kubernetes yang memungkinkan CRUD (Buat, Baca, Perbarui, Hapus). Contoh resource:

  • Namespace
  • Pod
  • Deployment
  • Volume Persistent
  • ConfigMaps

Contoh kemungkinan operasi atas sumber daya ini adalah:

  • create
  • get
  • delete
  • list
  • update

Untuk mengelola RBAC di Kubernetes, kita perlu mendeklarasikan:

Role and ClusterRole

Mereka hanya seperangkat aturan yang mewakili satu set izin. Peran hanya dapat digunakan untuk memberikan akses ke sumber daya dalam ruang nama. ClusterRole dapat digunakan untuk memberikan izin yang sama dengan Peran, tetapi juga dapat digunakan untuk memberikan akses ke sumber daya cakupan cluster, titik akhir non-sumber daya.

Subject

Subjek adalah entitas yang akan melakukan operasi dalam cluster. Mereka dapat berupa akun pengguna, akun layanan, atau bahkan grup.

RoleBinding dan ClusterRoleBinding

Seperti namanya, itu hanya pengikatan antara subjek dan Peran atau ClusterRole.

Role default yang didefinisikan di Kubernetes adalah:

View => akses hanya baca, tidak termasuk secret

Edit => semua kemampuan diatas dan mengedit sebagian besar sumber daya, tidak termasuk peran dan ikatan peran

Admin => semua kemampuan diatas dan mengelola peran dan ikatan peran di tingkat namespace

Cluster-admin => Semua nya bisa kita lakukan

Tentu saja kita dapat membuat Roles dan ClusterRoles tertentu, tetapi kami menyarankan kami untuk menggunakan default selama kami/ bisa. Ini dapat dengan cepat menjadi sulit untuk mengelola semua ini.

Membuat Role

Oke, kita melanjutkan yg kemarin yaitu menambahkan role pada User asep yang telah kita buat kemarin. Kita akan membuat user Asep bisa melihat semua deployment dan pod pada namespace default. Oke kita untuk untuk melakukanya buat file role.yml lalu isikan seperti dibawah ini:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: deployment-role-asep
rules:
  - apiGroups: [ apps ]
    resources: [ deployments,pod ]
    verbs: [ get, list ]

Simpan dan jalankan dengan perintah kubectl apply -f role.yml 

Membuat ClusterRole

Kita sudah selesai membuat role nya langkah selanjutnya yaitu kita harus membuat cluster role nya, dimana akan mendefinisikan akan seperti apa user Asep pada Kubernetes klaster ini. Untuk itu buatlah file bernama cluster_role.yml lalu isikan seperti dibawah ini

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: deployment-role-asep
rules:
  - apiGroups: [ apps ]
    resources: [ deployments ]
    verbs: [ get, list ]

Simpan dan jalankan dengan perintah kubectl apply -f cluster_role.yml

Membuat RoleBinding

Setelah itu kita perlu membuat RoleBinding yang berarti bahwa user Asep perlu membuat dua RoleBinding untuk otorisasinya di dalam sisi Clusternya. Untuk membuatnya kita bisa membuat file role_binding.yml dan isikan seperti dibawah ini:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: asep-edit
subjects:
- kind: User
  name: asep
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: edit
  apiGroup: rbac.authorization.k8s.io

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: asep-view
subjects:
- kind: User
  name: asep
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: view
  apiGroup: rbac.authorization.k8s.io

Simpan dan jalankan dengan perintah kubectl apply -f role_binding.yml

Pengetesan

Semua langkah telah kita laksanakan, sekarang tinggal melakukan pengetesan. Seperti yang tadi di sebutkan user Asep hanya bisa melihat Deployment dan juga Pod pada namespace default. Oke tanpa berlama-lama mari kita coba, langkah awal yg harus kita lakukan adalah login ke user asep dan pastikan masuk ke home directorinya. Untuk perintah su - asep

Jika sudah seperti diatas kita bisa lanjut ke langkah pengetesanya, kita mulai dengan list semua Pod yang berjalan dengan perintah kubectl get pod

Oke, list Pod berhasil, kita coba list Deployment dengan user asep. Untuk perintahnya adalah kubectl get deployment

Oke, list Deployment berhasil. Saatnya kita mencoba langkah yang cukup extream yaitu menghapus deployment dengan perintah kubectl delete deployment/simple-httpd-depl

Oke semua yang kita harapkan telah berhasil, sampai disini kita sudah sukses memberikan role pada user Asep. Oke mungkin cukup sekian dari saya mohon maaf bila banyak kesalahan sekian dan terima kasih

Write a comment