Identitas dan akses beban kerja Kubernetes

Artikel ini menjelaskan bagaimana Amazon Elastic Kubernetes Service (Amazon EKS) dan Azure Kubernetes Service (AKS) menyediakan identitas untuk beban kerja Kubernetes untuk mengakses layanan platform cloud. Untuk perbandingan terperinci dari Amazon Web Services (AWS) Identity and Access Management (IAM) dan ID Microsoft Entra, lihat:

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

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. Artikel 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.

Manajemen identitas dan akses Amazon EKS

Amazon EKS memiliki dua opsi asli untuk memanggil layanan AWS dari dalam pod Kubernetes: Peran IAM untuk akun layanan, dan peran tertaut layanan Amazon EKS.

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

• Hak istimewa paling sedikit: Anda tidak perlu memberikan izin yang diperluas ke peran IAM simpul untuk pod pada simpul tersebut untuk memanggil API AWS. Anda dapat mencakup izin IAM ke akun layanan, dan hanya pod yang menggunakan akun layanan tersebut yang memiliki akses ke izin tersebut. Fitur ini juga menghilangkan kebutuhan akan solusi pihak ketiga seperti kiam atau kube2iam.

• Isolasi kredensial: Kontainer hanya dapat mengambil kredensial untuk peran IAM yang terkait dengan akun layanan miliknya. Kontainer tidak pernah memiliki akses ke kredensial untuk kontainer lain yang termasuk dalam pod lain.

• Auditabilitas: Amazon CloudTrail menyediakan akses dan pengelogan peristiwa untuk membantu memastikan audit retrospektif.

Peran tertaut layanan Amazon EKS adalah peran IAM unik yang ditautkan langsung ke Amazon EKS. Peran yang ditautkan layanan telah ditentukan sebelumnya oleh Amazon EKS dan menyertakan semua izin yang diperlukan untuk memanggil layanan AWS lainnya atas nama peran tersebut. Untuk peran IAM simpul Amazon EKS, daemon simpul kubelet Amazon EKS memanggil API AWS atas nama simpul. Simpul mendapatkan izin untuk panggilan API ini dari profil instans IAM dan kebijakan terkait.

Identitas terkelola kluster AKS

Kluster AKS memerlukan identitas untuk mengakses sumber daya Azure seperti load balancer dan disk terkelola. Identitas ini dapat berupa identitas terkelola atau perwakilan layanan. Secara default, membuat kluster AKS secara otomatis membuat identitas terkelola yang ditetapkan sistem. Platform Azure mengelola identitas, dan Anda tidak perlu menyediakan atau memutar rahasia apa pun. Untuk informasi selengkapnya tentang identitas terkelola Microsoft Entra, lihat Identitas terkelola untuk sumber daya Azure.

AKS tidak membuat perwakilan layanan secara otomatis, jadi jika Anda ingin menggunakan perwakilan layanan, Anda harus membuatnya. Perwakilan layanan akhirnya kedaluwarsa, dan Anda harus memperbaruinya agar kluster tetap berfungsi. Mengelola perwakilan layanan menambah kompleksitas, sehingga lebih mudah untuk menggunakan identitas terkelola.

Identitas terkelola pada dasarnya adalah pembungkus di sekitar perwakilan layanan yang menyederhanakan manajemen. Persyaratan izin yang sama berlaku untuk perwakilan layanan dan identitas terkelola. Identitas terkelola menggunakan autentikasi berbasis sertifikat. Setiap kredensial identitas terkelola memiliki kedaluwarsa 90 hari dan diputar setelah 45 hari.

AKS menggunakan jenis identitas terkelola yang ditetapkan sistem maupun pengguna dan identitas ini tidak dapat diubah. Saat Anda membuat atau menggunakan jaringan virtual AKS, disk Azure terlampir, alamat IP statis, tabel rute, atau identitas yang ditetapkan kubelet pengguna dengan sumber daya di luar grup sumber daya simpul, Azure CLI menambahkan penetapan peran secara otomatis.

Jika Anda menggunakan metode lain untuk membuat kluster AKS, seperti templat Bicep, templat Azure Resource Manager (ARM), atau modul Terraform, Anda perlu menggunakan ID utama identitas terkelola kluster untuk melakukan penetapan peran. Identitas kluster AKS harus memiliki setidaknya peran Kontributor Jaringan pada subnet dalam jaringan virtual Anda. Untuk menentukan peran kustom alih-alih menggunakan peran Kontributor Jaringan bawaan, Anda memerlukan izin berikut:

• Microsoft.Network/virtualNetworks/subnets/join/action
• Microsoft.Network/virtualNetworks/subnets/read

Ketika identitas kluster perlu mengakses sumber daya yang ada, misalnya saat Anda menyebarkan kluster AKS ke jaringan virtual yang ada, Anda harus menggunakan identitas terkelola yang ditetapkan pengguna. Jika Anda menggunakan identitas sarana kontrol yang ditetapkan sistem, penyedia sumber daya tidak bisa mendapatkan ID utamanya sebelum membuat kluster, jadi tidak mungkin untuk membuat penetapan peran yang tepat sebelum provisi kluster.

Ringkasan identitas terkelola

AKS menggunakan identitas terkelola yang ditetapkan pengguna berikut untuk layanan dan add-on bawaan.

