Menggunakan Otorisasi RBAC

Role-based access control (RBAC) atau kontrol akses berbasis rol adalah metode pengaturan akses ke sumber daya komputer atau jaringan berdasarkan rol pengguna individu dalam organisasimu.

Otorisasi RBAC menggunakan grup API rbac.authorization.k8s.io untuk mengendalikan keputusan otorisasi. Hal ini memungkinkanmu untuk mengonfigurasi kebijakan secara dinamis melalui API Kubernetes.

Untuk mengaktifkan RBAC, jalankan server API dengan flag --authorization-mode diatur dengan daftar yang dipisahkan koma yang menyertakan RBAC; sebagai contoh:

kube-apiserver --authorization-mode=Example,RBAC --other-options --more-options

Objek API

API RBAC mendeklarasikan empat jenis objek Kubernetes: Role, ClusterRole, RoleBinding dan ClusterRoleBinding. kamu bisa mendeskripsikan beberapa objek, atau mengubahnya menggunakan alat seperti kubectl, seperti objek Kubernetes lain.

Perhatian: Objek-objek ini, dengan disengaja, memaksakan pembatasan akses. Jika kamu melakukan perubahan ke klaster saat kamu belajar, lihat pencegahan eskalasi privilese dan bootstrapping untuk memahami bagaimana pembatasan tersebut dapat mencegah kamu melakukan beberapa perubahan.

Role dan ClusterRole

Sebuah Role RBAC atau ClusterRole memuat aturan yang mewakili sekumpulan izin. Izin bersifat aditif (tidak ada aturan "tolak").

Sebuah Role selalu mengatur izin dalam Namespace tertentu; ketika kamu membuat Role, kamu harus menentukan Namespace tempat Role tersebut berada.

ClusterRole, sebaliknya, adalah sumber daya tanpa Namespace. Sumber daya tersebut memiliki nama yang berbeda (Role dan ClusterRole) karena objek Kubernetes selalu harus menggunakan Namespace atau tanpa Namespace; tidak mungkin keduanya.

ClusterRole memiliki beberapa kegunaan. Kamu bisa menggunakan ClusterRole untuk:

1. mendefinisikan izin pada sumber daya dalam Namespace dan diberikan dalam sebuah Namespace atau lebih
2. mendefinisikan izin pada sumber daya dalam Namespace dan diberikan dalam seluruh Namespace
3. mendefinisikan izin pada sumber daya dalam lingkup klaster

Jika kamu ingin mendefinisikan sebuah rol dalam Namespace, gunakan Role; jika kamu ingin mendefinisikan rol di level klaster, gunakan ClusterRole.

Contoh Role

Berikut adalah contoh Role dalam Namespace bawaan yang dapat digunakan untuk memberikan akses baca pada Pod:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  Namespace: default
  name: pod-reader
rules:
- apiGroups: [""] # "" mengindikasikan grup API inti
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

Contoh ClusterRole

ClusterRole dapat digunakan untuk memberikan izin yang sama dengan Role. Karena ClusterRole memiliki lingkup klaster, kamu juga dapat menggunakannya untuk memberikan akses ke:

• sumber daya lingkup klaster (seperti Node)
• berbagai endpoint non-sumber daya (seperti /healthz)
• sumber daya Namespace (seperti Pod), di semua Namespace Sebagai contoh: kamu bisa menggunakan ClusterRole untuk memungkinkan pengguna tertentu untuk menjalankan kubectl get pods --all-namespaces.

Berikut adalah contoh ClusterRole yang dapat digunakan untuk memberikan akses baca pada Secret di Namespace tertentu, atau di semua Namespace (tergantung bagaimana keterikatannya):

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  # "namespace" dihilangkan karena ClusterRole tidak menggunakan Namespace
  name: secret-reader
rules:
- apiGroups: [""]
  #
  # di tingkat HTTP, nama sumber daya untuk mengakses objek Secret
  # adalah "secrets"
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]

Nama objek Role dan ClusterRole harus menggunakan nama path segment yang valid.

RoleBinding dan ClusterRoleBinding

Sebuah RoleBinding memberikan izin yang ditentukan dalam sebuah Role kepada pengguna atau sekelompok pengguna. Ini menyimpan daftar subjek (pengguna, grup, atau ServiceAccount), dan referensi ke Role yang diberikan. RoleBinding memberikan izin dalam Namespace tertentu sedangkan ClusterRoleBinding memberikan akses tersebut pada lingkup klaster.

RoleBinding dapat merujuk Role apa pun di Namespace yang sama. Atau, RoleBinding dapat mereferensikan ClusterRole dan memasangkan ClusterRole tersebut ke Namespace dari RoleBinding. Jika kamu ingin memasangkan ClusterRole ke semua Namespace di dalam klastermu, kamu dapat menggunakan ClusterRoleBinding.

Nama objek RoleBinding atau ClusterRoleBinding harus valid menggunakan nama path segment yang valid.

Contoh RoleBinding

Berikut adalah contoh dari RoleBinding yang memberikan Role "pod-reader" kepada pengguna "jane" pada Namespace "default". Ini memungkinkan "jane" untuk membaca Pod di Namespace "default".

