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:
- Akses sumber daya AKS di langganan Azure Anda.
- Mengontrol penyekalaan atau peningkatan kluster menggunakan API AKS.
- Penarikan
kubeconfig
Anda.
- Akses ke API Kube. Akses ini dikendalikan oleh:
- RBAC Kube (secara tradisional).
- Integrasi RBAC Azure dengan AKS untuk otorisasi Kube.
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.
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.
Dengan kluster AKS terintegrasi Microsoft Entra, Anda dapat memberi pengguna atau grup akses ke sumber daya Kubernetes dalam namespace layanan atau di seluruh kluster.
- Untuk mendapatkan konteks konfigurasi
kubectl
, pengguna menjalankan perintah az aks get-credentials. - 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 Connect. OpenID Connect adalah lapisan identitas yang dibangun di atas protokol OAuth 2.0. Untuk informasi selengkapnya tentang OpenID Connect, lihat dokumentasi OpenID Connect. 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
Seperti yang ditunjukkan pada grafik di atas, server API memanggil server webhook AKS dan melakukan langkah-langkah berikut:
kubectl
menggunakan aplikasi klien Microsoft Entra untuk memasukkan pengguna dengan alur pemberian otorisasi perangkat OAuth 2.0.- MICROSOFT Entra ID menyediakan access_token, id_token, dan refresh_token.
- Pengguna membuat permintaan untuk
kubectl
dengan access_token darikubeconfig
. kubectl
mengirim access_token ke Server API.- Server API dikonfigurasi dengan Auth WebHook Server untuk melakukan validasi.
- Server webhook autentikasi mengonfirmasi tanda tangan JSON Web Token valid dengan memeriksa kunci penandatanganan publik Microsoft Entra.
- Aplikasi server menggunakan informasi masuk yang disediakan pengguna untuk mengkueri keanggotaan grup pengguna yang masuk dari MS Graph API.
- Respons dikirim ke Server API dengan informasi pengguna seperti klaim nama prinsipal pengguna (UPN) dari token akses, dan keanggotaan grup pengguna berdasarkan ID objek.
- API melakukan keputusan otorisasi berdasarkan Kube Role/RoleBinding.
- Setelah diotorisasi, server API mengembalikan respons ke
kubectl
. 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:
Jalankan
az login
untuk mengautentikasi ke Azure.Jalankan
az aks get-credentials
untuk mengunduh informasi masuk untuk kluster ke dalam.kube/config
.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.
- Juga ditemukan dengan nama parameter
Deskripsi | Diperlukan pemberian peran | Grup Microsoft Entra admin kluster | Waktu menggunakan |
---|---|---|---|
Data masuk admin lama menggunakan sertifikat klien | Peran Admin Kluster 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 "Peran Admin Kluster Azure Kubernetes Service". |
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 mulai menggunakan MICROSOFT Entra ID dan Kubernetes RBAC, lihat Mengintegrasikan MICROSOFT Entra ID dengan AKS.
- Untuk praktik terbaik terkait, lihat Praktik terbaik untuk autentikasi dan otorisasi di AKS.
- Untuk memulai dengan RBAC Azure untuk Otorisasi Kube, lihat Menggunakan RBAC Azure untuk mengotorisasi akses dalam Kluster Azure Kubernetes Service (AKS).
- Untuk mulai mengamankan file Anda
kubeconfig
, lihat Membatasi akses ke file konfigurasi kluster. - Untuk mulai menggunakan identitas terkelola di AKS, lihat Menggunakan identitas terkelola di AKS.
Untuk informasi lebih lanjut mengenai konsep pokok Kube dan AKS, lihat artikel berikut:
Azure Kubernetes Service