Untuk informasi selengkapnya, lihat Menggunakan identitas terkelola di Azure Kubernetes Service.

ID Beban Kerja Microsoft Entra untuk Kubernetes

Beban kerja Kubernetes memerlukan kredensial aplikasi Microsoft Entra untuk mengakses sumber daya yang dilindungi ID Microsoft Entra, seperti Azure Key Vault dan Microsoft Graph. Tantangan umum bagi pengembang adalah mengelola rahasia dan kredensial untuk mengamankan komunikasi antara komponen solusi yang berbeda.

ID Beban Kerja Microsoft Entra untuk Kubernetes menghilangkan kebutuhan untuk mengelola kredensial untuk mengakses layanan cloud seperti Azure Cosmos DB, Azure Key Vault, atau Azure Blob Storage. Aplikasi beban kerja yang dihosting AKS dapat menggunakan ID Beban Kerja Microsoft Entra untuk mengakses layanan terkelola Azure dengan menggunakan token keamanan Microsoft Entra, alih-alih kredensial eksplisit seperti string koneksi, nama pengguna, dan kata sandi, atau kunci primer.

Seperti yang ditunjukkan pada diagram berikut, 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 dengan menggunakan Azure Identity SDK atau Microsoft Authentication Library (MSAL).

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 memeriksa 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 dengan menggunakan token akses Microsoft Entra.

Federasi ID Beban Kerja Microsoft Entra untuk Kubernetes saat ini hanya didukung untuk aplikasi Microsoft Entra, tetapi model yang sama berpotensi meluas ke identitas terkelola Azure.

Untuk informasi selengkapnya, otomatisasi, dan dokumentasi untuk ID Beban Kerja Microsoft Entra, lihat:

• Proyek sumber terbuka Azure Workload Identity.
• Federasi identitas beban kerja
• Federasi ID Beban Kerja Microsoft Entra dengan Kubernetes
• Federasi ID Beban Kerja Microsoft Entra dengan idP OIDC eksternal
• Federasi ID Beban Kerja Microsoft Entra minimal
• ID Beban Kerja Microsoft Entra
• Mulai cepat ID Beban Kerja Microsoft Entra
• Gunakan ID Beban Kerja Microsoft Entra untuk Kubernetes dengan identitas terkelola yang ditetapkan pengguna dalam aplikasi .NET Standard

Contoh beban kerja

Contoh beban kerja menjalankan frontend dan layanan backend pada kluster AKS. Layanan beban kerja menggunakan ID Beban Kerja Microsoft Entra untuk mengakses layanan Azure berikut dengan menggunakan token keamanan Microsoft Entra:

• Azure Key Vault
• Azure Cosmos DB
• Akun Azure Storage
• Namespace Azure Service Bus

Prasyarat

1. Siapkan kluster AKS dengan penerbit OIDC diaktifkan.
2. Instal webhook penerimaan bermutasi.
3. Buat akun layanan Kubernetes untuk beban kerja.
4. Buat aplikasi Microsoft Entra seperti yang ditunjukkan dalam mulai cepat.
5. Tetapkan peran dengan izin yang tepat ke aplikasi terdaftar Microsoft Entra yang diperlukan.
6. Buat kredensial identitas gabungan antara aplikasi Microsoft Entra dan penerbit dan subjek akun layanan.
7. Sebarkan aplikasi beban kerja ke kluster AKS.

Alur pesan ID Beban Kerja Microsoft Entra

Aplikasi AKS mendapatkan token keamanan untuk akun layanan mereka dari penerbit OIDC kluster AKS. ID Beban Kerja Microsoft Entra bertukar token keamanan dengan token keamanan yang dikeluarkan oleh ID Microsoft Entra, dan aplikasi menggunakan token keamanan yang dikeluarkan ID Microsoft Entra untuk mengakses sumber daya Azure.

Diagram berikut menunjukkan bagaimana aplikasi frontend dan backend memperoleh token keamanan Microsoft Entra untuk menggunakan layanan platform as a service (PaaS) Azure.

Unduh file Visio arsitektur ini.

1. Kubernetes mengeluarkan token ke pod ketika dijadwalkan pada node, berdasarkan 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 memeriksa 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 Microsoft Entra secara end-to-end di kluster Kubernetes:

1. Anda mengonfigurasi kluster AKS untuk mengeluarkan token dan menerbitkan dokumen penemuan OIDC untuk memungkinkan validasi token ini.
2. Anda mengonfigurasi 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 Microsoft Entra 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

Artikel ini dikelola oleh Microsoft. Ini awalnya ditulis oleh kontributor berikut.

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
• Harga Ed | Manajer Program Konten Senior
• Theano Petersen | Penulis Teknis

Untuk melihat profil LinkedIn non-publik, masuk ke LinkedIn.

Langkah berikutnya

• AKS untuk profesional 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 kluster
• Manajemen identitas Microsoft Entra dan manajemen akses untuk AWS

Sumber daya terkait

• Perwakilan layanan dengan Azure Kubernetes Services (AKS)
• Menggunakan identitas terkelola di Azure Kubernetes Service
• Menerapkan Azure Kubernetes Service (AKS)
• Mengelola identitas dan akses di ID Microsoft Entra