在本文中，您將學習如何部署並配置使用 Microsoft Entra 工作負載 ID 的 Azure Kubernetes Service（AKS）叢集。 本文的步驟包括：
- 使用Azure CLI並啟用OpenID Connect（OIDC）發行者並啟用Microsoft Entra Workload ID，建立新或更新現有的AKS叢集。
- 建立一個工作負載識別碼和 Kubernetes 服務帳號。
- 設定權杖同盟的受控識別。
- 部署工作負載，並使用工作負載身分識別驗證。
- 選擇性地向叢集中的 Pod 授與 Azure 金鑰保存庫中秘密的存取權。
先決條件
- 如果您沒有 Azure 帳戶，請在開始之前建立 免費帳戶 。
- 本文必須使用 Azure CLI 2.47.0 版或更新版本。 如果您是使用 Azure Cloud Shell，就已安裝最新版本。
- 確保您用來建立叢集的身分識別擁有適當的最低權限。 欲了解更多資訊，請參閱 Azure Kubernetes Service（AKS）的存取與身份選項。
- 如果您有多個 Azure 訂用帳戶，則請使用
az account set命令選取應該從中針對資源計費的適當訂用帳戶識別碼。
附註
您可以使用「服務連接器」來協助您自動設定某些步驟。 欲了解更多資訊，請參閱 教學：使用 Microsoft Entra Workload ID 使用 Service Connector 連接 Azure Kubernetes Service （AKS） 中的 Azure 儲存帳號。
建立資源群組
使用
az group create命令建立資源群組。export RANDOM_ID="$(openssl rand -hex 3)" export RESOURCE_GROUP="myResourceGroup$RANDOM_ID" export LOCATION="<your-preferred-region>" az group create --name "${RESOURCE_GROUP}" --location "${LOCATION}"
在 AKS 叢集中啟用 OIDC 發行者及 Microsoft Entra 載荷 ID
你可以在新建或現有的 AKS 叢集上啟用 OIDC 發行者和 Microsoft Entra 工作負載 ID。
使用
az aks create命令並搭配--enable-oidc-issuer參數啟用 OIDC 發行者，以及使用--enable-workload-identity參數啟用 Microsoft Entra 工作負載 ID 來建立 AKS 叢集。 下列範例會建立具有單一節點的叢集：export CLUSTER_NAME="myAKSCluster$RANDOM_ID" az aks create \ --resource-group "${RESOURCE_GROUP}" \ --name "${CLUSTER_NAME}" \ --enable-oidc-issuer \ --enable-workload-identity \ --generate-ssh-keys在幾分鐘之後，此命令就會完成，並以 JSON 格式傳回叢集的相關資訊。
擷取 OIDC 簽發者 URL
取得 OIDC 發行者的 URL，並使用 [
az aks show][az-aks-show] 指令儲存為環境變數。export AKS_OIDC_ISSUER="$(az aks show --name "${CLUSTER_NAME}" \ --resource-group "${RESOURCE_GROUP}" \ --query "oidcIssuerProfile.issuerUrl" \ --output tsv)"環境變數應包含與下列範例類似的簽發者 URL：
https://eastus.oic.prod-aks.azure.com/00000000-0000-0000-0000-000000000000/11111111-1111-1111-1111-111111111111/根據預設，簽發者會設定為使用基底 URL
https://{region}.oic.prod-aks.azure.com/{tenant_id}/{uuid}，其中{region}的值會符合作為 AKS 叢集部署目的地的位置。 該值{uuid}代表 OIDC 鍵，是每個叢集隨機產生且不可變的 GUID。
建立受控識別
取得你的訂閱 ID，並使用 [
az account show][az-account-show] 指令儲存到環境變數。export SUBSCRIPTION="$(az account show --query id --output tsv)"使用
az identity create命令建立使用者指派的受控識別。export USER_ASSIGNED_IDENTITY_NAME="myIdentity$RANDOM_ID" az identity create \ --name "${USER_ASSIGNED_IDENTITY_NAME}" \ --resource-group "${RESOURCE_GROUP}" \ --location "${LOCATION}" \ --subscription "${SUBSCRIPTION}"下列輸出範例顯示已成功建立受控識別：
{ "clientId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx", "id": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourcegroups/myResourceGroupxxxxxx/providers/Microsoft.ManagedIdentity/userAssignedIdentities/myIdentityxxxxxx", "location": "eastus", "name": "myIdentityxxxxxx", "principalId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx", "resourceGroup": "myResourceGroupxxxxxx", "systemData": null, "tags": {}, "tenantId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx", "type": "Microsoft.ManagedIdentity/userAssignedIdentities" }取得受管理身份的客戶端 ID，並使用 [
az identity show][az-identity-show] 指令儲存到環境變數。export USER_ASSIGNED_CLIENT_ID="$(az identity show \ --resource-group "${RESOURCE_GROUP}" \ --name "${USER_ASSIGNED_IDENTITY_NAME}" \ --query 'clientId' \ --output tsv)"
建立 Kubernetes 服務帳戶
使用
az aks get-credentials命令連線至您的 AKS 叢集。az aks get-credentials --name "${CLUSTER_NAME}" --resource-group "${RESOURCE_GROUP}"建立一個 Kubernetes 服務帳號，並透過以下
kubectl apply指令套用 manifest 來註記管理身份的客戶端 ID：export SERVICE_ACCOUNT_NAME="workload-identity-sa$RANDOM_ID" export SERVICE_ACCOUNT_NAMESPACE="default" 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下列輸出顯示工作負載身分識別建立成功：
serviceaccount/workload-identity-sa created
建立同盟身分識別認證
使用
az identity federated-credential create指令建立一個聯邦身份憑證，連接管理身份、服務帳號發行者與主體。export FEDERATED_IDENTITY_CREDENTIAL_NAME="myFedIdentity$RANDOM_ID" az identity federated-credential create \ --name ${FEDERATED_IDENTITY_CREDENTIAL_NAME} \ --identity-name "${USER_ASSIGNED_IDENTITY_NAME}" \ --resource-group "${RESOURCE_GROUP}" \ --issuer "${AKS_OIDC_ISSUER}" \ --subject system:serviceaccount:"${SERVICE_ACCOUNT_NAMESPACE}":"${SERVICE_ACCOUNT_NAME}" \ --audience api://AzureADTokenExchange附註
新增同盟身分認證後，需要幾秒鐘的時間才能傳播。 如果在新增同盟身分識別認證後立即提出權杖要求，在重新整理快取之前，要求可能會失敗。 若要避免此問題，您可以在新增同盟身分識別認證之後稍待片刻，再提出權杖要求。
如需 Microsoft Entra 中同盟身分識別認證的詳細資訊，請參閱 Microsoft Entra ID 中的同盟身分識別認證概觀。
建立具有 Azure RBAC 授權的金鑰保存庫
下列範例會示範如何使用 Azure 角色型存取控制 (Azure RBAC) 權限模型，向 Pod 授與金鑰保存庫的存取權。 如需 Azure Key Vault 的 Azure RBAC 權限模型詳細資訊，請參閱使用 Azure RBAC 向應用程式授與存取 Azure 金鑰保存庫的權限。
使用 [
az keyvault create][az-keyvault-create] 指令建立一個帶有清除保護且啟用 Azure RBAC 授權的金鑰保險庫。 如果現有的金鑰保存庫已設定為清除保護和 Azure RBAC 授權，您也可以使用它：export KEYVAULT_NAME="keyvault-workload-id$RANDOM_ID" # Ensure the key vault name is between 3-24 characters az keyvault create \ --name "${KEYVAULT_NAME}" \ --resource-group "${RESOURCE_GROUP}" \ --location "${LOCATION}" \ --enable-purge-protection \ --enable-rbac-authorization取得金鑰保險庫的資源 ID，並使用 [
az keyvault show][az-keyvault-show] 指令儲存到環境變數。export KEYVAULT_RESOURCE_ID=$(az keyvault show --resource-group "${RESOURCE_GROUP}" \ --name "${KEYVAULT_NAME}" \ --query id \ --output tsv)
指派 RBAC 權限來管理金鑰保險庫
取得呼叫者物件 ID，並使用 [
az ad signed-in-user show][az-ad-signed-in-user-show] 指令儲存到環境變數。export CALLER_OBJECT_ID=$(az ad signed-in-user show --query id -o tsv)請為自己指派 Azure RBAC 金鑰庫秘密官 角色，這樣你就能使用 [
az role assignment create][az-role-assignment-create] 指令在新的金鑰庫中建立秘密。az role assignment create --assignee "${CALLER_OBJECT_ID}" \ --role "Key Vault Secrets Officer" \ --scope "${KEYVAULT_RESOURCE_ID}"
建立與設定秘密存取
在金鑰庫中使用 [
az keyvault secret set][az-keyvault-secret-set] 指令建立一個秘密。export KEYVAULT_SECRET_NAME="my-secret$RANDOM_ID" az keyvault secret set \ --vault-name "${KEYVAULT_NAME}" \ --name "${KEYVAULT_SECRET_NAME}" \ --value "Hello\!"取得使用者指派的管理身份的主 ID，並使用 [
az identity show][az-identity-show] 指令儲存到環境變數中。export IDENTITY_PRINCIPAL_ID=$(az identity show \ --name "${USER_ASSIGNED_IDENTITY_NAME}" \ --resource-group "${RESOURCE_GROUP}" \ --query principalId \ --output tsv)使用 [][az-role-assignment-create] 指令，將
az role assignment create角色指派給使用者指定的管理身份。 此步驟賦予受管理身份從金鑰庫讀取秘密的權限。az role assignment create \ --assignee-object-id "${IDENTITY_PRINCIPAL_ID}" \ --role "Key Vault Secrets User" \ --scope "${KEYVAULT_RESOURCE_ID}" \ --assignee-principal-type ServicePrincipal請使用 [
az keyvault show][az-keyvault-show] 指令為金鑰保險庫的 URL 建立環境變數：export KEYVAULT_URL="$(az keyvault show \ --resource-group "${RESOURCE_GROUP}" \ --name ${KEYVAULT_NAME} \ --query properties.vaultUri \ --output tsv)"
部署驗證艙並測試存取權限
部署一個 pod 來驗證工作負載身份 (Workload Identity) 是否能存取金鑰庫中的機密。 以下範例使用該
ghcr.io/azure/azure-workload-identity/msal-go映像，該映像包含一個範例應用程式，該範例應用程式使用 Microsoft Entra 工作負載 ID 從 Azure Key Vault 提取機密：kubectl apply -f - <<EOF apiVersion: v1 kind: Pod metadata: name: sample-workload-identity-key-vault namespace: ${SERVICE_ACCOUNT_NAMESPACE} labels: azure.workload.identity/use: "true" spec: serviceAccountName: ${SERVICE_ACCOUNT_NAME} containers: - image: ghcr.io/azure/azure-workload-identity/msal-go name: oidc env: - name: KEYVAULT_URL value: ${KEYVAULT_URL} - name: SECRET_NAME value: ${KEYVAULT_SECRET_NAME} nodeSelector: kubernetes.io/os: linux EOF使用
kubectl wait指令，等待 pod 進入Ready狀態。kubectl wait --namespace ${SERVICE_ACCOUNT_NAMESPACE} --for=condition=Ready pod/sample-workload-identity-key-vault --timeout=120s用指令
kubectl describe檢查 pod 裡的環境變數SECRET_NAME是否已設定。kubectl describe pod sample-workload-identity-key-vault | grep "SECRET_NAME:"如果成功，輸出應該類似下列範例：
SECRET_NAME: ${KEYVAULT_SECRET_NAME}確認 pods 是否能取得 token，並用指令
kubectl logs存取資源。kubectl logs sample-workload-identity-key-vault如果成功，輸出應該類似下列範例：
I0114 10:35:09.795900 1 main.go:63] "successfully got secret" secret="Hello\\!"重要事項
Azure RBAC 角色指派最多可能需要 10 分鐘才能傳播。 如果 Pod 無法存取秘密，您可能需要等候角色指派散佈開來。 如需詳細資訊，請參閱針對 Azure RBAC 進行疑難排解。
在 AKS 叢集上停用 Microsoft Entra Workload ID
在已啟用並設定的 AKS 叢集上停用 Microsoft Entra 工作負載 ID，並用
az aks update帶有--disable-workload-identity參數的指令更新 AKS 叢集。az aks update \ --resource-group "${RESOURCE_GROUP}" \ --name "${CLUSTER_NAME}" \ --disable-workload-identity
相關內容
在本文中，你部署了一個 Kubernetes 叢集，並設定它使用 Microsoft Entra 工作負載 ID，為應用程式工作負載用該憑證認證做準備。 現在您已準備好部署應用程式，並將其設定為使用工作負載身分識別搭配最新版的 Azure 身分識別用戶端程式庫。 如果您無法將應用程式重寫為使用最新的用戶端程式庫版本，您可以設定應用程式 Pod，以使用受控識別搭配工作負載身分識別進行驗證，作為短期移轉解決方案。
服務連接器整合有助於簡化 AKS 工作負載和 Azure 備份服務的連線設定。 其會安全地處理驗證和網路設定，並遵循連線至 Azure 服務的最佳做法。 欲了解更多資訊，請參閱使用 Microsoft Entra Workload Identity 在 AKS 的 Foundry 模型中連接 Azure OpenAI 及 服務連接器介紹。
