Gambaran umum identitas terkelola di Azure Kubernetes Service (AKS)

Artikel ini menyediakan gambaran umum identitas terkelola yang ditetapkan sistem dan ditetapkan pengguna di AKS, termasuk cara kerjanya, penetapan peran, dan fitur identitas terkelola khusus AKS.]

Untuk informasi selengkapnya tentang identitas terkelola di Azure, lihat dokumentasi Identitas terkelola untuk sumber daya Azure.

Nota

Identitas terkelola mencakup skenario identitas kluster-ke-Azure di AKS — bagaimana kluster AKS bertindak di Azure untuk mengelola sumber daya atas nama Anda. Untuk skenario identitas lainnya (autentikasi dan otorisasi sarana kontrol, dan identitas beban kerja Pod-ke-Azure), lihat Opsi akses dan identitas untuk AKS.

Nota

Jenis identitas yang ditetapkan oleh sistem dan pengguna berbeda dari identitas beban kerja, yang dirancang untuk digunakan oleh aplikasi yang berjalan di pod.

Alur otorisasi identitas terkelola AKS

Kluster AKS menggunakan identitas terkelola yang ditetapkan sistem atau ditetapkan pengguna untuk meminta token dari Microsoft Entra. Token ini membantu mengotorisasi akses ke sumber daya lain yang berjalan di Azure. Anda menetapkan peran kontrol akses berbasis peran Azure (Azure RBAC) ke identitas terkelola untuk memberinya izin ke sumber daya Azure tertentu. Misalnya, Anda dapat memberikan izin ke identitas terkelola untuk mengakses rahasia di brankas kunci Azure untuk digunakan oleh kluster.

Perilaku identitas terkelola di AKS

Saat Anda menyebarkan kluster AKS, identitas terkelola yang ditetapkan sistem dibuat untuk Anda secara default. Anda juga dapat membuat kluster dengan identitas terkelola yang ditetapkan pengguna, atau memperbarui kluster yang ada ke jenis identitas terkelola yang berbeda.

Jika kluster Anda sudah menggunakan identitas terkelola dan Anda mengubah jenis identitas (misalnya, dari yang ditetapkan sistem ke yang ditetapkan pengguna), ada penundaan saat komponen sarana kontrol beralih ke identitas baru. Komponen sarana kontrol terus menggunakan identitas lama sampai tokennya kedaluwarsa. Setelah token diperbarui, mereka beralih ke identitas baru. Proses ini dapat memakan waktu beberapa jam.

Nota

Anda juga dapat membuat kluster dengan aplikasi service principal, bukan dengan identitas terkelola. Namun, sebaiknya gunakan identitas terkelola melalui perwakilan layanan aplikasi untuk keamanan dan kemudahan penggunaan. Jika Anda memiliki kluster yang sudah ada yang menggunakan perwakilan layanan aplikasi, Anda dapat memperbaruinya untuk menggunakan identitas terkelola.

Manajemen identitas dan kredensial AKS

Platform Azure mengelola identitas terkelola yang ditetapkan sistem dan ditetapkan pengguna dan kredensialnya, sehingga Anda dapat mengotorisasi akses dari aplikasi Anda tanpa perlu menyediakan atau memutar rahasia apa pun.

Identitas terkelola yang diberikan oleh sistem

Tabel berikut ini meringkas karakteristik utama identitas terkelola yang ditetapkan sistem di AKS:

Pembuatan	Lifecycle	Berbagi antar sumber daya	Kasus penggunaan umum
Dibuat sebagai bagian dari sumber daya Azure, seperti kluster AKS	Terkait dengan siklus hidup sumber daya induk, sehingga akan dihapus saat sumber daya induk dihapus	Hanya dapat dikaitkan dengan satu sumber daya	• Beban kerja yang terkandung dalam satu sumber daya Azure • Beban kerja yang memerlukan identitas independen

Identitas terkelola yang ditetapkan pengguna

Tabel berikut ini meringkas karakteristik utama identitas terkelola yang ditetapkan pengguna di AKS:

Pembuatan	Lifecycle	Berbagi antar sumber daya	Kasus penggunaan umum
Dibuat sebagai sumber daya Azure mandiri, dan harus ada sebelum pembuatan kluster	Terlepas dari siklus hidup sumber daya tertentu, sehingga memerlukan penghapusan manual jika tidak lagi diperlukan	Dapat dibagikan di beberapa sumber daya	• Beban kerja yang berjalan pada beberapa sumber daya dan dapat berbagi satu identitas • Beban kerja yang memerlukan praautorisasi ke sumber daya yang aman sebagai bagian dari proses provisi • Beban kerja di mana sumber daya sering didaur ulang tetapi membutuhkan izin yang konsisten

Identitas terkelola kubelet yang telah dibuat sebelumnya

Identitas terkelola kubelet yang telah dibuat sebelumnya adalah identitas opsional yang ditetapkan pengguna yang dapat digunakan kubelet untuk mengakses sumber daya lain di Azure. Fitur ini memungkinkan skenario seperti koneksi ke Azure Container Registry (ACR) selama pembuatan kluster. Jika Anda tidak menentukan identitas terkelola yang ditetapkan pengguna untuk kubelet, AKS membuat identitas kubelet yang ditetapkan pengguna di grup sumber daya simpul. Untuk identitas kubelet yang ditetapkan pengguna di luar grup sumber daya simpul pekerja default, Anda perlu menetapkan peran Operator Identitas Terkelola pada identitas kubelet untuk identitas terkelola sarana kontrol.

