Mengakses dan mengidentifikasi opsi untuk Azure Kubernetes Service (AKS)

Anda dapat mengautentikasi, mengotorisasi, mengamankan, dan mengontrol akses ke kluster Kubernetes dengan berbagai cara:

  • Dengan menggunakan kontrol akses berbasis peran Kube (RBAC Kube), Anda dapat memberikan pengguna, grup, dan akses akun layanan hanya ke sumber daya yang dibutuhkan.
  • Dengan Azure Kubernetes Service (AKS), Anda dapat lebih meningkatkan struktur keamanan dan izin menggunakan MICROSOFT Entra ID dan Azure RBAC.

RBAC Kube dan AKS membantu Anda mengamankan akses kluster dan hanya memberikan izin minimum yang diperlukan kepada pengembang dan operator.

Artikel ini memperkenalkan konsep inti yang membantu Anda mengautentikasi dan menetapkan izin di AKS.

RBAC Kube

RBAC Kube menyediakan pemfilteran granular dari tindakan pengguna. Dengan mekanisme kontrol ini:

  • Anda tetapkan izin pengguna atau grup pengguna untuk membuat dan mengubah sumber daya atau menampilkan log dari beban kerja aplikasi yang sedang berjalan.
  • Anda dapat mencakup izin ke satu namespace layanan atau di seluruh kluster AKS.
  • Anda buat peran untuk menentukan izin, lalu tetapkan peran tersebut kepada pengguna dengan ikatan peran.

Untuk informasi lebih lanjut, lihat Menggunakan otorisasi RBAC Kube.

Peran dan ClusterRoles

Peran

Sebelum menetapkan izin kepada pengguna dengan RBAC Kube, Anda akan menentukan izin pengguna sebagai Peran. Memberikan izin dalam namespace layanan menggunakan peran.

Catatan

Peran Kube memberikan izin; peran Kube tidak menolak izin.

Untuk memberikan izin di seluruh kluster atau untuk mengkluster sumber daya di luar namespace layanan tertentu, Anda dapat menggunakan ClusterRoles sebagai gantinya.

ClusterRoles

ClusterRole memberikan dan menerapkan izin ke sumber daya di seluruh kluster, bukan namespace layanan tertentu.

RoleBindings dan ClusterRoleBindings

Setelah Anda menentukan peran untuk memberikan izin ke sumber daya, Anda tetapkan izin RBAC Kube tersebut dengan RoleBinding. Jika kluster AKS Anda terintegrasi dengan MICROSOFT Entra ID, RoleBindings memberikan izin kepada pengguna Microsoft Entra untuk melakukan tindakan dalam kluster. Lihat cara mengontrol akses ke sumber daya kluster menggunakan kontrol akses berbasis peran Kubernetes dan identitas Microsoft Entra.

RoleBindings

Tetapkan peran kepada pengguna untuk namespace layanan tertentu menggunakan RoleBindings. Dengan RoleBindings, Anda dapat secara logis memisahkan satu kluster AKS, hanya memungkinkan pengguna untuk mengakses sumber daya aplikasi di namespace layanan yang ditetapkan.

Untuk mengikat peran di seluruh kluster, atau untuk mengkluster sumber daya di luar namespace layanan tertentu, Anda dapat menggunakan ClusterRoleBindings sebagai gantinya.

ClusterRoleBinding

Dengan ClusterRoleBinding, Anda mengikat peran ke pengguna dan menerapkan ke sumber daya di seluruh kluster, bukan namespace layanan tertentu. Pendekatan ini memungkinkan Anda memberi admin atau teknisi dukungan akses ke semua sumber daya di kluster AKS.

Catatan

Microsoft/AKS melakukan tindakan kluster dengan persetujuan pengguna berdasarkan peran Kube bawaan aks-service dan ikatan peran bawaan aks-service-rolebinding.

