Praktik terbaik untuk autentikasi dan otorisasi di Azure Kubernetes Service (AKS)

  • Artikel

Saat Anda menyebarkan dan memelihara kluster di Azure Kubernetes Service (AKS), Anda menerapkan cara untuk mengelola akses ke sumber daya dan layanan. Tanpa kontrol ini:

  • Akun dapat memiliki akses ke sumber daya dan layanan yang tidak perlu.
  • Melacak kredensial yang digunakan untuk membuat perubahan bisa sulit.

Dalam artikel ini, kami membahas praktik yang direkomendasikan yang dapat diikuti operator kluster untuk mengelola akses dan identitas untuk kluster AKS. Anda akan mempelajari cara:

  • Autentikasi pengguna kluster AKS dengan ID Microsoft Entra.
  • Mengontrol akses ke sumber daya dengan kontrol akses berbasis peran Kube (RBAC Kube).
  • Menggunakan RBAC Azure untuk mengontrol akses ke sumber daya AKS secara terperinci, API Kube dalam skala besar, dan kubeconfig.
  • Gunakan identitas beban kerja untuk mengakses sumber daya Azure dari pod Anda.

Peringatan

Sumber terbuka identitas yang dikelola pod Microsoft Entra (pratinjau) di Azure Kubernetes Service telah tidak digunakan lagi pada 24/10/2022.

Jika Anda mengaktifkan identitas terkelola pod Microsoft Entra di kluster AKS Anda atau mempertimbangkan untuk menerapkannya, kami sarankan Anda meninjau artikel gambaran umum identitas beban kerja untuk memahami rekomendasi dan opsi kami untuk menyiapkan kluster Anda untuk menggunakan ID Beban Kerja Microsoft Entra (pratinjau). Metode autentikasi ini menggantikan identitas yang dikelola pod (pratinjau), yang terintegrasi dengan kemampuan asli Kubernetes untuk bergabung dengan penyedia identitas eksternal apa pun.

Menggunakan ID Microsoft Entra

Panduan praktik terbaik

Sebarkan kluster AKS dengan integrasi Microsoft Entra. Menggunakan MICROSOFT Entra ID mempusatkan lapisan manajemen identitas. Setiap perubahan di akun pengguna atau status grup secara otomatis diperbarui pada akses ke kluster AKS. Mencakup pengguna atau grup ke jumlah izin minimum menggunakan Peran, ClusterRoles, atau Pengikatan.

Pengembang kluster dan pemilik aplikasi Kube Anda memerlukan akses ke sumber daya yang berbeda. Kube tidak memiliki solusi pengelolaan identitas bagi Anda untuk mengontrol sumber daya yang mana penggunanya dapat berinteraksi. Sebagai gantinya, Anda dapat mengintegrasikan kluster Anda dengan solusi identitas yang ada seperti ID Microsoft Entra, solusi manajemen identitas siap perusahaan.

Dengan kluster terintegrasi Microsoft Entra di AKS, Anda membuat Peran atau ClusterRoles yang menentukan izin akses ke sumber daya. Anda kemudian mengikat peran ke pengguna atau grup dari ID Microsoft Entra. Pelajari lebih lanjut mengenai RBAC Kube ini di bagian selanjutnya. Integrasi Microsoft Entra dan cara Anda mengontrol akses ke sumber daya dapat dilihat dalam diagram berikut:

Cluster-level authentication for Microsoft Entra integration with AKS

  1. Pengembang mengautentikasi dengan ID Microsoft Entra.
  2. Titik akhir penerbitan token Microsoft Entra mengeluarkan token akses.
  3. Pengembang melakukan tindakan menggunakan token Microsoft Entra, seperti kubectl create pod.
  4. Kubernetes memvalidasi token dengan ID Microsoft Entra dan mengambil keanggotaan grup pengembang.
  5. RBAC Kube dan kebijakan kluster diterapkan.
  6. Permintaan pengembang berhasil berdasarkan validasi sebelumnya dari keanggotaan grup Microsoft Entra dan RBAC Kubernetes dan kebijakan.