apiVersion: rbac.authorization.k8s.io/v1
# RoleBinding memungkinkan "jane" untuk membaca Pod di Namespace "default"
# Kamu harus sudah memiliki Role bernama "pod-reader" di Namespace tersebut.
kind: RoleBinding
metadata:
  name: read-pods
  namespace: default
subjects:
# Kamu bisa mencantumkan lebih dari satu "subjek"
- kind: User
  name: jane # "name" peka huruf besar-kecil
  apiGroup: rbac.authorization.k8s.io
roleRef:
  # "roleRef" menentukan pengikatan (binding) ke Role / ClusterRole
  kind: Role # ini harus Role atau ClusterRole
  name: pod-reader # ini harus sesuai dengan nama Role atau ClusterRole yang ingin kamu gunakan
  apiGroup: rbac.authorization.k8s.io

RoleBinding juga bisa mereferensikan ClusterRole untuk memberikan izin yang didefinisikan di dalam ClusterRole ke sumber daya di dalam Namespace RoleBinding. Referensi semacam ini memungkinkan kamu menentukan sekumpulan Role yang umum di seluruh klastermu, lalu menggunakannya kembali di dalam beberapa Namespace.

Sebagai contoh, meskipun RoleBinding berikut merujuk ke ClusterRole, "dave" (subjek, peka kapital) hanya akan dapat membaca Secret di dalam Namespace "development", karena Namespace RoleBinding (di dalam metadatanya) adalah "development".

apiVersion: rbac.authorization.k8s.io/v1
# RoleBinding memungkinkan "dave" untuk membaca Secret di Namespace "development".
# Kamu sudah harus memiliki ClusterRole bernama "secret-reader".
kind: RoleBinding
metadata:
  name: read-secrets
  #
  # Namespace dari RoleBinding menentukan di mana izin akan diberikan.  
  # Ini hanya memberikan izin di dalam Namespace "development".
  namespace: development
subjects:
- kind: User
  name: dave # Nama peka huruf besar-kecil
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

Contoh ClusterRoleBinding

Untuk memberikan izin di seluruh klaster, kamu dapat menggunakan ClusterRoleBinding. ClusterRoleBinding berikut memungkinkan seluruh pengguna di dalam kelompok "manager" untuk membaca Secret di berbagai Namespace.

apiVersion: rbac.authorization.k8s.io/v1
# ClusterRoleBinding ini memungkinkan siapapun di dalam kelompok "manager" untuk membaca Secret di berbagai Namespace.
kind: ClusterRoleBinding
metadata:
  name: read-secrets-global
subjects:
- kind: Group
  name: manager # Nama peka kapital
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

Setelah kamu membuat ClusterRoleBinding, kamu tidak dapat mengganti Role atau ClusterRole yang dirujuk. Jika kamu mencoba mengganti roleRef dari sebuah ClusterRoleBinding, kamu akan mendapatkan galat validasi. Jika kamu tidak ingin mengganti roleRef untuk sebuah ClusterRoleBinding, kamu harus menghapus objek ClusterRoleBinding tersebut dan membuat sebuah pengganti.

Ada dua alasan untuk pembatasan tersebut:

1. Membuat roleRef menjadi tidak dapat diubah (immutable) memungkinkan pemberian izin update kepada seseorang pada objek ClusterRoleBinding yang ada, sehingga mereka dapat mengelola daftar subjek, tanpa bisa berubah Role yang diberikan kepada subjek tersebut.

2. ClusterRoleBinding dengan Role yang berbeda adalah ClusterRoleBinding yang berbeda secara fundamental. Mengharuskan sebuah ClusterRoleBinding untuk dihapus/diciptakan kembali untuk mengubah roleRef akan memastikan daftar lengkap subjek dalam ClusterRoleBinding akan diberikan Role baru (sebagai langkah untuk mencegah modifikasi secara tidak sengaja hanya pada roleRef tanpa memastikan semua subjek yang seharusnya diberikan izin pada Role baru).

Utilitas baris perintah kubectl auth reconcile membuat atau memperbarui berkas manifes yang mengandung objek RBAC, dan menangani penghapusan dan pembuatan objek ikatan jika dibutuhkan untuk mengganti Role yang dirujuk. Lihat penggunaan perintah dan contoh untuk informasi tambahan.

Mengacu pada sumber daya

Pada API Kubernetes, sebagian besar sumber daya diwakili dan diakses menggunakan representasi nama objek, seperti pods untuk Pod. RBAC mengacu pada sumber daya yang menggunakan nama yang persis sama dengan yang muncul di URL untuk berbagai endpoint API yang relevan. Beberapa Kubernetes APIs melibatkan subresource, seperti log untuk Pod. Permintaan untuk log Pod terlihat seperti:

GET /api/v1/namespaces/{namespace}/pods/{name}/log

Dalam hal ini, pods adalah sumber daya Namespace untuk sumber daya Pod, dan log adalah sebuah sub-sumber daya pods. Untuk mewakili ini dalam sebuah Role RBAC, gunakan garis miring (/) untuk membatasi sumber daya dan sub-sumber daya. Untuk memungkinkan subjek membaca pods dan juga mengakses sub-sumber daya log untuk masing-masing Pod tersebut, kamu dapat menulis:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-and-pod-logs-reader
rules:
- apiGroups: [""]
  resources: ["pods", "pods/log"]
  verbs: ["get", "list"]