Peran ini mengaktifkan AKS untuk memecahkan masalah dan mendiagnosis masalah kluster, tetapi tidak dapat mengubah izin atau membuat peran atau ikatan peran, atau tindakan hak istimewa tinggi lainnya. Akses peran hanya diaktifkan dalam tiket dukungan aktif dengan akses just-in-time (JIT). Baca selengkapnya tentang kebijakan dukungan AKS.

Akun layanan Kube

Akun layanan adalah salah satu jenis pengguna utama di Kube. API Kube memegang dan mengelola akun layanan. Informasi masuk akun layanan disimpan sebagai rahasia Kube, yang memungkinkannya digunakan oleh pod resmi untuk berkomunikasi dengan Server API. Sebagian besar permintaan API menyediakan token autentikasi untuk akun layanan atau akun pengguna normal.

Akun pengguna normal memungkinkan akses yang lebih tradisional untuk admin atau pengembang manusia, bukan hanya layanan dan proses. Meskipun Kube tidak menyediakan solusi manajemen identitas untuk menyimpan akun pengguna dan kata sandi reguler, Anda dapat mengintegrasikan solusi identitas eksternal ke dalam Kube. Untuk kluster AKS, solusi identitas terintegrasi ini adalah ID Microsoft Entra.

Untuk informasi lebih lanjut tentang opsi identitas di Kube, lihat autentikasi Kube.

Kontrol akses berbasis peran Azure

Kontrol akses berbasis peran Azure (RBAC) adalah sistem otorisasi yang dibuat di Azure Resource Manager yang memberikan manajemen akses mendetail untuk sumber daya Azure.

Sistem RBAC Deskripsi
RBAC Kube Dirancang untuk bekerja pada sumber daya Kube dalam kluster AKS Anda.
Azure RBAC Dirancang untuk bekerja pada sumber daya dalam langganan Azure Anda.

Dengan Azure RBAC, Anda membuat definisi peran yang menguraikan izin yang akan diterapkan. Anda kemudian menetapkan pengguna atau grup definisi peran ini melalui penetapan peran untuk cakupan tertentu. Cakupan dapat berupa sumber daya individu, grup sumber daya, atau di seluruh langganan.

Untuk informasi selengkapnya, lihat Apa yang dimaksud dengan kontrol akses berbasis peran Azure (RBAC Azure)?

Ada dua tingkat akses yang diperlukan untuk mengoperasikan kluster AKS sepenuhnya:

RBAC Azure untuk mengotorisasi akses ke sumber daya AKS

Dengan RBAC Azure, Anda dapat memberi pengguna (atau identitas) akses granular ke sumber daya AKS di satu atau beberapa langganan. Misalnya, Anda dapat menggunakan peran Azure Kubernetes Service Contributor untuk menyekalakan dan meningkatkan kluster Anda. Sementara itu, pengguna lain dengan peran Admin Kluster Azure Kubernetes Service hanya memiliki izin untuk menarik Admin kubeconfig.

Menggunakan RBAC Azure untuk menentukan akses ke file konfigurasi Kube di AKS.

Azure RBAC untuk Otorisasi Kubernetes

Dengan integrasi Azure RBAC, AKS akan menggunakan server webhook Otorisasi Kubernetes sehingga Anda dapat mengelola izin dan penetapan sumber daya kluster Kubernetes terintegrasi Microsoft Entra menggunakan definisi peran Azure dan penetapan peran.

Azure RBAC for Kubernetes authorization flow

Seperti yang ditunjukkan pada diagram di atas, saat menggunakan integrasi Azure RBAC, semua permintaan ke API Kubernetes akan mengikuti alur autentikasi yang sama seperti yang dijelaskan pada bagian integrasi Microsoft Entra.

Jika identitas yang membuat permintaan ada di ID Microsoft Entra, Azure akan bekerja sama dengan RBAC Kubernetes untuk mengotorisasi permintaan. Jika identitas ada di luar ID Microsoft Entra (yaitu, akun layanan Kubernetes), otorisasi akan menumpuk ke RBAC Kubernetes normal.

