Identitas dan akses beban kerja Kubernetes

Artikel ini menjelaskan bagaimana Amazon Elastic Kubernetes Service (EKS) dan Azure Kubernetes Service (AKS) menyediakan identitas untuk beban kerja Kubernetes untuk mengakses layanan platform cloud. Untuk perbandingan terperinci tentang Manajemen Identitas dan Akses (IAM) Amazon Web Services (AWS) dan ID Microsoft Entra, lihat sumber daya berikut:

• Manajemen identitas Microsoft Entra dan manajemen akses untuk AWS
• Memetakan konsep AWS IAM ke konsep Azure serupa

Panduan ini menjelaskan bagaimana kluster AKS, layanan bawaan, dan add-on menggunakan identitas terkelola untuk mengakses sumber daya Azure, seperti load balancer dan disk terkelola. Ini juga menunjukkan cara menggunakan ID Beban Kerja Microsoft Entra sehingga beban kerja AKS dapat mengakses sumber daya Azure tanpa memerlukan string koneksi, kunci akses, atau kredensial pengguna.

Nota

Artikel ini adalah bagian dari serangkaian artikel yang membantu para profesional yang terbiasa dengan Amazon EKS memahami Azure Kubernetes Service (AKS).

Manajemen identitas dan akses Amazon EKS

Amazon EKS menyediakan opsi asli untuk mengelola identitas dan akses dalam pod Kubernetes. Opsi ini termasuk peran IAM untuk akun layanan dan peran terkait layanan Amazon EKS.

Peran IAM untuk akun layanan

Anda dapat mengaitkan peran IAM dengan akun layanan Kubernetes. Asosiasi ini memberikan izin AWS ke kontainer dalam pod apa pun yang menggunakan akun layanan. Peran IAM untuk akun layanan memberikan manfaat berikut:

• Hak istimewa terkecil: Anda dapat menetapkan izin IAM tertentu ke akun layanan, yang memastikan bahwa hanya pod yang menggunakan akun layanan tersebut yang memiliki akses ke izin tersebut. Konfigurasi ini menghilangkan kebutuhan untuk memberikan izin yang diperluas ke peran IAM simpul untuk semua pod pada simpul. Pendekatan ini memberikan keamanan yang ditingkatkan dan kontrol terperinci dan menghilangkan kebutuhan akan solusi mitra, seperti kube2iam. Untuk informasi selengkapnya, lihat peran IAM untuk akun layanan.

• Isolasi kredensial: Setiap kontainer dalam pod hanya dapat mengambil kredensial untuk peran IAM yang terkait dengan akun layanan masing-masing. Isolasi ini memastikan bahwa kontainer tidak dapat mengakses kredensial milik kontainer lain di pod yang berbeda.

• Kemampuan audit: Amazon EKS menggunakan AWS CloudTrail untuk menyediakan akses dan pengelogan peristiwa, yang memfasilitasi audit dan kepatuhan retrospektif.

Untuk informasi selengkapnya, lihat peran IAM untuk akun layanan.

Peran tertaut layanan Amazon EKS

Peran terkait layanan Amazon EKS adalah peran IAM unik yang langsung ditautkan ke Amazon EKS. Peran yang telah ditentukan sebelumnya ini mencakup izin yang diperlukan untuk memanggil layanan AWS atas nama peran terkait. Peran terkait layanan utama untuk Amazon EKS adalah peran IAM simpul Amazon EKS.

Daemon simpul kubelet Amazon EKS menggunakan peran IAM simpul Amazon EKS untuk melakukan panggilan API ke layanan AWS atas nama simpul tersebut. Profil instans IAM dan kebijakan terkait menyediakan izin untuk panggilan API ini. Penyiapan ini menyederhanakan manajemen peran IAM untuk simpul dalam kluster EKS.

Untuk informasi selengkapnya, lihat Gunakan peran yang ditautkan ke layanan untuk Amazon EKS.

Informasi selengkapnya tentang manajemen identitas dan akses

Selain peran IAM untuk akun layanan dan peran terkait layanan Amazon EKS, aspek penting lainnya dalam mengelola identitas dan akses di Amazon EKS meliputi:

• Otorisasi Amazon EKS RBAC: Amazon EKS mendukung kontrol akses berbasis peran (RBAC). Gunakan fitur ini untuk menentukan izin terperinci untuk sumber daya Kubernetes di dalam kluster Anda.