Kamu juga dapat merujuk ke sumber daya dengan nama untuk permintaan tertentu melalui daftar resourceNames. Ketika nama dicantumkan, permintaan dapat dibatasi untuk setiap objek sumber daya. Berikut adalah contoh yang membatasi subjeknya hanya untuk melakukan get atau update pada sebuah ConfigMap bernama my-configmap:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: configmap-updater
rules:
- apiGroups: [""]
  #
  # pada level HTTP, nama sumber daya untuk mengakses objek ConfigMap
  # adalah "configmaps"
  resources: ["configmaps"]
  resourceNames: ["my-configmap"]
  verbs: ["update", "get"]

Catatan: Kamu tidak dapat membatasi permintaan create atau deletecollection dengan nama sumber daya. Untuk create, keterbatasan ini dikarenakan nama objek tidak diketahui pada waktu otorisasi.

ClusterRole gabungan

Kamu dapat mengumpulkan beberapa ClusterRole menjadi satu ClusterRole gabungan. Pengontrol, yang berjalan sebagai bagian dari control plane klaster, mengamati objek ClusterRole dengan aggregationRule. AggregationRule mendefinisikan Selector label yang digunakan oleh pengontrol untuk mencocokkan objek ClusterRole lain yang harus digabungkan ke dalam rules.

Berikut adalah contoh ClusterRole gabungan:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: monitoring
aggregationRule:
  clusterRoleSelectors:
  - matchLabels:
      rbac.example.com/aggregate-to-monitoring: "true"
rules: [] # Control plane secara otomatis mengisi rules

Jika kamu membuat ClusterRole baru yang cocok dengan label Selector dari ClusterRole gabungan yang ada, maka perubahan itu akan memicu penambahan aturan baru ke dalam ClusterRole gabungan. Berikut adalah contoh yang menambahkan aturan ke ClusterRole "monitoring", dengan membuat sebuah ClusterRole lain berlabel rbac.example.com/aggregate-to-monitoring: true.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: monitoring-endpoints
  labels:
    rbac.example.com/aggregate-to-monitoring: "true"
# ketika kamu membuat ClusterRole "monitoring-endpoints",
# aturan di bawah ini akan ditambahkan ke ClusterRole "monitoring".
rules:
- apiGroups: [""]
  resources: ["services", "endpoints", "pods"]
  verbs: ["get", "list", "watch"]

Role bawaan pengguna menggunakan agregasi ClusterRole. Ini memungkinkan kamu, sebagai administrator klaster, menambahkan aturan untuk sumber daya ubah suai, seperti yang dilayani oleh CustomResourceDefinitions atau server API gabungan, untuk memperluas Role bawaan.

Sebagai contoh: ClusterRole berikut mengizinkan Role bawaan "admin" dan "edit" mengelola sumber daya ubah suai bernama CronTab, sedangkan Role "view" hanya dapat membaca sumber daya CronTab. Kamu dapat mengasumsikan bahwa objek CronTab dinamai "crontab" dalam URL yang terlihat oleh server API.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: aggregate-cron-tabs-edit
  labels:
    # Tambahkan izin berikut ke Role bawaan "admin" and "edit".
    rbac.authorization.k8s.io/aggregate-to-admin: "true"
    rbac.authorization.k8s.io/aggregate-to-edit: "true"
rules:
- apiGroups: ["stable.example.com"]
  resources: ["crontabs"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: aggregate-cron-tabs-view
  labels:
    # Tambahkan izin berikut ke Role bawaan "view"    
    rbac.authorization.k8s.io/aggregate-to-view: "true"
rules:
- apiGroups: ["stable.example.com"]
  resources: ["crontabs"]
  verbs: ["get", "list", "watch"]

Contoh Role

Contoh berikut adalah potongan dari objek Role atau ClusterRole yang hanya menampilkan bagian rules.

Mengizinkan pembacaan sumber daya "pods" pada grup API inti:

rules:
- apiGroups: [""]
  #
  # pada tingkat HTTP, nama dari sumber daya untuk mengakses objek Pod
  # adalah "pods"
  resources: ["pods"]
  verbs: ["get", "list", "watch"]

Mengizinkan pembacaan/penulisan Deployment (pada tingkat HTTP: objek dengan "deployments" di bagian sumber daya dari URL) pada masing-masing grup API "extensions" dan "apps":

rules:
- apiGroups: ["extensions", "apps"]
  #
  # pada tingkat HTTP, nama dari sumber daya untuk mengakses objek Deployment
  # adalah "deployments"
  resources: ["deployments"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

Mengizinkan pembacaan pada Pods pada grup API inti, dan juga serta pembacaan atau penulisan Job di grup API "batch" atau "extensions":

rules:
- apiGroups: [""]
  #
  # pada tingkat HTTP, nama dari sumber daya untuk mengakses objek Pod
  # adalah "pods"
  resources: ["pods"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["batch", "extensions"]
  #
  # pada tingkat HTTP, nama dari sumber daya untuk mengakses objek Job
  # adalah "jobs"
  resources: ["jobs"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

Mengizinkan pembacaan ConfigMap bernama "my-config" (harus terikat dengan suatu RoleBinding untuk membatasi ke satu ConfigMap di satu Namespace):

rules:
- apiGroups: [""]
  #
  # pada tingkat HTTP, nama dari sumber daya untuk mengakses objek ConfigMap
  # adalah "configmaps"  
  resources: ["configmaps"]
  resourceNames: ["my-config"]
  verbs: ["get"]

Mengizinkan pembacaan sumber daya "nodes" pada grup API inti (karena sebuah node ada pada lingkup-klaster, ini harus berupa ClusterRole yang terikat dengan ClusterRoleBinding agar efektif):

rules:
- apiGroups: [""]
  #
  # pada tingkat HTTP, nama dari sumber daya untuk mengakses objek Node
  # adalah "nodes"
  resources: ["nodes"]
  verbs: ["get", "list", "watch"]

Mengizinkan permintaan GET dan POST kepada endpoint non-sumber daya /healthz dan seluruh subpath (harus berada di dalam ClusterRole yang terikat dengan ClusterRoleBinding agar efektif):

rules:
- nonResourceURLs: ["/healthz", "/healthz/*"] # '*' in a nonResourceURL is a suffix glob match
  verbs: ["get", "post"]

Mengacu pada subjek

RoleBinding atau ClusterRoleBinding mengikat sebuah Role ke subjek. Subjek dapat berupa kelompok, pengguna atau ServiceAccounts.

Kubernetes merepresentasikan username sebagai string. Ini bisa berupa: nama sederhana, seperti "alice"; email, seperti "bob@example.com"; atau ID pengguna numerik yang direpresentasikan sebagai string. Terserah kamu sebagai administrator klaster untuk mengonfigurasi modul otentikasi sehingga otentikasi menghasilkan username dalam format yang kamu inginkan.

Perhatian: Awalan system: direservasi untuk sistem Kubernetes, jadi kamu harus memastikan bahwa kamu tidak memiliki pengguna atau grup dengan nama yang dimulai dengan system: secara tidak sengaja. Selain prefiks khusus ini, sistem otorisasi RBAC tidak memerlukan format apa pun untuk nama pengguna.

Di Kubernetes, modul otentikasi menyediakan informasi grup. Grup, seperti halnya pengguna, direpresentasikan sebagai string, dan string tersebut tidak memiliki format tertentu, selain prefiks system: yang sudah direservasi.

ServiceAccount memiliki nama yang diawali dengan system:serviceaccount:, dan menjadi milik grup yang diawali dengan nama system:serviceaccounts:.

Catatan:

• system:serviceaccount: (tunggal) adalah prefiks untuk username ServiceAccount.
• system:serviceaccounts: (jamak) adalah prefiks untuk grup ServiceAccount.

Contoh RoleBinding

Contoh-contoh berikut ini hanya potongan RoleBinding yang hanya memperlihatkan bagian subjects.

Untuk pengguna bernama alice@example.com:

subjects:
- kind: User
  name: "alice@example.com"
  apiGroup: rbac.authorization.k8s.io

Untuk grup bernama frontend-admins:

subjects:
- kind: Group
  name: "frontend-admins"
  apiGroup: rbac.authorization.k8s.io

Untuk ServiceAccount bawaan di Namespace "kube-system":

subjects:
- kind: ServiceAccount
  name: default
  namespace: kube-system

Untuk seluruh ServiceAccount di Namespace qa:

subjects:
- kind: Group
  name: system:serviceaccounts:qa
  apiGroup: rbac.authorization.k8s.io

Untuk seluruh ServiceAccount di Namespace apapun:

subjects:
- kind: Group
  name: system:serviceaccounts
  apiGroup: rbac.authorization.k8s.io

Untuk seluruh pengguna yang terotentikasi:

subjects:
- kind: Group
  name: system:authenticated
  apiGroup: rbac.authorization.k8s.io

Untuk seluruh pengguna yang tidak terotentikasi:

subjects:
- kind: Group
  name: system:unauthenticated
  apiGroup: rbac.authorization.k8s.io

Untuk seluruh pengguna:

subjects:
- kind: Group
  name: system:authenticated
  apiGroup: rbac.authorization.k8s.io
- kind: Group
  name: system:unauthenticated
  apiGroup: rbac.authorization.k8s.io

Role dan RoleBinding bawaan

API membuat satu set objek ClusterRole dan ClusterRoleBinding bawaan. Sebagian besar dari objek dengan prefiks system: menunjukkan bahwa sumber daya tersebut secara langsung dikelola oleh control plane klaster. Seluruh ClusterRole dan ClusterRoleBinding dilabeli dengan kubernetes.io/bootstrapping=rbac-defaults.

Perhatian: Berhati-hatilah saat memodifikasi CLusterRole dan ClusterRoleBinding dengan nama yang memiliki prefiks system:. Modifikasi sumber daya ini dapat mengakibatkan malfungsi klaster.

Rekonsiliasi otomatis

Pada setiap penyalaan (start-up), server API memperbarui ClusterRole bawaan dengan berbagai izin yang hilang, dan memperbarui ClusterRoleBinding bawaan dengan subjek yang hilang. Ini memungkinkan klaster untuk memperbaiki modifikasi yang tidak disengaja, dan membantu menjaga Role dan RoleBinding selalu terkini karena izin dan subjek berubah pada rilis terbaru Kubernetes.

Untuk menonaktifkan rekonsiliasi ini, atur anotasi rbac.authorization.kubernetes.io/autoupdate pada ClusterRole bawaan atau RoleBinding bawaan menjadi false. Ingat bahwa hilangnya izin dan subjek bawaan dapat mengakibatkan malfungsi klaster.

Rekonsiliasi otomatis diaktifkan secara bawaan jika pemberi otorisasi RBAC aktif.

Role diskoveri API

RoleBinding bawaan memberi otorisasi kepada pengguna yang tidak terotentikasi untuk membaca informasi API yang dianggap aman untuk diakses publik (termasuk CustomResourceDefinitions). Untuk menonaktifkan akses anonim, tambahkan --anonymous-auth=false ke konfigurasi server API.

Untuk melihat konfigurasi Role ini melalui kubectl jalankan perintah:

kubectl get clusterroles system:discovery -o yaml

Catatan: Jika kamu mengubah ClusterRole tersebut, maka perubahanmu akan ditimpa pada penyalaan ulang server API melalui rekonsiliasi-otomatis. Untuk menghindari penulisan ulang tersebut, hindari mengubah Role secara manual, atau nonaktifkan rekonsiliasi otomatis

Role pengguna

Beberapa ClusterRole bawaan tidak diawali dengan system:. Ini dimaksudkan untuk Role pengguna. Ini termasuk Role super-user (cluster-admin), Role yang dimaksudkan untuk diberikan akses seluruh klaster dengan menggunakan ClusterRoleBinding, dan Role yang dimaksudkan untuk diberikan pada Namespace tertentu dengan menggunakan RoleBinding (admin, edit, view).

ClusterRole menggunakan ClusterRole gabungan untuk mengizinkan administrator untuk memasukan peraturan untuk sumber daya khusus pada ClusterRole ini. Untuk menambahkan aturan kepada Role admin, edit, atau view, buatlah sebuah CLusterRole dengan satu atau lebih label berikut:

metadata:
  labels:
    rbac.authorization.k8s.io/aggregate-to-admin: "true"
    rbac.authorization.k8s.io/aggregate-to-edit: "true"
    rbac.authorization.k8s.io/aggregate-to-view: "true"

Role komponen inti

Role komponen lainnya

Role untuk pengontrol bawaan

kube-controller-manager pada Kubernetes menjalankan pengontrol yang merupakan bawaan dari control plane Kubernetes. Ketika dijalankan dengan --use-service-account-credentials, kube-controller-manager memulai setiap pengontrol menggunakan ServiceAccount yang terpisah. Role yang sesuai tersedia untuk setiap pengontrol bawaan, dengan prefiks system:controller:. Jika manajer pengontrol tidak dimulai dengan --use-service-account-credentials, maka manajer pengontrol akan menjalankan semua kontrol tertutup (control loop) menggunakan kredensialnya sendiri, yang harus diberikan semua Role yang relevan. Role yang dimaksud termasuk:

• system:controller:attachdetach-controller
• system:controller:certificate-controller
• system:controller:clusterrole-aggregation-controller
• system:controller:cronjob-controller
• system:controller:daemon-set-controller
• system:controller:deployment-controller
• system:controller:disruption-controller
• system:controller:endpoint-controller
• system:controller:expand-controller
• system:controller:generic-garbage-collector
• system:controller:horizontal-pod-autoscaler
• system:controller:job-controller
• system:controller:namespace-controller
• system:controller:node-controller
• system:controller:persistent-volume-binder
• system:controller:pod-garbage-collector
• system:controller:pv-protection-controller
• system:controller:pvc-protection-controller
• system:controller:replicaset-controller
• system:controller:replication-controller
• system:controller:resourcequota-controller
• system:controller:root-ca-cert-publisher
• system:controller:route-controller
• system:controller:service-account-controller
• system:controller:service-controller
• system:controller:statefulset-controller
• system:controller:ttl-controller

Pencegahan eskalasi privilese dan bootstrapping

API RBAC mencegah pengguna dari mengeskalasikan privilese dengan mengubah Role atau RoleBinding. Karena hal ini diberlakukan pada level API, maka hal ini berlaku bahkan ketika pemberi otorisasi RBAC tidak digunakan.

Pembatasan pada pembuatan dan pembaruan Role

Kamu hanya bisa membuat/memperbaru suatu Role jika setidaknya satu dari beberapa hal di bawah ini terpenuhi:

1. Kamu telah mempunyai semua izin yang termuat dalam Role tersebut, pada lingkup yang sama dengan objek yang diubah (di seluruh klaster untuk sebuah ClusterRole, di dalam Namespace yang sama atau keseluruhan klaster untuk sebuah Role).
2. Kamu diberikan izin eksplisit untuk melakukan escalate pada sumber daya roles atau clusterroles di dalam grup API rbac.authorization.k8s.io.

Sebagai contoh, jika user-1 tidak memiliki kemampuan untuk mendaftar Secret di seluruh klaster, maka user-1 tidak akan bisa membuat suatu ClusterRole yang memuat izin tersebut. Agar pengguna bisa membuat/memperbaru Role:

1. Berikan sebuah Role yang memungkinkan mereka untuk membuat/memperbarui objek Role atau CLusterRole, sesuai keinginan.
2. Berikan mereka izin untuk menyertakan izin tertentu dalam Role yang mereka buat/perbarui:
   • secara implisit, dengan memberikan mereka izin tersebut (jika mereka mencoba untuk membuat atau mengubah sebuah Role atau ClusterRole dengan izin yang tidak mereka miliki, permintaan API akan dilarang)
   • atau secara eksplisit mengizinkan penentuan izin apa pun dalam sebuah Role atau ClusterRole dengan memberikan mereka izin untuk melakukan escalate pada sumber daya roles atau clusterroles di dalam grup API rbac.authorization.k8s.io

Pembatasan pada pembuatan dan pembaruan RoleBinding

Kamu hanya bisa membuat/memperbarui suatu RoleBinding jika kamu telah mempunyai semua izin yang terdapat pada Role yang diacu (di dalam lingkup yang sama dengan RoleBinding) atau jika kamu telah terotorisasi untuk melakukan bind pada role yang diacu. Sebagai contoh, jika user-1 tidak mempunyai kemampuan untuk mendaftar Secret di seluruh klaster, maka user-1 tidak akan bisa membuat sebuah ClusterRoleBinding dengan Role yang memberikan izin tersebut. Agar pengguna bisa membuat/memperbarui RoleBinding:

1. Berikan sebuah Role yang mengizinkan mereka untuk membuat/memperbarui objek RoleBinding atau ClusterRoleBinding, sesuai keinginan.
2. Berikan mereka izin yang dibutuhkan untuk RoleBinding tertentu:
   • secara implisit, dengan memberikan mereka izin yang yang termuat pada Role yang dimaksud
   • secara eksplisit, dengan memberikan mereka izin untuk melakukan bind pada Role (atau ClusterRole) tertentu

Sebagai contoh, ClusterRole dan RoleBinding berikut akan memungkinkan user-1 untuk memberikan Role admin, edit, dan view kepada pengguna lain di dalam Namespace user-1-namespace:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: role-grantor
rules:
- apiGroups: ["rbac.authorization.k8s.io"]
  resources: ["rolebindings"]
  verbs: ["create"]
- apiGroups: ["rbac.authorization.k8s.io"]
  resources: ["clusterroles"]
  verbs: ["bind"]
  resourceNames: ["admin","edit","view"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: role-grantor-binding
  namespace: user-1-namespace
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: role-grantor
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: user-1

Ketika melakukan bootstrapping Role dan RoleBinding yang pertama, pengguna awal perlu memberikan izin yang belum mereka miliki. Untuk melakukan bootstrapping Role dan RoleBinding awal:

• Gunakan kredensial dengan grup "system:masters" yang terikat ke Role super-user "cluster-admin" oleh RoleBinding bawaan.
• Jika server API dijalankan dengan porta tidak aman diaktifkan (--insecure-port), kamu juga bisa membuat panggilan API via porta tersebut, yang tidak memberlakukan otentikasi atau otorisasi.

Utilitas baris perintah

kubectl create role

Membuat sebuah objek Role yang mendefinisikan izin di dalam sebuah Namespace. Contoh:

• Membuat sebuah Role bernama "pod-reader" yang memungkinkan pengguna untuk melakukan get, watch dan list pada Pod:

  kubectl create role pod-reader --verb=get --verb=list --verb=watch --resource=pods
  

• Membuat sebuah Role bernama "pod-reader" dengan resourceNames yang ditentukan:

  kubectl create role pod-reader --verb=get --resource=pods --resource-name=readablepod --resource-name=anotherpod
  

• Membuat sebuah Role bernama "foo" dengan apiGroups yang ditentukan:

  kubectl create role foo --verb=get,list,watch --resource=replicasets.apps
  

• Membuat sebuah Role bernama "foo" dengan izin sub-sumber daya:

  kubectl create role foo --verb=get,list,watch --resource=pods,pods/status
  

• Membuat sebuah Role bernama "my-component-lease-holder" dengan izin untuk mendapatkan/memperbarui suatu sumber daya dengan nama tertentu:

  kubectl create role my-component-lease-holder --verb=get,list,watch,update --resource=lease --resource-name=my-component
  

kubectl create clusterrole

Membuat sebuah ClusterRole. Contoh:

• Membuat sebuah ClusterRole bernama "pod-reader" yang memungkinkan pengguna untuk merlakukan get, watch dan list pada Pod:

  kubectl create clusterrole pod-reader --verb=get,list,watch --resource=pods
  

• Membuat sebuah ClusterRole bernama "pod-reader" dengan recourceNames yang ditentukan:

  kubectl create clusterrole pod-reader --verb=get --resource=pods --resource-name=readablepod --resource-name=anotherpod
  

• Membuat sebuah ClusterRole bernama "foo" dengan apiGroups yang ditentukan:

  kubectl create clusterrole foo --verb=get,list,watch --resource=replicasets.apps
  

• Membuat sebuah ClusterRole bernama "foo" dengan izin sub-sumber daya:

  kubectl create clusterrole foo --verb=get,list,watch --resource=pods,pods/status
  

• Membuat sebuah ClusterRole bernama "foo" dengan nonResourceURL yang ditentukan:

  kubectl create clusterrole "foo" --verb=get --non-resource-url=/logs/*
  

• Membuat sebuah ClusterRole bernama "monitoring" dengan aggregationRule yang ditentukan:

  kubectl create clusterrole monitoring --aggregation-rule="rbac.example.com/aggregate-to-monitoring=true"
  

kubectl create rolebinding

Memberikan sebuah Role atau ClusterRole di dalam Namespace tertentu. Contoh:

• Di dalam Namespace "acme", memberikan izin dalam ClusterRole "admin" kepada pengguna bernama "bob":

  kubectl create rolebinding bob-admin-binding --clusterrole=admin --user=bob --namespace=acme
  

• Di dalam Namespace "acme", memberikan izin dalam ClusterRole "view" ke ServiceAccount di dalam Namespace "acme" yang bernama "myapp":

  kubectl create rolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp --namespace=acme
  

• Di dalam Namespace "acme", memberikan izin dalam ClusterRole "view" ke ServiceAccount di dalam Namespace "myappnamespace" yang bernama "myapp":

  kubectl create rolebinding myappnamespace-myapp-view-binding --clusterrole=view --serviceaccount=myappnamespace:myapp --namespace=acme
  

kubectl create clusterrolebinding

Memberikan sebuah ClusterRole di seluruh klaster (semua Namespace). Contoh:

• Di seluruh klaster, memberikan izin dalam ClusterRole "cluster-admin" kepada pengguna bernama "root":

  kubectl create clusterrolebinding root-cluster-admin-binding --clusterrole=cluster-admin --user=root
  

• Di seluruh klaster, memberikan izin dalam ClusterRole "system:node-proxier" kepada user bernama "system:kube-proxy":

  kubectl create clusterrolebinding kube-proxy-binding --clusterrole=system:node-proxier --user=system:kube-proxy
  

• Di seluruh klaster, memberikan izin dalam ClusterRole "view" ke ServiceAccount bernama "myapp" di dalam Namespace "acme":

  kubectl create clusterrolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp
  

kubectl auth reconcile

Membuat atau memperbarui objek API rbac.authorization.k8s.io/v1 dari suatu berkas manifes.

Objek yang hilang dibuat, dan Namespace dibuat untuk objek dengan Namespace jika diperlukan.

Role yang sudah ada diperbarui untuk menyertakan izin pada objek masukan, dan menghilangkan izin tambahan jika --remove-extra-permissions ditetapkan.

RoleBinding yang sudah ada diperbarui untuk menyertakan subjek pada objek masukan, dan menghapus subjek tambahan jika --remove-extra-subjects ditetapkan.

Contoh:

• Mencoba menerapkan sebuah berkas manifes dari objek RBAC, menampilkan perubahan yang akan dibuat:

  kubectl auth reconcile -f my-rbac-rules.yaml --dry-run=client
  

• Menerapkan sebuah berkas manifes dari objek RBAC, mempertahankan izin tambahan (dalam Role) dan subjek tambahan (dalam RoleBinding):

  kubectl auth reconcile -f my-rbac-rules.yaml
  

• Menerapkan sebuah berkas manifes dari objek RBAC, menghapus izin tambahan (dalam Role) dan subjek tambahan (dalam RoleBinding):

  kubectl auth reconcile -f my-rbac-rules.yaml --remove-extra-subjects --remove-extra-permissions
  

Izin ServiceAccount

Kebijakan RBAC bawaan memberikan izin terbatas ke komponen control plane, Node, dan pengontrol, akan tetapi tidak memberikan izin ke ServiceAccount di luar Namespace kube-system (di luar izin diskoveri yang diberikan kepada semua pengguna terotentikasi).

Hal ini memungkinkan kamu untuk memberika Role tertentu ke ServiceAccount tertentu sesuai kebutuhan. RoleBinding yang sangat detail memberikan keamanan yang lebih baik, akan tetapi membutuhkan lebih banyak usaha untuk pengaturannya. Pemberian izin yang lebih luas dapat memberikan akses API yang tidak perlu (dan berpotensi tereskalasi) ke ServiceAccount, akan tetapi pengaturannya lebih mudah.

Dalam urutan dari yang paling aman ke yang paling tidak aman, pendekatannya adalah:

1. Memberikan sebuah Role ke ServiceAccount aplikasi tertentu (praktik terbaik)

   Hal ini membutuhkan aplikasi untuk menentukan sebuah serviceAccountName di dalam spesifikasi Pod-nya, dan untuk ServiceAccount yang akan dibuat (via API, manifes aplikasi, kubectl create serviceaccount, dan lain-lain).

   Sebagai contoh, untuk memberikan izin hanya baca (read-only) di dalam "my-namespace" ke ServiceAccount "my-sa":

   kubectl create rolebinding my-sa-view \
     --clusterrole=view \
     --serviceaccount=my-namespace:my-sa \
     --namespace=my-namespace
   

2. Memberikan sebuah Role ke ServiceAccount "default" di dalam suatu Namespace

   Jika sebuah aplikasi tidak menetapkan serviceAccountName, aplikasi tersebut akan menggunakan ServiceAccount "default".

   Catatan: Izin yang diberikan ke ServiceAccount "default" tersedia ke Pod apa pun di dalam Namespace yang tidak menetapkan serviceAccountName.

   Sebagai contoh, untuk memberikan izin hanya baca di dalam "my-namespace" ke ServiceAccount "default":

   kubectl create rolebinding default-view \
     --clusterrole=view \
     --serviceaccount=my-namespace:default \
     --namespace=my-namespace
   

   Banyak pugasan berjalan sebagai ServiceAccount "default" di dalam Namespace kube-system. Untuk mengizinkan pugasan tersebut berjalan dengan akses super-user, berikan izin cluster-admin kepada ServiceAccount "default" di dalam Namespace kube-system.

   Perhatian: Mengaktifkan ini berarti Namespace kube-system memuat Secret yang memberikan akses super-user ke API klastermu.

   kubectl create clusterrolebinding add-on-cluster-admin \
     --clusterrole=cluster-admin \
     --serviceaccount=kube-system:default
   

3. Memberikan Role ke semua ServiceAccount dalam suatu Namespace

   Jika kamu ingin semua aplikasi di dalam satu Namespace untuk memiliki Role, apa pun ServiceAccount yang digunakan, maka kamu dapat memberikan Role ke grup ServiceAccount untuk Namespace tersebut.

   Sebagai contoh, untuk memberikan izin hanya baca di dalam "my-namespace" ke semua ServiceAccount di dalam Namespace tersebut:

   kubectl create rolebinding serviceaccounts-view \
     --clusterrole=view \
     --group=system:serviceaccounts:my-namespace \
     --namespace=my-namespace
   

4. Memberikan Role terbatas ke semua ServiceAccount di seluruh klaster (tidak disarankan)

   Jika kamu tidak ingin untuk mengelola izin per Namespace, kamu bisa memberikan Role yang berlaku di seluruh klaster kepada semua ServiceAccount.

   Sebagai contoh, untuk memberikan akses hanya baca di semua Namespace untuk semua ServiceAccount yang ada di klaster:

   kubectl create clusterrolebinding serviceaccounts-view \
     --clusterrole=view \
    --group=system:serviceaccounts
   

5. Memberikan akses super-user ke semua ServiceAccount di seluruh klaster (sangat tidak disarankan)

   Jika kamu tidak peduli untuk melakukan partisi terhadap izin sama sekali, maka kamu bisa memberikan akses super-user ke semua ServiceAccount.

   Peringatan: Hal ini akan memberikan akses penuh untuk aplikasi apapun ke klastermu, dan juga memberikan pengguna manapun dengan akses baca ke Secret (atau kemampuan untuk membuat Pod apa pun) akses penuh ke klastermu.

   kubectl create clusterrolebinding serviceaccounts-cluster-admin \
     --clusterrole=cluster-admin \
     --group=system:serviceaccounts
   

Melakukan peningkatan dari ABAC

Klaster yang awalnya menjalankan versi Kubernetes lawas sering kali menggunakan kebijakan ABAC yang permisif, termasuk memberikan akses API penuh ke semua ServiceAccount.

Kebijakan RBAC bawaan memberikan izin yang terbatas ke komponen control plane, Node, dan pengontrol, akan tetapi tidak memberikan izin ke ServiceAccount di luar Namespace kube-system (di luar izin diskoveri yang diberikan kepada semua pengguna terotentikasi).

Meskipun jauh lebih aman, hal ini dapat mengganggu beban kerja yang sudah ada yang mengharapkan untuk menerima izin API secara otomatis. Berikut adalah dua pendekatan untuk mengelola transisi ini:

Pemberi otorisasi paralel

Jalankan pemberi otorisasi RBAC dan ABAC bersamaan, dan tentukan berkas kebijakan yang memuat kebijakan ABAC lama:

--authorization-mode=...,RBAC,ABAC --authorization-policy-file=mypolicy.json

Untuk menjelaskan opsi baris perintah yang pertama secara detail: jika pemberi otorisasi sebelumnya, seperti Node, menolak permintaan, maka pemberi otorisasi RBAC mencoba untuk mengotorisasi permintaan API tersebut. Jika RBAC juga menolak permintaan API tersebut, maka pemberi otorisasi ABAC akan dijalankan. Hal ini berarti permintaan apa pun yang diizinkan oleh salah satu kebijakan RBAC atau ABAC akan diizinkan.

Ketika kube-apiserver dijalankan dengan level log 5 atau lebih tinggi untuk komponen RBAC (--vmodule=rbac*=5 atau --v=5), kamu dapat melihat penolakan RBAC di log server API (dengan prefiks RBAC). Kamu dapat menggunakan informasi tersebut untuk menentukan Role mana yang perlu diberikan ke pengguna, grup, atau ServiceAccount yang mana.

Jika kamu telah memberikan Role ke ServiceAccount dan beban kerja sedang berjalan tanpa pesan penolakan RBAC dalam log server, maka kamu dapat menghapus pemberi otorisasi ABAC.

Izin RBAC permisif

Kamu dapat mereplikasi kebijakan ABAC yang permisif dengan menggunakan RoleBinding RBAC.

Peringatan:

Kebijakan berikut mengizinkan SEMUA ServiceAccount bentindak sebagai administrator klaster. Aplikasi apa pun yang berjalan di dalam Container akan menerima kredensial ServiceAccount secara otomatis, dan dapat melakukan tindakan apa pun terhadap API, termasuk menampilkan Secret dan mengubah izin. Hal ini bukan kebijakan yang direkomendasikan.

kubectl create clusterrolebinding permissive-binding \
  --clusterrole=cluster-admin \
  --user=admin \
  --user=kubelet \
  --group=system:serviceaccounts

Setelah kamu beralih menggunakan RBAC, kamu harus menyesuaikan kontrol akses untuk klastermu untuk memastikan bahwa kesemuanya memenuhi kebutuhanmu terkait keamanan informasi.