Untuk membuat kluster AKS yang menggunakan MICROSOFT Entra ID, lihat Mengintegrasikan MICROSOFT Entra ID dengan AKS.

Menggunakan kontrol akses berbasis peran Kube (RBAC Kube)

Panduan praktik terbaik

Tentukan izin pengguna atau grup untuk mengelompokkan sumber daya kluster dengan RBAC Kube. Buat peran dan ikatan yang menetapkan jumlah izin yang paling sedikit diperlukan. Integrasikan dengan ID Microsoft Entra untuk memperbarui status pengguna atau perubahan keanggotaan grup secara otomatis dan menjaga akses ke sumber daya kluster tetap terkini.

Di Kube, Anda menyediakan kontrol akses terperinci ke sumber daya kluster. Anda menentukan izin di tingkat kluster, atau ke namespace layanan tertentu. Anda menentukan sumber daya apa yang dapat dikelola dan dengan izin apa. Anda kemudian menerapkan peran ini ke pengguna atau grup dengan sebuah pengikatan. Untuk informasi lebih lanjut tentang Peran, ClusterRoles, dan Pengikatan, lihat Opsi akses dan identitas untuk Azure Kubernetes Service (AKS).

Misalnya, Anda membuat peran dengan akses penuh ke sumber daya di namespace bernama finance-app, seperti yang ditunjukkan dalam contoh manifes YAML berikut:

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: finance-app-full-access-role
  namespace: finance-app
rules:
- apiGroups: [""]
  resources: ["*"]
  verbs: ["*"]

Anda kemudian membuat RoleBinding dan mengikat pengguna developer1@contoso.com Microsoft Entra ke dalamnya, seperti yang ditunjukkan dalam manifes YAML berikut:

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: finance-app-full-access-role-binding
  namespace: finance-app
subjects:
- kind: User
  name: developer1@contoso.com
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: finance-app-full-access-role
  apiGroup: rbac.authorization.k8s.io

Saat developer1@contoso.com diautentikasi terhadap kluster AKS, mereka memiliki izin penuh ke sumber daya di namespace finance-app. Dengan cara ini, Anda secara logis memisahkan dan mengontrol akses ke sumber daya. Gunakan RBAC Kubernetes dengan microsoft Entra ID-integration.

Untuk mempelajari cara menggunakan grup Microsoft Entra untuk mengontrol akses ke sumber daya Kubernetes menggunakan Kubernetes RBAC, lihat Mengontrol akses ke sumber daya kluster menggunakan kontrol akses berbasis peran dan identitas Microsoft Entra di AKS.

Menggunakan RBAC Azure

Panduan praktik terbaik

Gunakan RBAC Azure untuk menentukan izin minimum pengguna dan grup yang diperlukan ke sumber daya AKS dalam satu atau beberapa langganan.

Ada dua tingkat akses yang diperlukan untuk mengoperasikan kluster AKS sepenuhnya:

  • Akses sumber daya AKS di langganan Azure Anda.

    Tingkat akses ini memungkinkan Anda untuk:

    • Mengontrol penskalaan atau peningkatan kluster menggunakan API AKS
    • Penarikan kubeconfig Anda.

    Untuk mempelajari cara mengontrol akses ke sumber daya AKS dan kubeconfig, lihat Membatasi akses ke file konfigurasi kluster.

  • Akses ke API Kube.

    Tingkat akses ini dikendalikan dengan salah satu dari:

    • RBAC Kube (secara tradisional) atau
    • Dengan mengintegrasikan RBAC Azure dengan AKS untuk otorisasi kube.

    Untuk mempelajari cara memberikan izin secara terperinci ke API Kubernetes menggunakan Azure RBAC, lihat Menggunakan Azure RBAC untuk otorisasi Kubernetes.

Menggunakan identitas yang dikelola pod

Peringatan