• AWS IAM: IAM menyediakan solusi manajemen identitas yang komprehensif untuk layanan AWS, termasuk EKS. Gunakan IAM untuk membuat dan mengelola pengguna, grup, dan peran untuk mengontrol akses ke sumber daya EKS Anda.

• Grup keamanan Amazon EKS: Gunakan Amazon EKS untuk menerapkan aturan grup keamanan ke pod yang berjalan dalam kluster Anda. Gunakan fitur ini untuk mengontrol lalu lintas masuk dan keluar.

Untuk informasi selengkapnya, lihat Apa itu Amazon EKS?.

Identitas terkelola untuk kluster AKS

Kluster AKS memerlukan identitas Microsoft Entra untuk mengakses sumber daya Azure, seperti load balancer dan disk terkelola. Kami menyarankan agar Anda menggunakan identitas terkelola untuk sumber daya Azure untuk mengotorisasi akses dari kluster AKS ke layanan Azure lainnya.

Tipe identitas terkelola

Pengembang sering bergumul dengan manajemen rahasia, kredensial, sertifikat, dan kunci yang membantu mengamankan komunikasi antar layanan. Identitas terkelola menghilangkan kebutuhan Anda untuk mengelola kredensial ini. Anda dapat menggunakan identitas terkelola untuk mengautentikasi kluster AKS Anda tanpa mengelola kredensial atau menyertakannya dalam kode Anda. Tetapkan peran Azure RBAC ke identitas untuk memberikan izin identitas ke sumber daya tertentu di Azure.

Dua jenis identitas terkelola meliputi:

• Ditetapkan oleh sistem. Anda dapat menggunakan beberapa sumber daya Azure, seperti komputer virtual, untuk mengaktifkan identitas terkelola langsung pada sumber daya. Saat Anda mengaktifkan identitas terkelola yang ditetapkan sistem:

  • Jenis prinsipal layanan khusus dibuat di Microsoft Entra ID untuk pengelolaan identitas. Prinsipal layanan terhubung dengan siklus hidup sumber daya Azure tersebut. Saat sumber daya Azure dihapus, Azure secara otomatis menghapus perwakilan layanan.

  • Hanya sumber daya Azure yang dapat menggunakan identitas untuk meminta token dari ID Microsoft Entra.

  • Anda mengotorisasi identitas terkelola untuk memiliki akses ke satu atau beberapa layanan.

  • Nama perwakilan layanan yang ditetapkan sistem sama dengan nama sumber daya Azure yang dibuat.

• Ditetapkan pengguna. Anda dapat membuat identitas terkelola sebagai sumber daya Azure mandiri. Anda dapat membuat identitas terkelola yang ditetapkan pengguna dan menetapkannya ke satu atau beberapa sumber daya Azure. Saat Anda mengaktifkan identitas terkelola yang ditetapkan pengguna:

  • Jenis prinsipal layanan khusus dibuat di Microsoft Entra ID untuk pengelolaan identitas. Entitas layanan dikelola secara terpisah dari sumber daya yang menggunakannya.

  • Beberapa sumber daya dapat menggunakannya.

  • Anda mengotorisasi identitas terkelola untuk memiliki akses ke satu atau beberapa layanan.

Anda dapat menggunakan salah satu jenis identitas terkelola untuk mengotorisasi akses ke sumber daya Azure dari kluster AKS Anda.

Untuk informasi selengkapnya, lihat Jenis identitas terkelola.

Identitas terkelola di AKS (Azure Kubernetes Service)

Anda dapat menggunakan jenis identitas terkelola berikut dengan kluster AKS:

• Identitas terkelola yang ditetapkan sistem dikaitkan dengan satu sumber daya Azure, seperti kluster AKS. Ini hanya ada untuk siklus hidup kluster.

• Identitas terkelola yang ditetapkan pengguna adalah sumber daya Azure mandiri yang dapat Anda gunakan untuk mengotorisasi akses ke layanan Azure lainnya dari kluster AKS Anda. Ini bertahan secara terpisah dari kluster dan beberapa sumber daya Azure dapat menggunakannya.

• Identitas terkelola kubelet yang dibuat sebelumnya adalah identitas opsional yang ditetapkan pengguna yang dapat digunakan kubelet untuk mengakses sumber daya lain di Azure. Jika tidak ada identitas terkelola yang ditetapkan pengguna untuk "kubelet", AKS akan membuat identitas "kubelet" yang ditetapkan pengguna di grup sumber daya simpul.

Mengonfigurasi identitas terkelola untuk kluster AKS

Saat Anda menyebarkan kluster AKS, identitas terkelola yang ditetapkan sistem akan dibuat secara otomatis. Anda juga dapat membuat kluster dengan identitas terkelola yang ditetapkan pengguna. Kluster menggunakan identitas terkelola untuk meminta token dari ID Microsoft Entra. Token mengotorisasi akses ke sumber daya lain yang berjalan di Azure.

Saat menetapkan peran Azure RBAC ke identitas terkelola, Anda dapat memberikan izin kluster untuk mengakses sumber daya tertentu. Misalnya, Anda dapat menetapkan identitas terkelola peran Azure RBAC yang memungkinkannya mengakses rahasia di brankas kunci Azure. Gunakan pendekatan ini untuk dengan mudah mengotorisasi akses ke kluster Anda tanpa mengelola kredensial.

Manfaat dan pengelolaan identitas terkelola di AKS

Saat Anda menggunakan identitas terkelola di AKS, Anda tidak perlu menyediakan atau mengganti rahasia. Azure mengelola kredensial identitas. Oleh karena itu, Anda dapat mengotorisasi akses dari aplikasi Anda tanpa mengelola rahasia tambahan apa pun.

Jika Anda sudah memiliki kluster AKS yang menggunakan identitas terkelola, Anda dapat memperbarui kluster ke jenis identitas terkelola yang berbeda. Namun, pembaruan ini mungkin menimbulkan penundaan saat komponen sarana kontrol beralih ke identitas baru. Proses ini dapat memakan waktu beberapa jam. Selama waktu ini, komponen sarana kontrol terus menggunakan identitas lama sampai tokennya kedaluwarsa.

Jenis identitas terkelola di AKS

AKS menggunakan berbagai jenis identitas terkelola untuk mengaktifkan berbagai layanan dan add-on bawaan.

Identitas yang dikelola	Studi kasus	Izin bawaan
Rencana kontrol (ditetapkan sistem)	Komponen sarana kontrol AKS menggunakan identitas ini untuk mengelola sumber daya kluster. Sumber daya ini termasuk load balancer ingress, alamat IP publik yang dikelola AKS, autoscaler kluster, dan disk Azure, file, dan driver CSI blob.	Peran kontributor untuk grup sumber daya simpul
Kubelet (ditetapkan pengguna)	Autentikasi dengan Azure Container Registry.	N/A (untuk Kubernetes versi 1.15 dan yang lebih baru)
Identitas tambahan (AzureNPM, pemantauan jaringan AzureCNI, Azure Policy, dan Calico)	Add-on ini tidak memerlukan identitas.	Tidak tersedia
Perutean 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
Gateway aplikasi Ingress	Mengelola sumber daya jaringan yang diperlukan.	Peran kontributor untuk grup sumber daya simpul
Agen Operations Management Suite (OMS)	Mengirim metrik AKS ke Azure Monitor.	Memantau peran Penerbit Metrik
Node virtual (konektor Azure Container Instances)	Mengelola sumber daya jaringan yang diperlukan untuk Container Instances.	Peran kontributor untuk grup sumber daya simpul
Analisis biaya	Mengumpulkan data alokasi biaya.	Tidak tersedia
Identitas beban kerja (ID Beban Kerja)	Memungkinkan aplikasi mengakses sumber daya cloud dengan aman dengan ID Beban Kerja.	Tidak tersedia

Untuk informasi selengkapnya, lihat Menggunakan identitas terkelola di AKS.

ID beban kerja untuk Kubernetes

ID beban kerja terintegrasi dengan Kubernetes untuk mengaktifkan beban kerja yang disebarkan kluster AKS untuk mengakses sumber daya yang dilindungi Microsoft Entra, seperti Key Vault dan Microsoft Graph. ID Workload menggunakan kemampuan bawaan Kubernetes untuk bergabung dengan penyedia identitas eksternal. Untuk informasi selengkapnya, lihat Menggunakan ID Beban Kerja dengan AKS.

Untuk menggunakan ID Beban Kerja, konfigurasikan akun layanan dalam Kubernetes. Pod menggunakan akun layanan ini untuk mengautentikasi dan mengakses sumber daya Azure dengan aman. ID beban kerja berfungsi dengan baik dengan pustaka klien layanan identitas Azure atau koleksi Pustaka Autentikasi Microsoft. Anda harus mendaftarkan aplikasi di ID Microsoft Entra untuk mengelola izin dan kontrol akses untuk identitas.

Untuk sepenuhnya menggunakan ID Beban Kerja dalam kluster Kubernetes, konfigurasikan kluster AKS untuk mengeluarkan token dan menerbitkan dokumen penemuan OpenID Connect (OIDC) untuk validasi token. Untuk informasi selengkapnya, lihat Membuat penyedia OIDC di AKS.

Anda juga perlu mengonfigurasi aplikasi Microsoft Entra untuk mempercayai token Kubernetes. Pengembang kemudian dapat mengonfigurasi penyebaran mereka untuk menggunakan akun layanan Kubernetes untuk mendapatkan token. ID beban kerja menukar token dengan token Microsoft Entra. Beban kerja kluster AKS dapat menggunakan token Microsoft Entra ini untuk mengakses sumber daya yang dilindungi dengan aman di Azure.

Diagram berikut menunjukkan bagaimana kluster Kubernetes menjadi penerbit token keamanan yang mengeluarkan token ke akun layanan Kubernetes. Anda dapat mengonfigurasi token ini untuk dipercaya pada aplikasi Microsoft Entra. Token kemudian dapat ditukar dengan token akses Microsoft Entra melalui SDK layanan identitas Azure atau Microsoft Authentication Library.

Diagram urutan menunjukkan interaksi antara lima komponen: Kubelet, beban kerja Kubernetes, ID Microsoft Entra, dokumen penemuan OpenID, dan sumber daya Azure. Interaksi diberi nomor dari 1 hingga 5. Panah menunjukkan arah komunikasi. Panah dari Kubelet ke beban kerja Kubernetes diberi label 1. Panah dari beban kerja Kubernetes ke ID Microsoft Entra diberi label 2. Panah dari ID Microsoft Entra ke dokumen penemuan OpenID diberi label 3. Panah dari ID Microsoft Entra menuju beban kerja Kubernetes diberi label 4. Panah dari beban kerja Kubernetes ke sumber daya Azure diberi label 5.

1. Agen memproyeksikan kubelet token akun layanan ke beban kerja pada jalur file yang dapat dikonfigurasi.

2. Beban kerja Kubernetes mengirimkan token akun layanan yang diproyeksikan dan ditandatangani ke ID Microsoft Entra dan meminta token akses.

3. MICROSOFT Entra ID menggunakan dokumen penemuan OIDC untuk memverifikasi kepercayaan pada identitas terkelola yang ditentukan pengguna atau aplikasi terdaftar dan memvalidasi token masuk.

4. ID Microsoft Entra mengeluarkan token akses keamanan.

5. Beban kerja Kubernetes mengakses sumber daya Azure melalui token akses Microsoft Entra.

Untuk informasi selengkapnya tentang ID Beban Kerja, lihat sumber daya berikut ini:

• Proyek sumber terbuka Workload ID
• federasi identitas beban kerja
• Federasi ID beban kerja dengan Kubernetes
• Federasi ID Beban Kerja dengan Penyedia Identitas (IdP) OIDC Eksternal
• Federasi ID Beban Kerja Minimal
• Dokumentasi ID Beban Kerja
• Mulai cepat ID beban kerja
• Gunakan ID Beban Kerja untuk Kubernetes dengan identitas terkelola yang ditetapkan pengguna dalam aplikasi .NET Standard

Contoh beban kerja

Contoh beban kerja berikut berjalan pada kluster AKS dan terdiri dari layanan front-end dan back-end. Layanan ini menggunakan ID Beban Kerja untuk mengakses layanan Azure, termasuk Key Vault, Azure Cosmos DB, akun Azure Storage, dan namespace Azure Service Bus. Untuk menyiapkan contoh beban kerja ini, lakukan prasyarat berikut:

1. Siapkan kluster AKS yang mengaktifkan pengeluar sertifikat OIDC dan identitas beban kerja .

2. Buat akun layanan Kubernetes di namespace beban kerja.

3. Buat identitas terkelola yang ditetapkan pengguna Microsoft Entra atau aplikasi terdaftar.

4. Buat kredensial identitas gabungan antara identitas terkelola Microsoft Entra atau aplikasi terdaftar dan akun layanan beban kerja.

5. Tetapkan peran yang diperlukan dengan izin yang sesuai ke identitas terkelola Microsoft Entra atau aplikasi terdaftar.

6. Sebarkan beban kerja dan verifikasi autentikasi dengan identitas beban kerja.

Alur pesan ID beban kerja

Dalam contoh beban kerja ini, aplikasi front-end dan back-end memperoleh token keamanan Microsoft Entra untuk mengakses solusi platform as a service (PaaS) Azure. Diagram berikut menunjukkan alur pesan.

Bagian utamanya adalah penyiapan kluster AKS, yang mencakup pengontrol ingress NGINX dan namespace layanan Todolist dan komponennya. Kontainer penyebaran menunjukkan langkah 1 dalam alur kerja keseluruhan. Alur 2 beralih dari kontainer penyebaran ke ID Microsoft Entra. Alur 3 beralih dari ID Microsoft Entra ke URL penerbit OIDC. Alur 4 beralih dari ID Microsoft Entra ke kontainer penyebaran. Alur 5 beralih dari kontainer penyebaran ke Azure Key Vault, Azure Service Bus, Azure Cosmos DB, dan akun Azure Storage.

Unduh file Visio arsitektur ini.

1. Kubernetes mengeluarkan token ke pod ketika pod dijadwalkan pada node. Token ini didasarkan pada spesifikasi pod atau penyebaran.

2. Pod mengirimkan token yang dikeluarkan OIDC ke ID Microsoft Entra untuk meminta token Microsoft Entra untuk spesifik appId dan sumber daya.

3. MICROSOFT Entra ID memverifikasi kepercayaan pada aplikasi dan memvalidasi token masuk.

4. ID Microsoft Entra mengeluarkan token keamanan: {sub: appId, aud: requested-audience}.

5. Pod menggunakan token Microsoft Entra untuk mengakses sumber daya Azure target.

Untuk menggunakan ID Beban Kerja secara end-to-end di kluster Kubernetes:

1. Konfigurasikan kluster AKS untuk menerbitkan token dan menerbitkan dokumen penemuan OIDC untuk memungkinkan validasi token ini.

2. Konfigurasikan aplikasi Microsoft Entra untuk mempercayai token Kubernetes.

3. Pengembang mengonfigurasi penyebaran mereka untuk menggunakan akun layanan Kubernetes untuk mendapatkan token Kubernetes.

4. ID beban kerja menukar token Kubernetes dengan token Microsoft Entra.

5. Beban kerja kluster AKS menggunakan token Microsoft Entra untuk mengakses sumber daya yang dilindungi, seperti Microsoft Graph.

Kontributor

Microsoft mempertahankan artikel ini. Kontributor berikut menulis artikel ini.

Penulis utama:

• Paolo Salvatori | Teknisi Layanan Utama
• Martin Gjoshevski | Insinyur Layanan Senior

Kontributor lain:

• Laura Nicolas | Insinyur Perangkat Lunak Senior
• Chad Kittel | Insinyur Perangkat Lunak Utama - Pola & Praktik Azure
• Ed Price | Manajer Program Konten Senior
• Theano Petersen | Penulis Teknis

Untuk melihat profil LinkedIn nonpublik, masuk ke LinkedIn.

Langkah berikutnya

• Menggunakan perwakilan layanan dengan AKS
• Menggunakan sebuah identitas terkelola di AKS
• Jalur pembelajaran: Mengelola identitas dan akses di ID Microsoft Entra

Sumber daya terkait

• AKS untuk para profesional yang berkecimpung di Amazon EKS
• Pemantauan dan pengelogan Kubernetes
• Mengamankan akses jaringan ke Kubernetes
• Opsi penyimpanan untuk kluster Kubernetes
• Manajemen biaya untuk Kubernetes
• Node Kubernetes dan manajemen kumpulan simpul
• Tata kelola kelompok
• Manajemen identitas Microsoft Entra dan manajemen akses untuk AWS