從 Pod 受控識別移轉至工作負載身分識別
本文專注於從 Pod 受控識別移轉至 Azure Kubernetes Service (AKS) 叢集的 Microsoft Entra 工作負載識別碼。 其也會依據容器型應用程式所使用的 Azure 身分識別用戶端程式庫版本來提供指引。
如果您不熟悉 Microsoft Entra 工作負載識別碼,則請參閱下列概觀文章。
開始之前
Azure CLI 2.47.0 版或更新版本。 執行 az --version
以尋找版本,然後執行 az upgrade
以升級版本。 如果您需要安裝或升級,請參閱安裝 Azure CLI。
移轉案例
本節說明可用的移轉選項,視安裝的 Azure 身分識別 SDK 版本而定。
在任一案例中,您都必須先設定同盟信任,才能更新應用程式以使用工作負載身分識別。 下列是所需的最少步驟:
- 建立受控識別認證。
- 將受控識別與已用於 Pod 受控識別的 Kubernetes 服務帳戶建立關聯,或建立新的 Kubernetes 服務帳戶,然後將其與受控識別建立關聯。
- 在受控識別與 Microsoft Entra ID 之間建立同盟信任關係。
從最新版本移轉
如果您的應用程式已使用最新版的 Azure 身分識別 SDK,則請執行下列步驟以完成驗證設定:
- 使用 Pod 受控身分識別來平行部署工作負載身分識別。 您可以重新啟動應用程式部署,以開始使用工作負載身分識別,其中應用程式部署會自動將 OIDC 註釋插入應用程式中。
- 驗證應用程式能夠成功驗證之後,您可以從應用程式移除 Pod 受控識別註釋,然後移除 Pod 受控識別附加元件。
從舊版移轉
如果您的應用程式未使用 Azure 身分識別 SDK 最新版本,則您有兩個選項:
您可以使用我們在您 Linux 應用程式內提供的移轉 Sidecar,其會將應用程式所做的 IMDS 交易 Proxy 處理成 OpenID Connect (OIDC)。 移轉 Sidecar 並非長期解決方案,而是在工作負載身分識別上快速啟動並執行的方式。 請執行下列步驟,以:
- 使用移轉 Sidecar 部署工作負載,透過 Proxy 處理應用程式 IMDS 交易。
- 確認正在成功完成驗證交易。
- 排程應用程式的工作,以將 SDK 更新為所支援的版本。
- SDK 更新為支援的版本之後,您可以移除 Proxy Sidecar,並重新部署應用程式。
注意
移轉 Sidecar「不支援用於生產環境」。 此功能旨在讓您有時間將應用程式 SDK 移轉至所支援的版本,而不是長期解決方案。 因為只提供具有 Linux 節點集區的 Pod 受控身分識別,所以移轉 Sidecar 僅適用於 Linux 容器。
重寫您的應用程式,以支援最新版的 Azure 身分識別用戶端程式庫。 之後,執行下列步驟:
- 重新啟動應用程式部署,以使用工作負載身分識別開始驗證。
- 確認驗證交易成功完成之後,您可以從應用程式移除 Pod 受控識別註釋,然後移除 Pod 受控識別附加元件。
建立受控識別
如果您未建立受控識別並將其指派給 Pod,請執行下列步驟來建立並授與儲存體、Key Vault 或您的應用程式必須在 Azure 中驗證之任何資源的必要權限。
使用 Azure CLI az account set 命令,將特定訂閱設定為目前使用中訂閱。 然後使用 az identity create 命令來建立受控識別。
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)"
授與存取 Azure 中資源所需的權限給受控識別。 如需做法的相關資訊,請參閱將受控識別存取權指派給資源。
若要取得 OIDC 簽發者 URL 並將其儲存至環境變數,請執行下列命令。 取代叢集名稱和資源群組名稱的預設值。
export AKS_OIDC_ISSUER="$(az aks show --name myAKSCluster --resource-group myResourceGroup --query "oidcIssuerProfile.issuerUrl" -o tsv)"
此變數應該包含與下列範例類似的簽發者 URL:
https://eastus.oic.prod-aks.azure.com/00000000-0000-0000-0000-000000000000/00000000-0000-0000-0000-000000000000/
根據預設,簽發者會設定為使用基底 URL
https://{region}.oic.prod-aks.azure.com/{uuid}
,其中{region}
的值符合 AKS 叢集部署所在的位置。 值{uuid}
代表 OIDC 金鑰。
建立 Kubernetes 服務帳戶
若您未為此應用程式建立專用 Kubernetes 服務帳戶,請執行下列步驟來建立,然後使用在上一個步驟中建立的受控識別用戶端識別碼予以標註。 使用 az aks get-credentials 命令,並取代叢集名稱與資源群組名稱的值。
az aks get-credentials --name myAKSCluster --resource-group "${RESOURCE_GROUP}"
在 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
下列輸出與成功的身分識別建立類似:
Serviceaccount/workload-identity-sa created
建立同盟身分識別認證信任
使用 az identity federated-credential create 命令,在受控識別、服務帳戶簽發者與主體之間建立同盟身分識別認證。 取代 resourceGroupName
、userAssignedIdentityName
、federatedIdentityName
、serviceAccountNamespace
和 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
注意
一開始新增之後,同盟身分識別認證需要幾秒鐘的時間才能散佈。 若在新增同盟身分識別認證之後立即提出權杖要求,可能會導致幾分鐘的失敗,因為快取會在目錄中填入舊的資料。 若要避免此問題,您可以在新增同盟身分識別認證之後稍待片刻,再提出權杖要求。
使用移轉 Sidecar 部署工作負載
注意
移轉 Sidecar「不支援用於生產環境」。 此功能旨在讓您有時間將應用程式 SDK 移轉至所支援的版本,而不是長期解決方案。 因為只有在 Linux 節點集區中才能使用 Pod 受控身分識別,所以移轉 Sidecar 僅適用於 Linux 容器。
若您的應用程式正在使用受控識別,並且仍依賴 IMDS 來取得存取權杖,您可以使用工作負載身分識別移轉 Sidecar 來啟動工作負載身分識別的移轉。 此 Sidecar 是一種移轉解決方案,在長期應用程式中,您應該修改其程式碼,以使用支援用戶端判斷提示的最新 Azure 身分識別 SDK。
若要更新或部署工作負載,請只在您想要使用移轉 Sidecar 時才新增這些 Pod 註釋。 插入下列註釋值,以在 Pod 規格中使用 Sidecar:
azure.workload.identity/inject-proxy-sidecar
- 值為true
或false
azure.workload.identity/proxy-sidecar-port
- 值為 Proxy Sidecar 所要的連接埠。 預設值是8000
。
建立具有上述註釋的 Pod 時,Azure 工作負載身分識別變動 Webhook 會自動將 Init 容器與 Proxy Sidecar 插入 Pod 規格。
已在執行的 Webhook 會將下列 YAML 程式碼片段新增至 Pod 部署。 下列是已變動 Pod 規格的範例:
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
此設定適用於正在建立 Pod 的任何設定。 更新或部署應用程式之後,您可以使用 kubectl describe pod 命令來確認 Pod 處於執行狀態。 以您已部署 Pod 的映像名稱取代值 podName
。
kubectl describe pods podName
若要確認 Pod 正在傳遞 IMDS 交易,請使用 kubectl logs 命令。 以您已部署 Pod 的映像名稱取代值 podName
:
kubectl logs podName
下列記錄輸出類似透過 Proxy Sidecar 成功進行通訊。 確認記錄顯示權杖已成功取得,且 GET 作業成功。
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>"
移除 Pod 受控識別
在您完成測試並成功讓應用程式能夠使用 Proxy Sidecar 取得權杖之後,可以從叢集中移除 Pod 的 Microsoft Entra Pod 受控識別對應,然後移除身分識別。
執行 az aks pod-identity delete 命令,從 Pod 中移除身分識別。 只有在命名空間中使用 Pod 受控識別對應的所有 Pod 都已移轉為使用 Sidecar 之後,才應該執行此動作。
az aks pod-identity delete --name podIdentityName --namespace podIdentityNamespace --resource-group myResourceGroup --cluster-name myAKSCluster
下一步
本文顯示如何將 Pod 設定為使用工作負載身分識別進行驗證,以作為移轉選項。 如需 Microsoft Entra 工作負載識別碼的詳細資訊,請參閱下列概觀文章。