Opsi akses dan identitas untuk Azure Kubernetes Service (AKS)

Berlaku untuk: ✔️ AKS Automatic ✔️ AKS Standard

AKS menggunakan identitas dalam lima skenario yang berbeda. Setiap skenario menjawab pertanyaan yang berbeda dan memiliki model konfigurasinya sendiri.

Untuk sebagian besar beban kerja AKS produksi, AKS Automatic adalah pilihan default yang direkomendasikan karena hadir dengan baseline platform yang siap untuk produksi, termasuk pengaturan default terkait identitas, dengan tetap mempertahankan model identitas AKS yang sama seperti yang dijelaskan dalam artikel ini.

Artikel ini memberikan gambaran singkat tentang setiap skenario, menjelaskan bagaimana panduan tersebut diterapkan pada AKS Automatic dan AKS Standard, serta merujuk ke dokumentasi pembahasan mendalam.

Lima skenario identitas di AKS

Skenario Pertanyaan yang dijawabnya Dokumen mendalam
A. Autentikasi sarana kontrol Kube Siapa pemanggil yang mengakses API Kubernetes? Konsep autentikasi kluster, penyedia identitas eksternal
B. Otorisasi sarana kontrol Kubernetes Apa yang diizinkan untuk dilakukan oleh pemanggil ketika diautentikasi ke API Kubernetes? Konsep otorisasi kluster
C. Otorisasi sumber daya AKS (Azure Resource Manager) Siapa yang dapat melakukan operasi tingkat Azure pada sumber daya AKS, seperti menarik kubeconfig? Membatasi akses ke file konfigurasi kluster, peran bawaan Azure
D. Identitas kluster (kluster → Azure) Bagaimana kluster AKS bertindak di Azure untuk mengelola sumber daya atas nama Anda? Identitas terkelola di AKS
E. Identitas beban kerja (pod → Azure) Bagaimana pod mengautentikasi ke layanan Azure seperti Key Vault atau Storage? ringkasan Microsoft Entra Workload ID

Status identitas di AKS Automatic dan AKS Standard

Lima skenario identitas dalam artikel ini berlaku untuk AKS Otomatis dan Standar AKS. Perbedaan utamanya adalah postur operasional:

  • AKS Otomatis menyediakan lebih banyak default identitas dan keamanan yang telah dikonfigurasi sebelumnya.
  • AKS Standard menyediakan kontrol yang lebih manual dan membutuhkan lebih banyak pilihan penyiapan.

Gunakan AKS Otomatis sebagai titik awal default untuk sebagian besar beban kerja produksi, dan gunakan AKS Standard saat Anda memerlukan konfigurasi platform kustom yang lebih dalam.

Untuk gambaran umum AKS Otomatis, lihat Pengantar Azure Kubernetes Service (AKS) Otomatis.

Perbandingan postur identitas AKS Otomatis dan Standar AKS

Bagian identitas Postur otomatis AKS Postur Standar AKS Pelajari lebih lanjut
Autentikasi API Kubernetes Konfigurasi default untuk produksi dengan integrasi Microsoft Entra sebagai model yang direkomendasikan Dapat dikonfigurasi, termasuk akun lokal dan pilihan integrasi Entra Konsep autentikasi kluster
Otorisasi API Kubernetes Azure RBAC untuk otorisasi Kubernetes telah dikonfigurasi sebelumnya Model yang mengutamakan akun lokal serta otorisasi yang dipilih oleh konfigurasi kluster Konsep otorisasi kluster
Otorisasi sumber daya AKS Menggunakan model RBAC Azure standar pada operasi sumber daya AKS Menggunakan model RBAC Azure standar pada operasi sumber daya AKS Mengontrol akses kubeconfig
Identitas kluster Menggunakan model identitas terkelola dengan konfigurasi dasar produksi sebagai nilai bawaan Menggunakan model identitas terkelola dengan penyiapan yang dipilih oleh operator Identitas terkelola di AKS
Identitas beban kerja Identitas beban kerja dan pengeluar sertifikat OIDC telah dikonfigurasi sebelumnya Opsional dan dikonfigurasi oleh operator Gambaran umum identitas beban kerja

Sisa artikel ini memberikan orientasi singkat untuk setiap skenario.

A. Autentikasi sarana kontrol Kube

Autentikasi sarana kontrol Kubernetes menetapkan identitas pengguna atau perwakilan layanan yang memanggil server API Kubernetes. AKS mendukung:

  • Microsoft Entra ID (disarankan): Gunakan identitas dan grup Entra ID untuk masuk ke kluster. Integrasi Microsoft Entra mengkonfigurasi dan memperbarui integrasi atas nama Anda. Untuk mengaktifkan, lihat Menggunakan integrasi Microsoft Entra.
  • Akun lokal: Sertifikat admin kluster bawaan yang melewati Entra ID. Kami merekomendasikan untuk menonaktifkan akun lokal di lingkungan produksi. Lihat Mengelola akun lokal.
  • Penyedia identitas eksternal: Gunakan idP yang mematuhi OIDC selain Microsoft Entra ID. Lihat Autentikasi penyedia identitas eksternal.

Untuk sebagian besar beban kerja produksi, mulailah dengan integrasi AKS Otomatis dan Microsoft Entra.

Untuk melihat secara mendalam bagaimana AKS mengautentikasi permintaan API Kubernetes, lihat Konsep autentikasi kluster.

B. Otorisasi sarana kontrol Kubernetes