Sumber terbuka identitas yang dikelola pod Microsoft Entra (pratinjau) di Azure Kubernetes Service telah tidak digunakan lagi pada 24/10/2022.

Jika Anda mengaktifkan identitas terkelola pod Microsoft Entra di kluster AKS Anda atau mempertimbangkan untuk menerapkannya, kami sarankan Anda meninjau artikel gambaran umum identitas beban kerja untuk memahami rekomendasi dan opsi kami untuk menyiapkan kluster Anda untuk menggunakan ID Beban Kerja Microsoft Entra (pratinjau). Metode autentikasi ini menggantikan identitas yang dikelola pod (pratinjau), yang terintegrasi dengan kemampuan asli Kubernetes untuk bergabung dengan penyedia identitas eksternal apa pun.

Jangan gunakan informasi masuk yang tetap dalam pod atau gambar kontainer, karena berisiko terpapar atau disalahgunakan. Sebagai gantinya, gunakan identitas pod untuk meminta akses secara otomatis menggunakan ID Microsoft Entra.

Untuk mengakses sumber daya Azure lainnya, seperti penyimpanan Azure Cosmos DB, Key Vault, atau Blob, pod memerlukan kredensial autentikasi. Anda dapat menentukan kredensial autentikasi dengan gambar kontainer atau menyuntikkannya sebagai rahasia Kubernetes. Bagaimanapun itu, Anda harus membuat dan menetapkannya secara manual. Biasanya, informasi masuk ini digunakan kembali di seluruh pod dan tidak diputar secara teratur.

Dengan identitas yang dikelola pod (pratinjau) untuk sumber daya Azure, Anda secara otomatis meminta akses ke layanan melalui ID Microsoft Entra. Identitas yang dikelola pod saat ini dalam pratinjau untuk AKS. Lihat dokumentasi Gunakan identitas yang dikelola pod Microsoft Entra dalam Azure Kubernetes Service (Pratinjau) untuk memulai.

Identitas yang dikelola pod Microsoft Entra (pratinjau) mendukung dua mode operasi:

  • Mode standar : Dalam mode ini, 2 komponen berikut disebarkan ke kluster AKS:

    • Managed Identity Controller (MIC): Pengontrol Kube yang mengawasi perubahan ke pod, AzureIdentity dan AzureIdentityBinding melalui Server API Kube. Saat MIC mendeteksi perubahan yang relevan, MIC akan menambahkan atau menghapus AzureAssignedIdentity sesuai kebutuhan. Secara khusus, ketika pod dijadwalkan, MIC memberikan identitas terkelola pada Azure ke set skala mesin virtual yang mendasari yang digunakan oleh kumpulan node selama fase pembuatan. Ketika semua pod yang menggunakan identitas dihapus, hal ini menghapus identitas dari set skala mesin virtual kumpulan node, kecuali jika identitas terkelola yang sama digunakan oleh pod lain. MIC mengambil tindakan serupa ketika AzureIdentity atau AzureIdentityBinding dibuat atau dihapus.

    • Node Managed Identity (NMI): adalah pod yang berjalan sebagai DaemonSet di setiap node dalam kluster AKS. NMI mencegat permintaan token keamanan ke Azure Instance Metadata Service pada setiap simpul. Ini mengalihkan permintaan ke dirinya sendiri dan memvalidasi apakah pod memiliki akses ke identitas yang meminta token untuk, dan mengambil token dari penyewa Microsoft Entra atas nama aplikasi.

  • Mode terkelola : Dalam mode ini, hanya ada NMI. Identitas harus ditetapkan dan dikelola secara manual oleh pengguna. Untuk informasi selengkapnya, lihat Identitas Pod dalam Mode Terkelola. Dalam mode ini, ketika Anda menggunakan perintah az aks pod-identity add untuk menambahkan identitas pod ke kluster Azure Kubernetes Service (AKS), ia membuat AzureIdentity dan AzureIdentityBinding di namespace yang ditentukan oleh --namespace parameter, sementara penyedia sumber daya AKS menetapkan identitas terkelola yang ditentukan oleh --identity-resource-id parameter ke set skala komputer virtual dari setiap kumpulan simpul di kluster AKS.

