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
initialize
gcloud CLI. Jika sebelumnya Anda telah menginstal gcloud CLI, dapatkan versi terbaru dengan menjalankan
gcloud components update
.
- Baca Praktik terbaik untuk GKE RBAC untuk mendapatkan panduan dalam meningkatkan desain kebijakan RBAC Anda.
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
atauClusterRoleBinding
. - 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
atauClusterRole
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 Peran dan ClusterRole API 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:
Identifikasi ID unik akun layanan:
gcloud iam service-accounts describe SERVICE_ACCOUNT_EMAIL
Misalnya, output berikut menampilkan
uniqueId
untuk akun layananmy-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'
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 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
- Pelajari cara membuat kebijakan IAM.
- Pelajari cara mengonfigurasi Google Grup untuk RBAC.