Penugasan peran untuk identitas terkelola di AKS

Anda dapat menetapkan peran Azure RBAC ke identitas terkelola untuk memberikan izin kluster pada sumber daya Azure lain. Azure RBAC mendukung definisi peran bawaan dan kustom yang menentukan tingkat izin. Untuk menetapkan peran, lihat Langkah-langkah untuk menetapkan peran Azure.

Saat menetapkan peran Azure RBAC ke identitas terkelola, Anda harus menentukan cakupan untuk peran tersebut. Secara umum, ini adalah praktik terbaik untuk membatasi cakupan peran hingga hak istimewa minimum yang diperlukan oleh identitas terkelola. Untuk informasi selengkapnya tentang cakupan peran Azure RBAC, lihat Memahami cakupan untuk Azure RBAC.

Penetapan peran identitas terkelola sarana kontrol

Saat Anda membuat dan menggunakan VNet Anda sendiri, disk Azure terlampir, alamat IP statis, tabel rute, atau identitas kubelet yang ditetapkan pengguna di mana sumber daya berada di luar grup sumber daya simpul pekerja, Azure CLI menambahkan penetapan peran secara otomatis. Jika Anda menggunakan templat ARM atau metode lain, gunakan ID utama identitas terkelola untuk melakukan penetapan peran.

Jika Anda tidak menggunakan Azure CLI, tetapi Anda menggunakan VNet Anda sendiri, disk Azure terlampir, alamat IP statis, tabel rute, atau identitas kubelet yang ditetapkan pengguna yang berada di luar grup sumber daya simpul pekerja, sebaiknya gunakan identitas terkelola yang ditetapkan pengguna untuk sarana kontrol.

Ketika sarana kontrol menggunakan identitas terkelola yang ditetapkan sistem, identitas dibuat pada saat yang sama dengan kluster, sehingga penetapan peran tidak dapat dilakukan sampai setelah pembuatan kluster.

Ringkasan identitas terkelola yang digunakan oleh AKS

AKS menggunakan beberapa identitas terkelola untuk layanan dan add-on bawaan. Tabel berikut ini meringkas identitas terkelola yang digunakan oleh AKS, kasus penggunaannya, izin default, dan apakah Anda dapat membawa identitas Anda sendiri:

Identitas	Nama	Skenario penggunaan	Izin bawaan	Bawa identitas Anda sendiri
Pesawat pengendali	Nama kluster AKS	Digunakan oleh komponen kendali AKS untuk mengelola sumber daya kluster termasuk penyeimbang beban ingress dan IP publik yang dikelola AKS, Cluster Autoscaler, Disk Azure, driver File, Blob CSI.	Peran kontributor untuk grup sumber daya simpul	Didukung
Kubelet	Kluster AKS nama-agentpool	Autentikasi dengan Azure Container Registry (ACR)	N/A untuk Kubernetes versi 1.15 dan yang lebih baru	Didukung
Tambahan	AzureNPM	Tidak diperlukan identitas	N/A	Tidak didukung
Tambahan	Pemantauan jaringan AzureCNI	Tidak diperlukan identitas	N/A	Tidak didukung
Tambahan	azure-policy (penjaga gerbang)	Tidak diperlukan identitas	N/A	Tidak didukung
Tambahan	Calico	Tidak diperlukan identitas	N/A	Tidak didukung
Tambahan	pengaturan rute aplikasi	Mengelola sertifikat Azure DNS dan Azure Key Vault	Peran Pengguna Secrets untuk Key Vault, peran Kontributor Zona DNS untuk zona DNS, peran Kontributor Zona DNS Privat untuk zona DNS privat	Tidak didukung
Tambahan	HTTPApplicationRouting	Mengelola sumber daya jaringan yang diperlukan	Peran pembaca untuk grup sumber daya simpul, peran kontributor untuk zona DNS	Tidak didukung
Tambahan	Gateway aplikasi Ingress	Mengelola sumber daya jaringan yang diperlukan	Peran kontributor untuk grup sumber daya simpul	Tidak didukung
Tambahan	omsagent	Digunakan untuk mengirim metrik AKS ke Azure Monitor	Memantau peran Penerbit Metrik	Tidak didukung
Tambahan	Virtual-Node (ACIConnector)	Mengelola sumber daya jaringan yang diperlukan untuk Azure Container Instances (ACI)	Peran kontributor untuk grup sumber daya simpul	Tidak didukung
Tambahan	Analisis biaya	Digunakan untuk mengumpulkan data alokasi biaya	N/A	Didukung
Identitas beban kerja	ID Pekerjaan Microsoft Entra	Memungkinkan aplikasi mengakses sumber daya cloud dengan aman dengan ID Beban Kerja Microsoft Entra	N/A	Tidak didukung

Langkah selanjutnya

Aktifkan jenis identitas terkelola yang Anda inginkan pada kluster AKS baru atau yang sudah ada menggunakan panduan berikut:

• Menggunakan identitas terkelola yang ditetapkan sistem di AKS
• Menggunakan identitas terkelola yang ditetapkan pengguna di AKS
• Menggunakan identitas terkelola kubelet yang telah dibuat sebelumnya di AKS