Setelah penelepon diautentikasi ke API Kubernetes, AKS mengotorisasi permintaan menggunakan satu (atau keduanya) dari dua model:

  • RBAC Kubernetes: Kubernetes Role, , ClusterRoledan RoleBinding model asli yang dievaluasi oleh server API. Izin disimpan di kluster sebagai objek Kubernetes.
  • Otorisasi Microsoft Entra ID: Webhook otorisasi AKS mendelegasikan keputusan otorisasi kepada Microsoft Entra ID menggunakan penetapan peran Azure. Penetapan peran Azure RBAC dengan dataActions didukung untuk semua sumber daya API Kubernetes standar, dan penetapan peran dengan kondisi Azure ABAC didukung untuk sumber daya kustom. Kelola izin secara terpusat di Microsoft Entra ID untuk mengelola banyak kluster melalui satu penetapan peran pada cakupan langganan, grup manajemen, atau grup sumber daya.

Dalam AKS Otomatis, Azure RBAC untuk otorisasi Kubernetes telah dikonfigurasi sebelumnya sebagai bagian dari postur default siap produksi.

Untuk perbandingan dan panduan tentang kapan menggunakan setiap model, lihat Konsep otorisasi kluster.

C. Otorisasi sumber daya AKS (Azure Resource Manager)

Selain mengotorisasi panggilan ke API Kubernetes, Anda juga perlu mengotorisasi operasi tingkat Azure pada sumber daya AKS itu sendiri. Contoh paling umum adalah mengendalikan siapa yang dapat mengakses kluster kubeconfig, yang merupakan operasi mandiri di Azure Resource Manager yang dapat Anda atur dengan cermat menggunakan Azure RBAC. Operasi ini menggunakan Azure RBAC standar terhadap penyedia sumber daya Microsoft.ContainerService, terpisah dari otorisasi API Kubernetes, dan berlaku dengan cara yang sama untuk AKS Automatic dan AKS Standard. Untuk informasi selengkapnya, lihat Membatasi akses ke file konfigurasi kluster dan peran bawaan dalam peran bawaan Azure.

D. Identitas kluster (kluster → Azure)

Kluster AKS menggunakan identitas terkelola Azure untuk bertindak atas nama Anda — misalnya, untuk membuat load balancer, melampirkan disk, atau menarik gambar dari Azure Container Registry. Identitas utama adalah:

  • Identitas sarana kontrol: Digunakan oleh sarana kontrol kluster untuk mengelola sumber daya Azure untuk kluster.
  • Identitas Kubelet: Digunakan oleh kubelet pada setiap simpul untuk mengautentikasi ke layanan seperti Azure Container Registry.
  • Identitas add-on dan ekstensi: Beberapa add-on dan ekstensi AKS menggunakan identitas terkelola mereka sendiri.

AKS Automatic mempertahankan model identitas yang sama ini sekaligus mengurangi kendala dalam penyiapan melalui konfigurasi default siap produksi.

Untuk detail tentang setiap jenis identitas dan cara menggunakan identitas yang ditetapkan sistem vs identitas yang ditetapkan pengguna, lihat Identitas terkelola di AKS.

E. Identitas beban kerja (pod → Azure)

Identitas beban kerja memungkinkan pod yang berjalan di kluster AKS Anda mengautentikasi ke layanan Azure yang dilindungi Microsoft Entra (seperti Key Vault, Storage, atau Cosmos DB) tanpa menyimpan rahasia di kluster. AKS menggunakan ID Beban Kerja Microsoft Entra, yang memproyeksikan token akun layanan Kubernetes yang digabungkan ke aplikasi Microsoft Entra atau identitas terkelola yang ditetapkan pengguna.

AKS Otomatis mencakup identitas beban kerja dan pengeluar sertifikat OIDC sebagai default yang telah dikonfigurasi sebelumnya. Dalam Standar AKS, kemampuan ini bersifat opsional dan dikonfigurasi oleh operator.

Jangan gunakan identitas yang dikelola pod Microsoft Entra yang tidak digunakan lagi untuk beban kerja baru.

Panduan keputusan

Maksud Gunakan dokumen ini
Mulailah dengan garis besar identitas siap produksi untuk sebagian besar beban kerja Pengantar AKS Otomatis
Memasukkan pengguna ke kluster dengan ID Microsoft Entra Mengaktifkan integrasi Microsoft Entra
Mengatur siapa yang dapat melakukan apa di API Kubernetes di banyak kluster Menggunakan otorisasi ID Microsoft Entra untuk API Kubernetes
Membatasi akses ke jenis sumber daya kustom tertentu Kondisi ABAC dalam otorisasi ID Entra
Menyusun izin per-kluster, per-namespace sebagai objek Kubernetes Menggunakan RBAC Kubernetes dengan integrasi Entra
Biarkan kluster menarik dari ACR atau melampirkan disk Identitas terkelola di AKS
Biarkan pod mencapai Key Vault atau Storage tanpa rahasia ringkasan Microsoft Entra Workload ID
Membatasi siapa yang dapat mengunduh kluster kubeconfig Membatasi akses ke file konfigurasi kluster
Membuat kluster siap produksi dengan postur identitas default Membuat kluster Otomatis AKS

Referensi izin layanan AKS

Untuk izin Azure yang digunakan AKS (identitas yang membuat kluster, identitas kluster saat runtime, izin identitas kluster tambahan, dan akses simpul AKS), lihat Referensi izin layanan AKS.

Konten terkait

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

  • Last updated on