Dalam skenario ini, Anda menggunakan mekanisme RBAC Azure dan API untuk menetapkan peran bawaan pengguna atau membuat peran kustom, sama seperti peran Kube.

Dengan fitur ini, Anda tidak hanya memberikan izin kepada pengguna untuk sumber daya AKS di seluruh langganan, tetapi Anda juga mengonfigurasi peran dan izin untuk di dalam masing-masing kluster yang mengontrol akses API Kube. Misalnya, Anda dapat memberikan peran Azure Kubernetes Service RBAC Reader pada cakupan langganan. Penerima peran akan dapat mencantumkan dan mendapatkan semua objek Kube dari semua kluster tanpa mengubahnya.

Penting

Anda perlu mengaktifkan RBAC Azure untuk otorisasi Kube sebelum menggunakan fitur ini. Untuk detail lebih lanjut dan panduan langkah demi langkah, ikuti panduan cara Menggunakan RBAC Azure untuk Otorisasi Kube.

Peran bawaan

AKS menyediakan empat peran bawaan berikut. Peran tersebut mirip dengan peran bawaan Kube dengan beberapa perbedaan, seperti CRD pendukung. Lihat daftar lengkap tindakan yang diizinkan oleh setiap peran bawaan Azure.

Peran Deskripsi
Pembaca RBAC Azure Kubernetes Service Mengizinkan akses baca-saja untuk melihat sebagian besar objek di namespace layanan.
Tidak mengizinkan menampilkan peran atau pengikatan peran.
Tidak mengizinkan menampilkan Secrets. Membaca konten Secrets mengaktifkan akses ke informasi masuk ServiceAccount di namespace layanan, yang akan mengizinkan akses API seperti ServiceAccount di namespace layanan (bentuk eskalasi hak istimewa).
Penulis RBAC Azure Kubernetes Service Mengizinkan akses read/write ke sebagian besar objek dalam sebuah namespace layanan.
Tidak mengizinkan menampilkan atau mengubah peran atau pengikatan peran.
Mengizinkan mengakses Secrets dan menjalankan pod sebagai ServiceAccount apa pun di namespace layanan, sehingga dapat digunakan untuk mendapatkan tingkatan akses API dari ServiceAccount apa pun di namespace layanan.
Admin RBAC Azure Kubernetes Service Mengizinkan akses admin, untuk di dalam namespace layanan.
Mengizinkan akses read/write ke sebagian besar sumber daya di namespace layanan (atau cakupan klaster), termasuk kemampuan untuk membuat peran dan pengikatan peran dalam namespace layanan.
Tidak mengizinkan akses tulis ke kuota sumber daya atau ke namespace layanan itu sendiri.
Admin Kluster RBAC Azure Kubernetes Service Mengizinkan akses bagi pengguna-super untuk melakukan tindakan apa pun pada sumber daya apa pun.
Memberikan kontrol penuh atas setiap sumber daya dalam kluster dan di semua namespace layanan.

Integrasi Microsoft Entra

Tingkatkan keamanan kluster AKS Anda dengan integrasi Microsoft Entra. Dibangun berdasarkan manajemen identitas perusahaan selama beberapa dekade, MICROSOFT Entra ID adalah layanan manajemen identitas dan direktori berbasis cloud multi-penyewa yang menggabungkan layanan direktori inti, manajemen akses aplikasi, dan perlindungan identitas. Dengan MICROSOFT Entra ID, Anda dapat mengintegrasikan identitas lokal ke dalam kluster AKS untuk menyediakan satu sumber untuk manajemen dan keamanan akun.

Microsoft Entra integration with AKS clusters

Dengan kluster AKS terintegrasi Microsoft Entra, Anda dapat memberi pengguna atau grup akses ke sumber daya Kubernetes dalam namespace layanan atau di seluruh kluster.

  1. Untuk mendapatkan konteks konfigurasi kubectl, pengguna menjalankan perintah az aks get-credentials.
  2. Saat pengguna berinteraksi dengan kluster AKS dengan kubectl, mereka diminta untuk masuk dengan kredensial Microsoft Entra mereka.

