Migrasi dari identitas terkelola pod ke identitas beban kerja

  • Artikel

Artikel ini berfokus pada migrasi dari identitas yang dikelola pod ke ID Beban Kerja Microsoft Entra untuk kluster Azure Kubernetes Service (AKS). Ini juga menyediakan panduan tergantung pada versi pustaka klien Azure Identity yang digunakan oleh aplikasi berbasis kontainer Anda.

Jika Anda tidak terbiasa dengan ID Beban Kerja Microsoft Entra, lihat artikel Gambaran Umum berikut ini.

Sebelum Anda mulai

Azure CLI versi 2.47.0 atau yang lebih baru. Jalankan az --version untuk menemukan versi, dan jalankan az upgrade untuk meningkatkan versi. Jika Anda perlu memasang atau meningkatkan, lihat Memasang Azure CLI.

Skenario migrasi

Bagian ini menjelaskan opsi migrasi yang tersedia tergantung pada versi Azure Identity SDK apa yang diinstal.

Untuk salah satu skenario, Anda harus menyiapkan kepercayaan federasi sebelum memperbarui aplikasi Anda untuk menggunakan identitas beban kerja. Berikut ini adalah langkah-langkah minimum yang diperlukan:

  • Buat kredensial identitas terkelola.
  • Kaitkan identitas terkelola dengan akun layanan kubernetes yang sudah digunakan untuk identitas yang dikelola pod atau buat akun layanan Kubernetes baru lalu kaitkan dengan identitas terkelola.
  • Membangun hubungan kepercayaan federasi antara identitas terkelola dan ID Microsoft Entra.

Migrasi dari versi terbaru

Jika aplikasi Anda sudah menggunakan versi terbaru Azure Identity SDK, lakukan langkah-langkah berikut untuk menyelesaikan konfigurasi autentikasi:

  • Sebarkan identitas beban kerja secara paralel dengan identitas yang dikelola pod. Anda dapat memulai ulang penyebaran aplikasi untuk mulai menggunakan identitas beban kerja, di mana ia menyuntikkan anotasi OIDC ke dalam aplikasi secara otomatis.
  • Setelah memverifikasi bahwa aplikasi berhasil diautentikasi, Anda dapat menghapus anotasi identitas yang dikelola pod dari aplikasi Anda lalu menghapus add-on identitas yang dikelola pod.

Migrasi dari versi yang lebih lama

Jika aplikasi Anda tidak menggunakan versi terbaru Azure Identity SDK, Anda memiliki dua opsi:

  • Anda dapat menggunakan sidecar migrasi yang kami sediakan dalam aplikasi Linux Anda, yang membuat proksi transaksi IMDS yang dilakukan aplikasi Anda ke OpenID Koneksi (OIDC). Sidecar migrasi tidak dimaksudkan untuk menjadi solusi jangka panjang, tetapi cara untuk bangun dan berjalan dengan cepat pada identitas beban kerja. Lakukan langkah-langkah berikut untuk:

    • Sebarkan beban kerja dengan sidecar migrasi untuk mem-proksi transaksi IMDS aplikasi.
    • Verifikasi bahwa transaksi autentikasi berhasil diselesaikan.
    • Jadwalkan pekerjaan untuk aplikasi untuk memperbarui SDK di sana ke versi yang didukung.
    • Setelah SDK diperbarui ke versi yang didukung, Anda dapat menghapus sidecar proksi dan menyebarkan ulang aplikasi.

    Catatan

    Sidecar migrasi tidak didukung untuk penggunaan produksi. Fitur ini dimaksudkan untuk memberi Anda waktu untuk memigrasikan SDK aplikasi Anda ke versi yang didukung, dan tidak dimaksudkan atau dimaksudkan untuk menjadi solusi jangka panjang. Sidecar migrasi hanya tersedia untuk kontainer Linux, karena hanya menyediakan identitas yang dikelola pod dengan kumpulan simpul Linux.

  • Tulis ulang aplikasi Anda untuk mendukung versi terbaru pustaka klien Azure Identity . Setelah itu, lakukan langkah-langkah berikut:

    • Mulai ulang penyebaran aplikasi Anda untuk mulai mengautentikasi menggunakan identitas beban kerja.
    • Setelah Anda memverifikasi bahwa transaksi autentikasi berhasil diselesaikan, Anda dapat menghapus anotasi identitas yang dikelola pod dari aplikasi Anda lalu menghapus add-on identitas yang dikelola pod.

Buat identitas terkelola

Jika Anda tidak memiliki identitas terkelola yang dibuat dan ditetapkan ke pod Anda, lakukan langkah-langkah berikut untuk membuat dan memberikan izin yang diperlukan untuk penyimpanan, Key Vault, atau sumber daya apa pun yang perlu diautentikasi aplikasi Anda di Azure.

  1. Gunakan perintah az account set Azure CLI untuk mengatur langganan tertentu menjadi langganan aktif saat ini. Kemudian gunakan perintah az identity create untuk membuat identitas terkelola.

    az account set --subscription "subscriptionID"

    az identity create --name "userAssignedIdentityName" --resource-group "resourceGroupName" --location "location" --subscription "subscriptionID"

    export USER_ASSIGNED_CLIENT_ID="$(az identity show --resource-group "resourceGroupName" --name "userAssignedIdentityName" --query 'clientId' -otsv)"

  2. Berikan identitas terkelola izin yang diperlukan untuk mengakses sumber daya di Azure yang diperlukan. Untuk informasi tentang cara melakukannya, lihat Menetapkan akses identitas terkelola ke sumber daya.

  3. Untuk mendapatkan URL Pengeluar Sertifikat OIDC dan menyimpannya ke variabel lingkungan, jalankan perintah berikut. Ganti nilai default untuk nama kluster dan nama grup sumber daya.

    export AKS_OIDC_ISSUER="$(az aks show -n myAKSCluster -g myResourceGroup --query "oidcIssuerProfile.issuerUrl" -otsv)"

    Variabel harus berisi URL Penerbit yang mirip dengan contoh berikut:

    https://eastus.oic.prod-aks.azure.com/00000000-0000-0000-0000-000000000000/00000000-0000-0000-0000-000000000000/

    Secara default, Penerbit diatur untuk menggunakan URL https://{region}.oic.prod-aks.azure.com/{uuid}dasar , di mana nilai untuk {region} mencocokkan lokasi tempat kluster AKS disebarkan. Nilai {uuid} mewakili kunci OIDC.

Membuat akun layanan Kubernetes

Jika Anda tidak memiliki akun layanan Kubernetes khusus yang dibuat untuk aplikasi ini, lakukan langkah-langkah berikut untuk membuat dan kemudian membuat anotasi dengan ID klien identitas terkelola yang dibuat pada langkah sebelumnya. Gunakan perintah az aks get-credentials dan ganti nilai untuk nama kluster dan nama grup sumber daya.

az aks get-credentials -n myAKSCluster -g "${RESOURCE_GROUP}"

Salin dan tempel input multibaris berikut di Azure CLI.

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: ServiceAccount
metadata:
  annotations:
    azure.workload.identity/client-id: ${USER_ASSIGNED_CLIENT_ID}
  name: ${SERVICE_ACCOUNT_NAME}
  namespace: ${SERVICE_ACCOUNT_NAMESPACE}
EOF

Output berikut menyerupan pembuatan identitas yang berhasil:

Serviceaccount/workload-identity-sa created

Menetapkan kepercayaan kredensial identitas federasi

Gunakan perintah az identity federated-credential create untuk membuat kredensial identitas federasi antara identitas terkelola, penerbit akun layanan, dan subjek. Ganti nilai resourceGroupName, , userAssignedIdentityNamefederatedIdentityName, serviceAccountNamespace, dan serviceAccountName.

az identity federated-credential create --name federatedIdentityName --identity-name userAssignedIdentityName --resource-group resourceGroupName --issuer ${AKS_OIDC_ISSUER} --subject system:serviceaccount:${SERVICE_ACCOUNT_NAMESPACE}:${SERVICE_ACCOUNT_NAME} --audience api://AzureADTokenExchange

Catatan

Dibutuhkan waktu beberapa detik agar info masuk identitas federasi dapat disebarluaskan setelah ditambahkan. Jika permintaan token dibuat segera setelah menambahkan kredensial identitas federasi, itu mungkin menyebabkan kegagalan selama beberapa menit karena cache diisi di direktori dengan data lama. Untuk menghindari masalah ini, Anda dapat menambahkan sedikit penundaan setelah menambahkan kredensial identitas federasi.

Menyebarkan beban kerja dengan sidecar migrasi

Catatan

Sidecar migrasi tidak didukung untuk penggunaan produksi. Fitur ini dimaksudkan untuk memberi Anda waktu untuk memigrasikan SDK aplikasi Anda ke versi yang didukung, dan tidak dimaksudkan atau dimaksudkan untuk menjadi solusi jangka panjang. Sidecar migrasi hanya untuk kontainer Linux karena identitas yang dikelola pod hanya tersedia di kumpulan simpul Linux.

Jika aplikasi Anda menggunakan identitas terkelola dan masih bergantung pada IMDS untuk mendapatkan token akses, Anda dapat menggunakan sidecar migrasi identitas beban kerja untuk mulai bermigrasi ke identitas beban kerja. Sidecar ini adalah solusi migrasi dan dalam aplikasi jangka panjang, Anda harus memodifikasi kodenya untuk menggunakan Azure Identity SDK terbaru yang mendukung pernyataan klien.

Untuk memperbarui atau menyebarkan beban kerja, tambahkan anotasi pod ini hanya jika Anda ingin menggunakan sidecar migrasi. Anda menyuntikkan nilai anotasi berikut untuk menggunakan sidecar dalam spesifikasi pod Anda:

  • azure.workload.identity/inject-proxy-sidecar - nilai adalah true atau false
  • azure.workload.identity/proxy-sidecar-port - nilai adalah port yang diinginkan untuk sidecar proksi. Nilai defaultnya adalah 8000.

Ketika pod dengan anotasi di atas dibuat, Identitas Beban Kerja Azure yang bermutasi webhook secara otomatis menyuntikkan kontainer init dan sidecar proksi ke spesifikasi pod.

Webhook yang sudah berjalan menambahkan cuplikan YAML berikut ke penyebaran pod. Berikut ini adalah contoh spesifikasi pod yang dimutasi:

apiVersion: v1
kind: Pod
metadata:
  name: httpbin-pod
  labels:
    app: httpbin
    azure.workload.identity/use: "true"
  annotations:
    azure.workload.identity/inject-proxy-sidecar: "true"
spec:
  serviceAccountName: workload-identity-sa
  initContainers:
  - name: init-networking
    image: mcr.microsoft.com/oss/azure/workload-identity/proxy-init:v1.1.0
    securityContext:
      capabilities:
        add:
        - NET_ADMIN
        drop:
        - ALL
      privileged: true
      runAsUser: 0
    env:
    - name: PROXY_PORT
      value: "8000"
  containers:
  - name: nginx
    image: nginx:alpine
    ports:
    - containerPort: 80
  - name: proxy
    image: mcr.microsoft.com/oss/azure/workload-identity/proxy:v1.1.0
    ports:
    - containerPort: 8000

Konfigurasi ini berlaku untuk konfigurasi apa pun di mana pod sedang dibuat. Setelah memperbarui atau menyebarkan aplikasi, Anda dapat memverifikasi pod dalam keadaan berjalan menggunakan perintah kubectl describe pod . Ganti nilai podName dengan nama gambar pod yang Anda sebarkan.

kubectl describe pods podName

Untuk memverifikasi bahwa pod melewati transaksi IMDS, gunakan perintah log kubectl. Ganti nilai podName dengan nama gambar pod yang Anda sebarkan:

kubectl logs podName

Output log berikut menyerupan komunikasi yang berhasil melalui sidecar proksi. Pastikan log menunjukkan token berhasil diperoleh dan operasi GET berhasil.

I0926 00:29:29.968723       1 proxy.go:97] proxy "msg"="starting the proxy server" "port"=8080 "userAgent"="azure-workload-identity/proxy/v0.13.0-12-gc8527f3 (linux/amd64) c8527f3/2022-09-26-00:19"
I0926 00:29:29.972496       1 proxy.go:173] proxy "msg"="received readyz request" "method"="GET" "uri"="/readyz"
I0926 00:29:30.936769       1 proxy.go:107] proxy "msg"="received token request" "method"="GET" "uri"="/metadata/identity/oauth2/token?resource=https://management.core.windows.net/api-version=2018-02-01&client_id=<client_id>"
I0926 00:29:31.101998       1 proxy.go:129] proxy "msg"="successfully acquired token" "method"="GET" "uri"="/metadata/identity/oauth2/token?resource=https://management.core.windows.net/api-version=2018-02-01&client_id=<client_id>"

Menghapus identitas yang dikelola pod

Setelah menyelesaikan pengujian dan aplikasi berhasil mendapatkan token menggunakan sidecar proksi, Anda dapat menghapus pemetaan identitas yang dikelola pod Microsoft Entra untuk pod dari kluster Anda, lalu menghapus identitas.

  1. Jalankan perintah az aks pod-identity delete untuk menghapus identitas dari pod Anda. Ini hanya boleh dilakukan setelah semua pod di namespace menggunakan pemetaan identitas yang dikelola pod telah dimigrasikan untuk menggunakan sidecar.

    az aks pod-identity delete --name podIdentityName --namespace podIdentityNamespace --resource-group myResourceGroup --cluster-name myAKSCluster

Langkah berikutnya

Artikel ini menunjukkan cara menyiapkan pod untuk mengautentikasi menggunakan identitas beban kerja sebagai opsi migrasi. Untuk informasi selengkapnya tentang ID Beban Kerja Microsoft Entra, lihat artikel Gambaran Umum berikut ini.