Mengizinkan tindakan dalam cluster menggunakan role-based access control

Halaman ini menunjukkan cara mengizinkan tindakan pada resource di cluster Google Kubernetes Engine (GKE) Anda menggunakan mekanisme role-based access control (RBAC) bawaan di Kubernetes.

RBAC adalah fitur keamanan inti di Kubernetes yang memungkinkan Anda membuat izin terperinci untuk mengelola tindakan yang dapat dilakukan pengguna dan workload pada resource dalam cluster Anda. Sebagai administrator platform, Anda membuat peran RBAC dan mengikat peran tersebut ke subject, yang merupakan pengguna terautentikasi seperti akun layanan atau Grup. RBAC Kubernetes diaktifkan secara default.

Sebelum memulai

Sebelum memulai, pastikan Anda telah menjalankan tugas berikut:

  • Aktifkan Google Kubernetes Engine API.
    • Aktifkan Google Kubernetes Engine API
  • Jika ingin menggunakan Google Cloud CLI untuk tugas ini, instal lalu lakukan inisialisasi gcloud CLI. Jika sebelumnya Anda telah menginstal gcloud CLI, dapatkan versi terbaru dengan menjalankan gcloud components update.

Interaksi dengan Identity and Access Management

Anda dapat menggunakan Identity and Access Management (IAM) dan RBAC Kubernetes untuk mengontrol akses ke cluster GKE:

  • IAM tidak spesifik pada Kubernetes; sistem ini menyediakan pengelolaan identitas untuk beberapa produk Google Cloud, dan beroperasi terutama di tingkat project Google Cloud.

  • RBAC Kubernetes adalah komponen inti Kubernetes untuk membuat dan memberikan peran (serangkaian izin) untuk objek atau jenis objek di dalam cluster.

  • Untuk mengizinkan tindakan, GKE memeriksa kebijakan RBAC terlebih dahulu. Jika tidak ada kebijakan RBAC, GKE akan memeriksa izin IAM.

Di GKE, IAM dan RBAC Kubernetes terintegrasi untuk mengizinkan pengguna melakukan tindakan jika mereka memiliki izin yang memadai sesuai dengan salah satu alat tersebut. Ini adalah bagian penting dalam bootstrap cluster GKE, karena secara default pengguna Google Cloud tidak memiliki RoleBindings RBAC Kubernetes.

Untuk memberikan otorisasi kepada pengguna menggunakan akun Google Cloud, klien harus dikonfigurasi dengan benar untuk mengautentikasi menggunakan akun tersebut terlebih dahulu. Misalnya, jika Anda menggunakan kubectl, Anda harus mengonfigurasi perintah kubectl untuk melakukan autentikasi ke Google Cloud sebelum menjalankan perintah yang memerlukan otorisasi.

Di hampir semua kasus, RBAC Kubernetes dapat menggantikan IAM. Pengguna GKE memerlukan setidaknya, izin IAM container.clusters.get dalam project yang berisi cluster. Izin ini disertakan dalam peran container.clusterViewer, dan peran lain dengan hak istimewa yang lebih tinggi. Izin container.clusters.get diperlukan pengguna untuk melakukan autentikasi ke cluster dalam project, tetapi tidak memberi otorisasi untuk melakukan tindakan apa pun di dalam klaster tersebut. Otorisasi kemudian dapat diberikan oleh IAM atau RBAC Kubernetes.

Menentukan dan menetapkan izin

Anda dapat menentukan aturan RBAC dalam objek ClusterRole dan Role, lalu menetapkan aturan tersebut dengan objek ClusterRoleBinding dan RoleBinding seperti berikut:

  • ClusterRole: pengelompokan operasi yang diizinkan dan resource tingkat cluster yang dapat Anda tetapkan ke pengguna atau grup menggunakan RoleBinding atau ClusterRoleBinding.
  • Peran: pengelompokan operasi yang diizinkan dan resource dengan namespace yang dapat Anda tetapkan ke satu atau sekelompok pengguna menggunakan RoleBinding.
  • ClusterRoleBinding: menetapkan ClusterRole ke pengguna atau grup untuk semua namespace di cluster.
  • RoleBinding: menetapkan Role atau ClusterRole ke pengguna atau grup di dalam namespace tertentu.

Saat Anda menggunakan RoleBinding untuk menetapkan ClusterRole ke pengguna atau grup, pengguna dan grup tersebut hanya dapat mengakses resource dalam namespace yang Anda tentukan di RoleBinding. Jika Anda ingin pengguna atau grup mengakses resource di semua namespace, gunakan ClusterRoleBinding.

Menentukan izin menggunakan Peran atau ClusterRoles