Pendekatan ini menyediakan sumber tunggal untuk manajemen akun pengguna dan informasi masuk kata sandi. Pengguna hanya dapat mengakses sumber daya sebagaimana yang ditentukan oleh admin kluster.

Autentikasi Microsoft Entra disediakan untuk kluster AKS dengan OpenID Koneksi. OpenID Connect adalah lapisan identitas yang dibangun di atas protokol OAuth 2.0. Untuk informasi selengkapnya tentang Koneksi OpenID, lihat dokumentasi Koneksi OpenID. Dari dalam kluster Kube, Autentikasi Token Webhook digunakan untuk memverifikasi token autentikasi. Autentikasi token webhook dikonfigurasi dan dikelola sebagai bagian dari kluster AKS.

Server webhook dan API

Webhook and API server authentication flow

Seperti yang ditunjukkan pada grafik di atas, server API memanggil server webhook AKS dan melakukan langkah-langkah berikut:

  1. kubectl menggunakan aplikasi klien Microsoft Entra untuk memasukkan pengguna dengan alur pemberian otorisasi perangkat OAuth 2.0.
  2. MICROSOFT Entra ID menyediakan access_token, id_token, dan refresh_token.
  3. Pengguna membuat permintaan untuk kubectl dengan access_token dari kubeconfig.
  4. kubectl mengirim access_token ke Server API.
  5. Server API dikonfigurasi dengan Auth WebHook Server untuk melakukan validasi.
  6. Server webhook autentikasi mengonfirmasi tanda tangan JSON Web Token valid dengan memeriksa kunci penandatanganan publik Microsoft Entra.
  7. Aplikasi server menggunakan informasi masuk yang disediakan pengguna untuk mengkueri keanggotaan grup pengguna yang masuk dari MS Graph API.
  8. Respons dikirim ke Server API dengan informasi pengguna seperti klaim nama prinsipal pengguna (UPN) dari token akses, dan keanggotaan grup pengguna berdasarkan ID objek.
  9. API melakukan keputusan otorisasi berdasarkan Kube Role/RoleBinding.
  10. Setelah diotorisasi, server API mengembalikan respons ke kubectl.
  11. kubectl memberikan umpan balik kepada pengguna.

Pelajari cara mengintegrasikan AKS dengan MICROSOFT Entra ID dengan panduan cara integrasi Microsoft Entra yang dikelola AKS.

Izin layanan AKS

Saat membuat kluster, AKS menghasilkan atau memodifikasi sumber daya yang dibutuhkan (seperti komputer virtual dan NIC) untuk membuat dan menjalankan kluster atas nama pengguna. Identitas ini berbeda dari izin identitas kluster, yang dibuat selama pembuatan kluster.

Identitas membuat dan mengoperasikan izin cluster

Izin berikut diperlukan oleh identitas yang membuat dan mengoperasikan kluster.

Izin Alasan
Microsoft.Compute/diskEncryptionSets/read Diperlukan untuk membaca ID set enkripsi disk.
Microsoft.Compute/proximityPlacementGroups/write Diperlukan untuk memperbarui grup penempatan terdekat.
Microsoft.Network/applicationGateways/read
Microsoft.Network/applicationGateways/write
Microsoft.Network/virtualNetworks/subnets/join/action
Diperlukan untuk mengonfigurasi gateway aplikasi dan bergabung dengan subnet.
Microsoft.Network/virtualNetworks/subnets/join/action Diperlukan untuk mengonfigurasi Kelompok Keamanan Jaringan untuk subnet ketika menggunakan VNET kustom.
Microsoft.Network/publicIPAddresses/join/action
Microsoft.Network/publicIPPrefixes/join/action
Diperlukan untuk mengonfigurasi IP publik keluar pada Load Balancer Standar.
Microsoft.OperationalInsights/workspaces/sharedkeys/read
Microsoft.OperationalInsights/workspaces/read
Microsoft.OperationsManagement/solutions/write
Microsoft.OperationsManagement/solutions/read
Microsoft.ManagedIdentity/userAssignedIdentities/assign/action
Diperlukan untuk membuat dan memperbarui ruang kerja Analitik Log dan pemantauan Azure untuk kontainer.
Microsoft.Network/virtualNetworks/joinLoadBalancer/action Diperlukan untuk mengonfigurasi Kumpulan Backend Load Balancer berbasis IP.

Izin identitas kluster AKS

Izin berikut digunakan oleh identitas kluster AKS, yang dibuat dan dikaitkan dengan kluster AKS. Setiap izin digunakan untuk alasan di bawah ini:

Izin Alasan
Microsoft.ContainerService/managedClusters/*
Diperlukan untuk membuat pengguna dan mengoperasikan kluster
Microsoft.Network/loadBalancers/delete
Microsoft.Network/loadBalancers/read
Microsoft.Network/loadBalancers/write
Diperlukan untuk mengonfigurasi load balancer untuk layanan LoadBalancer.
Microsoft.Network/publicIPAddresses/delete
Microsoft.Network/publicIPAddresses/read
Microsoft.Network/publicIPAddresses/write
Diperlukan untuk menemukan dan mengonfigurasi IP publik untuk layanan LoadBalancer.
Microsoft.Network/publicIPAddresses/join/action Diperlukan untuk mengonfigurasi IP publik untuk layanan LoadBalancer.
Microsoft.Network/networkSecurityGroups/read
Microsoft.Network/networkSecurityGroups/write
Diperlukan untuk membuat atau menghapus aturan keamanan untuk layanan LoadBalancer.
Microsoft.Compute/disks/delete
Microsoft.Compute/disks/read
Microsoft.Compute/disks/write
Microsoft.Compute/locations/DiskOperations/read
Diperlukan untuk mengonfigurasi AzureDisks.
Microsoft.Storage/storageAccounts/delete
Microsoft.Storage/storageAccounts/listKeys/action
Microsoft.Storage/storageAccounts/read
Microsoft.Storage/storageAccounts/write
Microsoft.Storage/operations/read
Diperlukan untuk mengonfigurasi akun penyimpanan untuk AzureFile atau AzureDisk.
Microsoft.Network/routeTables/read
Microsoft.Network/routeTables/routes/delete
Microsoft.Network/routeTables/routes/read
Microsoft.Network/routeTables/routes/write
Microsoft.Network/routeTables/write
Diperlukan untuk mengonfigurasi tabel rute dan rute untuk simpul.
Microsoft.Compute/virtualMachines/read Diperlukan untuk menemukan informasi untuk komputer virtual di VMAS, seperti zona, domain kegagalan, ukuran, dan disk data.
Microsoft.Compute/virtualMachines/write Diperlukan untuk melampirkan AzureDisks ke komputer virtual di VMAS.
Microsoft.Compute/virtualMachineScaleSets/read
Microsoft.Compute/virtualMachineScaleSets/virtualMachines/read
Microsoft.Compute/virtualMachineScaleSets/virtualmachines/instanceView/read
Diperlukan untuk menemukan informasi untuk set skala komputer virtual, seperti zona, domain kegagalan, ukuran, dan disk data.
Microsoft.Network/networkInterfaces/write Diperlukan untuk menambahkan komputer virtual dalam VMAS ke kumpulan alamat backend load balancer.
Microsoft.Compute/virtualMachineScaleSets/write Diperlukan untuk menambahkan set skala komputer virtual ke kumpulan alamat backend load balancer dan meluaskan skala simpul dalam set skala komputer virtual.
Microsoft.Compute/virtualMachineScaleSets/delete Diperlukan untuk menghapus set skala komputer virtual ke kumpulan alamat backend load balancer dan mengecilkan skala simpul dalam set skala komputer virtual.
Microsoft.Compute/virtualMachineScaleSets/virtualmachines/write Diperlukan untuk melampirkan AzureDisks dan menambahkan komputer virtual dari set skala komputer virtual ke load balancer.
Microsoft.Network/networkInterfaces/read Diperlukan untuk mencari IP internal dan kumpulan alamat backend load balancer untuk komputer virtual di VMAS.
Microsoft.Compute/virtualMachineScaleSets/virtualMachines/networkInterfaces/read Diperlukan untuk mencari IP internal dan kumpulan alamat backend load balancer untuk komputer virtual di set skala komputer virtual.
Microsoft.Compute/virtualMachineScaleSets/virtualMachines/networkInterfaces/ipconfigurations/publicipaddresses/read Diperlukan untuk menemukan IP publik untuk komputer virtual dalam set skala komputer virtual.
Microsoft.Network/virtualNetworks/read
Microsoft.Network/virtualNetworks/subnets/read
Diperlukan untuk memverifikasi apakah subnet ada untuk load balancer internal di grup sumber daya lain.
Microsoft.Compute/snapshots/delete
Microsoft.Compute/snapshots/read
Microsoft.Compute/snapshots/write
Diperlukan untuk mengonfigurasi rekam jepret untuk AzureDisk.
Microsoft.Compute/locations/vmSizes/read
Microsoft.Compute/locations/operations/read
Diperlukan untuk menemukan ukuran komputer virtual untuk menemukan batas volume AzureDisk.

Izin identitas kluster tambahan

Saat membuat kluster dengan atribut tertentu, Anda akan memerlukan izin tambahan berikut untuk identitas kluster. Karena izin ini tidak ditetapkan secara otomatis, Anda harus menambahkannya ke identitas kluster setelah dibuat.

Izin Alasan
Microsoft.Network/networkSecurityGroups/write
Microsoft.Network/networkSecurityGroups/read
Diperlukan jika menggunakan kelompok keamanan jaringan di grup sumber daya lain. Diperlukan untuk mengonfigurasi aturan keamanan untuk layanan LoadBalancer.
Microsoft.Network/virtualNetworks/subnets/read
Microsoft.Network/virtualNetworks/subnets/join/action
Diperlukan jika menggunakan subnet di grup sumber daya lain seperti VNET kustom.
Microsoft.Network/routeTables/routes/read
Microsoft.Network/routeTables/routes/write
Diperlukan jika menggunakan subnet yang terkait dengan tabel rute di grup sumber daya lain seperti VNET kustom dengan tabel rute kustom. Diperlukan untuk memverifikasi apakah subnet sudah ada untuk subnet di grup sumber daya lainnya.
Microsoft.Network/virtualNetworks/subnets/read Diperlukan jika menggunakan load balancer internal di grup sumber daya lain. Diperlukan untuk memverifikasi apakah subnet sudah ada untuk load balancer internal di grup sumber.
Microsoft.Network/privatednszones/* Diperlukan jika menggunakan zona DNS privat di grup sumber daya lain seperti privateDNSZone kustom.

Akses Node Azure Kubernetes Service

Secara default Akses Node tidak diperlukan untuk Azure Kubernetes Service. Akses berikut diperlukan untuk simpul jika komponen tertentu dimanfaatkan.

Access Alasan
kubelet Diperlukan untuk memberikan akses MSI ke ACR.
http app routing Diperlukan untuk menulis izin untuk "nama acak".aksapp.io.
container insights Diperlukan untuk memberikan izin ke ruang kerja Analitik Log.

Ringkasan

Lihat tabel untuk ringkasan singkat tentang bagaimana pengguna dapat mengautentikasi ke Kubernetes saat integrasi Microsoft Entra diaktifkan. Dalam semua kasus, urutan perintah pengguna adalah:

  1. Jalankan az login untuk mengautentikasi ke Azure.

  2. Jalankan az aks get-credentials untuk mengunduh informasi masuk untuk kluster ke dalam .kube/config.

  3. Jalankan perintah kubectl.

    • Perintah pertama dapat memicu autentikasi berbasis browser untuk mengautentikasi ke kluster, seperti yang dijelaskan dalam tabel berikut.

Di portal Microsoft Azure, Anda dapat menemukan:

  • Pemberian Peran (pemberian peran RBAC Azure) yang dimaksud di kolom kedua diperlihatkan pada tab Kontrol Akses.
  • Grup Microsoft Entra Admin Kluster ditampilkan pada tab Konfigurasi .
    • Juga ditemukan dengan nama parameter --aad-admin-group-object-ids di Azure CLI.
Deskripsi Diperlukan pemberian peran Grup Microsoft Entra admin kluster Waktu menggunakan
Data masuk admin lama menggunakan sertifikat klien Peran Admin Azure Kubernetes Service. Peran ini memungkinkan az aks get-credentials untuk digunakan dengan --admin bendera, yang mengunduh sertifikat admin kluster warisan (non-Microsoft Entra) ke dalam pengguna .kube/config. Ini adalah satu-satunya tujuan dari "Peran Admin Kube Azure". n/a Jika Anda diblokir secara permanen dengan tidak memiliki akses ke grup Microsoft Entra yang valid dengan akses ke kluster Anda.
ID Microsoft Entra dengan RoleBindings manual (Kluster) Peran Pengguna Kluster Azure Kubernetes Service. Peran "Pengguna" memungkinkan az aks get-credentials untuk digunakan tanpa bendera --admin. (Ini adalah satu-satunya tujuan "Peran Pengguna Kluster Azure Kubernetes Service".) Hasilnya, pada kluster berkemampuan ID Microsoft Entra, adalah unduhan entri kosong ke dalam .kube/config, yang memicu autentikasi berbasis browser saat pertama kali digunakan oleh kubectl. Pengguna tidak berada dalam grup ini. Karena pengguna tidak berada dalam grup Admin Kluster apa pun, hak mereka akan dikontrol sepenuhnya oleh RoleBinding atau ClusterRoleBinding yang telah disiapkan oleh admin kluster. (Kluster)RoleBindings mencalonkan pengguna Microsoft Entra atau grup Microsoft Entra sebagai mereka subjects. Jika tidak ada pengikatan seperti yang telah disiapkan, pengguna tidak akan dapat mengeluarkan perintah kubectl apa pun. Jika Anda ingin kontrol akses mendetail, dan Anda tidak menggunakan RBAC Azure untuk Otorisasi Kube. Perhatikan bahwa pengguna yang menyiapkan pengikatan harus masuk dengan salah satu metode lain yang tercantum dalam tabel ini.
ID Microsoft Entra menurut anggota grup admin Sama seperti di atas Pengguna adalah anggota dari salah satu grup yang tercantum di sini. AKS secara otomatis menghasilkan ClusterRoleBinding yang mengikat semua grup yang terdaftar ke peran Kube cluster-admin. Jadi pengguna dalam grup ini dapat menjalankan semua perintah kubectl sebagai cluster-admin. Jika Anda ingin dengan mudah memberikan hak admin penuh kepada pengguna, dan tidak menggunakan RBAC Azure untuk otorisasi Kube.
ID Microsoft Entra dengan Azure RBAC untuk Otorisasi Kubernetes Dua peran:
Pertama, Peran Pengguna Kluster Azure Kubernetes Service (seperti di atas).
Kedua, salah satu peran "Azure Kubernetes Service RBAC..." yang tercantum di atas, atau alternatif kustom Anda sendiri.
Bidang peran admin pada tab Konfigurasi tidak relevan ketika RBAC Azure untuk Otorisasi Kube diaktifkan. Anda menggunakan RBAC Azure untuk otorisasi Kube. Pendekatan ini memberi Anda kontrol mendetail, tanpa perlu menyiapkan RoleBindings atau ClusterRoleBindings.

Langkah berikutnya

Untuk informasi lebih lanjut mengenai konsep pokok Kube dan AKS, lihat artikel berikut: