Catatan
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba masuk atau mengubah direktori.
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba mengubah direktori.
Artikel ini menjelaskan bagaimana Azure Kubernetes Service (AKS) memutuskan apa yang diizinkan untuk dilakukan oleh pemanggil terautentikasi terhadap API Kubernetes. Ini mencakup dua model otorisasi yang didukung AKS dan kontrol sumber daya kustom yang halus dengan kondisi Azure ABAC.
Untuk bagaimana AKS mengautentikasi pemanggil pada awalnya, lihat Konsep autentikasi kluster.
Untuk orientasi di keempat skenario identitas AKS, lihat Opsi akses dan identitas untuk AKS.
Mengotorisasi API Kubernetes
Setelah penelepon diautentikasi, AKS mengevaluasi apakah pemanggil berwenang untuk melakukan tindakan yang diminta. AKS mendukung dua model otorisasi untuk API Kubernetes:
- Kontrol akses berbasis peran Kubernetes (RBAC). Model otorisasi Kubernetes asli. Izin didefinisikan sebagai
RoledanClusterRoleobjek, serta diberikan kepada subjek melaluiRoleBindingdanClusterRoleBindingobjek yang disimpan di setiap kluster. - Otorisasi Microsoft Entra ID. Webhook otorisasi AKS yang mendelegasikan keputusan otorisasi ke Microsoft Entra ID. Izin diberikan sebagai penugasan peran Azure ke identitas ID Entra, dan dapat disempurnakan secara opsional dengan kondisi Azure ABAC.
Anda dapat menggunakan kedua model pada kluster yang sama. Kami merekomendasikan otorisasi ID Microsoft Entra sebagai default, sementara Kubernetes RBAC digunakan untuk izin intra-kluster yang terperinci. Bagian lainnya menjelaskan mengapa dan kapan menggunakan masing-masing.
RBAC Kubernetes
Kubernetes RBAC adalah model otorisasi Kubernetes upstream. Anda membuat Role atau ClusterRole objek yang memberikan kata kerja (seperti get, list, create) pada sumber daya (seperti pods, deployments) dan mengikatnya ke subjek (pengguna, grup, atau akun layanan) menggunakan RoleBinding atau ClusterRoleBinding objek. Otorisasi RBAC bawaan server API Kubernetes mengevaluasi pengikatan ini pada setiap permintaan.
Gunakan RBAC Kubernetes saat Anda ingin:
- Kontrol akses rinci dalam satu kluster dan setiap namespace yang ditulis sebagai Manifes Kubernetes bersama beban kerja yang mereka lindungi.
- Otorisasi yang dikelola GitOps yang berada di sumber kebenaran yang sama dengan konfigurasi aplikasi Anda.
- Izin untuk akun layanan dalam kluster yang digunakan oleh pekerjaan untuk memanggil API Kubernetes.
Izin RBAC Kubernetes dibatasi dalam satu kluster. Untuk menerapkan kebijakan yang sama ke banyak kluster, Anda harus menerapkan manifes ke setiap kluster (biasanya melalui GitOps). Gunakan pengguna dan grup Microsoft Entra sebagai subjek di Kubernetes RoleBinding dan ClusterRoleBinding objek sehingga identitas manusia masih berasal dari direktori pusat Anda.
Untuk informasi latar belakang tentang model RBAC Kubernetes, silakan lihat dokumentasi Kubernetes RBAC upstream. Untuk penyiapan di AKS, lihat Menggunakan Kubernetes RBAC dengan integrasi Microsoft Entra.
Otorisasi ID Microsoft Entra untuk API Kubernetes
Dengan otorisasi Entra ID, AKS menerapkan webhook otorisasi yang mendelegasikan keputusan otorisasi API Kubernetes ke Microsoft Entra ID. Ketika permintaan mencapai server API, webhook akan memanggil API Entra ID checkaccess untuk mengevaluasi penetapan peran Azure dari penelepon (serta kondisi ABAC yang terlampir) dan memberikan keputusan untuk mengizinkan atau menolak.
Otorisasi ID Entra memberi Anda manfaat berikut daripada mengelola manifes RBAC Kubernetes pada setiap kluster:
- Lapisan identitas tunggal. Pengguna, grup, dan perwakilan layanan Microsoft Entra yang sama yang mengatur akses ke sumber daya Azure Anda juga mengatur akses ke API Kubernetes Anda. Tidak ada direktori pengguna terpisah untuk memprovisikan atau mengganti.
- Tetapkan sekali, kelola banyak kluster. Penetapan peran Azure dapat dilakukan di langganan, grup manajemen, atau cakupan grup sumber daya. Satu penetapan peran pada cakupan grup sumber daya memberikan akses ke setiap kluster AKS saat ini dan di masa mendatang dalam cakupan grup sumber daya tersebut. Dengan RBAC Kubernetes, Anda harus menerapkan manifes ke setiap kluster satu per satu.
- Akses Kondisional dan Privileged Identity Management (PIM). Akses kluster secara otomatis mewarisi kebijakan Akses Bersyarat Entra ID yang sudah ada dalam organisasi Anda (seperti pembatasan berbasis lokasi atau autentikasi multifaktor) dan dapat ditingkatkan tepat waktu melalui PIM.
- Audit terpusat. Setiap perubahan penetapan peran dicatat di Log Aktivitas Azure bersama perubahan sumber daya Azure lainnya, sehingga Anda memiliki satu jejak audit untuk tata kelola akses kluster.
- Batasan sumber daya kustom yang halus. Dengan kondisi ABAC, Anda dapat membatasi akses ke grup dan jenis sumber daya kustom (CRD) tertentu tanpa menulis manifes RBAC Kubernetes per kluster.
AKS menyediakan peran bawaan berikut untuk otorisasi ID Entra:
| Peranan | Description |
|---|---|
| Pembaca RBAC Azure Kubernetes Service | Akses baca-saja ke sebagian besar objek dalam namespace. Tidak mengizinkan melihat peran, pengikatan peran, atau Secrets. |
| Penulis RBAC untuk Azure Kubernetes Service | Akses baca/tulis ke sebagian besar objek dalam namespace. Tidak mengizinkan menampilkan atau memodifikasi peran atau pengikatan peran. |
| RBAC Admin Azure Kubernetes Service | Akses baca/tulis ke sebagian besar sumber daya di namespace, ditambah kemampuan untuk membuat peran dan pengikatan peran dalam namespace. |
| RBAC Cluster Admin Azure Kubernetes Service | Pengendalian penuh atas setiap sumber daya dalam kluster, di semua namespace. |
Untuk pola izin kustom, Anda dapat menulis definisi peran kustom yang menargetkan grup API Kubernetes tertentu menggunakan Microsoft.ContainerService tindakan data penyedia sumber daya. Untuk penyiapan langkah demi langkah dan contoh peran kustom, lihat Menggunakan otorisasi ID Microsoft Entra untuk API Kubernetes.
Comparison
| Kemampuan | RBAC Kubernetes | Otorisasi Entra ID |
|---|---|---|
| Sumber identitas | Pengguna, grup, akun layanan Kubernetes | Identitas Microsoft Entra ID |
| Cakupan satu hibah | Satu kluster | Sumber daya, grup sumber daya, langganan, atau grup manajemen |
| Tata kelola multi-kluster | Menerapkan manifes ke setiap kluster (biasanya GitOps) | Satu pengaturan peran pada cakupan yang lebih tinggi dapat mengatur banyak kluster |
| Akses Bersyarat / PIM | Tidak didukung | Diwarisi dari ID Entra |
| Jejak audit | Log audit kluster | Log Aktivitas Azure |
| Memfilter akses menurut grup atau jenis CRD | Mengelola objek per CRD Role |
Menggunakan atribut kondisi ABAC untuk penetapan peran |
Membatasi akses sumber daya kustom dengan kondisi ABAC
Saat Anda memberikan akses baca yang luas melalui otorisasi ID Microsoft Entra tetapi ingin membatasi sumber daya kustom (CRD) mana yang dapat dibaca penerima tugas, lampirkan kondisi Azure ABAC ke penetapan peran.
Tanpa kondisi ABAC, memberikan izin baca pada sumber daya kustom memerlukan wildcard seperti Microsoft.ContainerService/managedClusters/*/read, sehingga mencakup setiap CRD pada setiap kluster dalam cakupan. Dengan ABAC, Anda dapat melampirkan kondisi yang membatasi akses ke grup dan jenis CRD tertentu — misalnya, memungkinkan templates.gatekeeper.sh saat memblokir kyverno.io — tanpa menulis manifes RBAC Kubernetes per kluster.
Untuk otorisasi API Kubernetes, Anda dapat memfilter akses ke sumber daya kustom oleh grup API dan jenisnya menggunakan atribut berikut:
Microsoft.ContainerService/managedClusters/customResources:groupMicrosoft.ContainerService/managedClusters/customResources:kind
Untuk latar belakang di Azure ABAC, lihat Apa itu kondisi penetapan peran Azure?. Untuk penyiapan langkah demi langkah, lihat Membatasi akses sumber daya kustom menggunakan kondisi ABAC.