Anda menentukan izin dalam objek Role atau ClusterRole. Peran menentukan akses ke resource dalam satu Namespace, sedangkan ClusterRole menentukan akses ke resource di seluruh cluster.

Roles dan ClusterRoles memiliki sintaksis yang sama. Setiap sintaksis memiliki bagian rules, di mana Anda menentukan resource yang diterapkan aturan dan operasi yang diizinkan untuk Peran tersebut. Misalnya, Peran berikut memberikan akses baca (get, watch, dan list) ke semua pod di Namespace accounting:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: accounting
  name: pod-reader
rules:
- apiGroups: [""] # "" indicates the core API group
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

Lihat dokumentasi API Peran dan ClusterRole untuk mengetahui daftar lengkap kolom yang diizinkan.

Role vs ClusterRole

Karena izin yang diberikan ClusterRole berlaku di seluruh cluster, Anda dapat menggunakan ClusterRoles untuk mengontrol akses ke berbagai jenis resource daripada yang dapat Anda akses dengan Peran. Resource tersebut meliputi:

  • Resource cakupan cluster seperti node
  • Endpoint REST tanpa resource seperti /healthz
  • Resource namespace di semua namespace (misalnya, semua Pod di seluruh cluster, terlepas dari namespace)

Menetapkan Peran menggunakan RoleBindings atau ClusterRoleBindings

Setelah membuat Peran atau ClusterRole, tetapkan ke pengguna atau sekelompok pengguna dengan membuat RoleBinding atau ClusterRoleBinding. Pengguna dan grup disebut subjects, dan dapat berupa salah satu dari berikut ini:

Jenis subject Nilai untuk kind Nilai untuk name
Akun pengguna Google Cloud User Alamat email yang terdaftar di Google Cloud
Akun layanan Kubernetes ServiceAccount Nama objek ServiceAccount Kubernetes di cluster
Akun layanan IAM User Alamat email akun layanan IAM yang dibuat secara otomatis
Alamat Grup Google di domain terverifikasi Group Alamat email Grup Google Workspace yang merupakan anggota grup gke-security-groups. Untuk mengetahui petunjuk dalam menyiapkan Google Grup untuk RBAC, lihat Mengonfigurasi Google Grup untuk RBAC.

RoleBinding berikut memberikan Peran pod-reader kepada pengguna, akun layanan Kubernetes, akun layanan IAM, dan Grup Google:

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: pod-reader-binding
  namespace: accounting
subjects:
# Google Cloud user account
- kind: User
  name: janedoe@example.com
# Kubernetes service account
- kind: ServiceAccount
  name: johndoe
# IAM service account
- kind: User
  name: test-account@test-project.iam.gserviceaccount.com
# Google Group
- kind: Group
  name: accounting-group@example.com
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

Memverifikasi akses API menggunakan kubectl

kubectl menyediakan subperintah auth can-i untuk membuat kueri lapisan otorisasi API dengan cepat. Sebagai administrator platform, Anda mungkin perlu meniru identitas pengguna untuk menentukan tindakan yang dapat mereka lakukan. Anda dapat menggunakan auth can-i dan meneruskan flag --as tambahan.

Jika menjalankan perintah kubectl auth can-i tanpa flag --as, Identity and Access Management (IAM) akan melakukan otorisasi. Sedangkan jika Anda menambahkan flag --as, RBAC Kubernetes akan melakukan otorisasi. Oleh karena itu, Anda perlu membuat objek Role dan RoleBinding yang diperlukan RBAC.

Untuk informasi selengkapnya, lihat Memverifikasi Akses API.

Penggunaan dan Contoh API

Untuk mengetahui informasi lengkap tentang penggunaan Kubernetes API dalam membuat objek Role, ClusterRole, RoleBinding, dan ClusterRoleBinding yang diperlukan RBAC, lihat Menggunakan Otorisasi Role-Based Access Control dalam dokumentasi Kubernetes.

Pemecahan masalah dan proses debug

Untuk men-debug masalah dengan RBAC, gunakan Log audit aktivitas admin, yang diaktifkan di semua cluster secara default. Jika akses ke resource atau operasi ditolak karena izin tidak memadai, server API akan mencatat error RBAC DENY ke dalam log, beserta informasi tambahan seperti keanggotaan implisit dan eksplisit pengguna dalam grup. Jika Anda menggunakan Google Grup untuk RBAC, google groups akan muncul dalam pesan log.

Batasan

Bagian berikut menjelaskan interaksi yang mungkin tidak terlihat jelas saat menggunakan IAM dan RBAC Kubernetes.

Peran discovery default

Cluster dibuat dengan kumpulan ClusterRoles dan ClusterRoleBindings default. Permintaan yang dibuat dengan kredensial yang valid masuk ke grup system:authenticated, sedangkan permintaan lain masuk ke system:unauthenticated.

ClusterRole system:basic-user memungkinkan pengguna membuat SelfSubjectAccessReviews untuk menguji izin mereka di cluster. Peran system:discovery memungkinkan pengguna membaca discovery API, yang dapat menunjukkan informasi tentang CustomResourceDefinitions yang ditambahkan ke cluster.

Pengguna anonim (system:unauthenticated) menerima ClusterRole system:public-info-viewer, yang memberikan akses hanya baca ke /healthz dan /version API.

Untuk melihat endpoint API yang diizinkan ClusterRole system:discovery, jalankan perintah berikut:

kubectl get clusterroles system:discovery -o yaml

Error forbidden untuk akun layanan di instance VM Google Cloud

Error berikut dapat terjadi jika instance VM tidak memiliki cakupan userinfo-email:

Error from server (Forbidden): error when creating ... "role-name" is forbidden: attempt to grant extra privileges:...

Misalnya, anggap VM memiliki cakupan cloud-platform, tetapi tidak memiliki cakupan userinfo-email. Saat VM mendapatkan token akses, Google Cloud mengaitkan token tersebut dengan cakupan cloud-platform. Saat server Kubernetes API meminta identitas yang terkait dengan token akses ke Google Cloud, server akan menerima ID unik akun layanan, bukan email akun layanan.

Agar autentikasi berhasil, buat VM baru dengan cakupan userinfo-email atau buat binding peran baru yang menggunakan ID unik tersebut.

Untuk membuat instance VM baru dengan cakupan userinfo-email, jalankan perintah berikut:

gcloud compute instances create INSTANCE_NAME \
    --service-account SERVICE_ACCOUNT_EMAIL \
    --scopes userinfo-email

Untuk membuat binding peran baru yang menggunakan ID unik akun layanan untuk VM yang ada, lakukan langkah-langkah berikut:

  1. Identifikasi ID unik akun layanan:

    gcloud iam service-accounts describe SERVICE_ACCOUNT_EMAIL

    Misalnya, output berikut menampilkan uniqueId untuk akun layanan my-iam-account@somedomain.com:

    displayName: Some Domain IAM service account
email: my-iam-account@somedomain.com
etag: BwWWja0YfJA
name: projects/project-name/serviceAccounts/my-iam-account@somedomain.com
oauth2ClientId: '123456789012345678901'
projectId: project-name
uniqueId: '123456789012345678901'

  2. Buat binding peran dengan uniqueId akun layanan:

    kubectl create clusterrolebinding CLUSTERROLEBINDING_NAME \
    --clusterrole cluster-admin \
    --user UNIQUE_ID

Izin untuk membuat atau memperbarui peran dan binding peran

Di Kubernetes, Anda hanya dapat membuat atau memperbarui peran atau binding peran dengan izin tertentu jika memenuhi kondisi berikut:

  • Membuat atau memperbarui peran: Anda harus memiliki izin yang ingin Anda berikan ke peran tersebut. Atau, Anda harus memiliki otorisasi untuk menjalankan kata kerja escalate pada peran tersebut.
  • Membuat atau memperbarui binding peran: Anda harus memiliki izin yang diberikan ke peran yang terikat, dengan cakupan yang sama dengan binding peran. Atau, Anda harus memiliki otorisasi untuk menjalankan kata kerja bind pada peran yang dirujuk.

Jika izin yang Anda berikan pada peran awalnya diberikan kepada Anda menggunakan kebijakan izin IAM dan bukan RBAC, permintaan peran atau binding peran Anda mungkin gagal. Misalnya, pertimbangkan permintaan pembuatan peran berikut, dari pengguna yang telah diberi izin IAM container.pods.* dan container.roles.create:

kubectl create role allowed-to-view-pods --resource pods --verb list,get

Jika pengguna hanya diberi izin menggunakan IAM, error berikut dapat terjadi:

Error from server (Forbidden): clusterroles.rbac.authorization.k8s.io "allowed-to-view-pods" is forbidden:
user "caller@example.com" (groups=["system:authenticated"]) is attempting to grant RBAC permissions not currently held:
{APIGroups:[""], Resources:["pods"], Verbs:["list" "get"]}

Untuk memitigasi batasan ini, beri pemanggil izin dalam peran tersebut menggunakan RBAC, bukan IAM.

Anda juga dapat menggunakan RBAC atau IAM untuk memberikan kata kerja escalate, kata kerja bind, atau keduanya kepada pemanggil. Namun, GKE tidak merekomendasikan pendekatan ini, karena pemanggil akan dapat memberikan izin apa pun ke peran mana pun.

Langkah selanjutnya