Catatan

Jika Anda memutuskan untuk menginstal identitas yang dikelola pod Microsoft Entra menggunakan add-on kluster AKS, penyiapan menggunakan mode .managed

Mode managed memberikan keuntungan berikut jika dibandingkan standard:

  • Penetapan identitas pada set skala komputer virtual dari kumpulan simpul dapat memakan waktu 40-60 detik. Dengan cronjobs atau aplikasi yang memerlukan akses ke identitas dan tidak dapat mentolerir penundaan penugasan, yang terbaik adalah menggunakan managed mode karena identitas telah ditetapkan sebelumnya ke kumpulan skala komputer virtual kumpulan simpul. Baik secara manual atau menggunakan perintah az aks pod-identity add .
  • Dalam standard mode, MIC memerlukan izin tulis pada set skala komputer virtual yang digunakan oleh kluster AKS dan Managed Identity Operator izin pada identitas terkelola yang ditetapkan pengguna. Saat berjalan di managed mode, karena tidak ada MIC, penetapan peran tidak diperlukan.

Alih-alih menentukan kredensial secara manual untuk pod, identitas yang dikelola pod meminta token akses secara real time, menggunakannya untuk mengakses hanya sumber daya yang ditetapkan. Dalam AKS, ada dua komponen yang menangani operasi untuk memungkinkan pod untuk menggunakan identitas terkelola:

  • Server Identitas Pengelolaan Simpul (NMI) adalah sebuah pod yang berjalan sebagai DaemonSet pada setiap simpul di kluster AKS. Server NMI mendengarkan permintaan pod ke layanan Azure.
  • Penyedia Sumber Azure melakukan kueri server API Kube dan melakukan pemetaan identitas Azure yang sesuai dengan sebuah pod.

Ketika pod meminta token keamanan dari ID Microsoft Entra untuk mengakses sumber daya Azure, aturan jaringan mengalihkan lalu lintas ke server NMI.

  1. Server NMI:

    • Mengidentifikasi pod yang meminta akses ke sumber daya Azure berdasarkan alamat jarak jauhnya.
    • Melakukan kueri Penyedia Sumber Azure.

  2. Penyedia Sumber Azure memeriksa pemetaan identitas Azure di kluster AKS.

  3. Server NMI meminta token akses dari MICROSOFT Entra ID berdasarkan pemetaan identitas pod.

  4. MICROSOFT Entra ID menyediakan akses ke server NMI, yang dikembalikan ke pod.

    • Token akses ini dapat digunakan oleh pod untuk kemudian meminta akses ke sumber daya di Azure.

Dalam contoh berikut, pengembang membuat pod yang menggunakan sebuah identitas terkelola untuk meminta akses ke Azure SQL Database:

Pod identities allow a pod to automatically request access to other resources.

  1. Operator kluster membuat akun layanan untuk memetakan identitas saat pod meminta akses ke sumber daya.
  2. Server NMI disebarkan untuk menyampaikan permintaan pod apa pun, bersama dengan Penyedia Sumber Daya Azure, untuk token akses ke ID Microsoft Entra.
  3. Pengembang menyebarkan sebuah pod dengan sebuah identitas terkelola yang meminta token akses melalui server NMI.
  4. Tokennya dikembalikan ke pod dan digunakan untuk mengakses Azure SQL Database

Untuk menggunakan identitas yang dikelola Pod, lihat Menggunakan identitas yang dikelola pod Microsoft Entra di Azure Kubernetes Service (pratinjau).

Langkah berikutnya

Artikel praktik terbaik ini berfokus pada autentikasi dan otorisasi untuk kluster dan sumber daya Anda. Untuk menerapkan beberapa praktik terbaik ini, lihat artikel-artikel berikut:

Untuk informasi selengkapnya tentang operasi kluster di AKS, lihat praktik terbaik berikut: