在 AKS Edge Essentials 群集上配置工作负荷标识（预览版）

项目
11/16/2024

Azure Kubernetes 服务（AKS） Edge Essentials 是Azure Kubernetes 服务（AKS）的本地 Kubernetes 实现，可大规模自动运行容器化应用程序。本文介绍如何执行以下任务：

创建 Kubernetes 服务帐户并将其绑定到 Azure 托管标识。
在托管标识上创建联合凭据，以信任 OIDC 颁发者。
部署应用程序。
示例：向群集中的 Pod 授予对 Azure 密钥保管库中机密的访问权限。

有关工作负荷标识联合的概念性概述，请参阅已启用 Azure Arc 的 Kubernetes 中的工作负荷标识联合（预览版）。

重要

这些预览功能在自助服务上可用，可选择加入。预览功能是“按现状”和“按可用”提供的，不包括在服务级别协议和有限保证中。 Azure Kubernetes 服务 Edge Essentials 预览版部分由客户支持人员尽最大努力涵盖。

注意

在此公共预览版中，AKS Edge Essentials 允许在 Azure IoT 操作快速入门脚本的初始部署期间启用工作负荷标识。此功能不适用于其他 AKS Edge Essentials 方案。

先决条件

在使用 AKS Edge Essentials 群集的工作负荷标识联合之前，必须部署 Azure IoT 操作快速入门脚本，如创建和配置可以运行 Azure IoT 操作的 AKS Edge Essentials 群集中所述。该脚本会自动在 AKS Edge Essentials 群集上启用工作负荷标识联合功能。

部署 AKS Edge Essentials 群集后，可以使用以下命令检查工作负荷标识扩展的状态：

az connectedk8s show -n $aks_cluster_name -g $resource_group_name

# agentState = "Succeeded" 
"agentPublicKeyCertificate": "", 
  "agentVersion": "1.21.10", 
  "arcAgentProfile": { 
    "agentAutoUpgrade": "Enabled", 
    "agentErrors": [], 
    "agentState": "Succeeded", 
    "desiredAgentVersion": "", 
    "systemComponents": null 

# oidcIssuerProfile "enabled": true and "issuerUrl" present 
"oidcIssuerProfile": { 
    "enabled": true, 
    "issuerUrl": "https://oidcdiscovery-{location}-endpoint-1111111111111111.000.azurefd.net/00000000-0000-0000-0000-000000000000/11111111-1111-1111-1111-111111111111/", 

# workloadIdentity "enabled": true 
"securityProfile": { 
    "workloadIdentity": { 
      "enabled": true

在Azure 门户中，可以在 Kubernetes 群集的“属性”部分下查看wiextension扩展。

导出环境变量

为了帮助简化配置所需标识的步骤，以下步骤定义本文示例中引用的环境变量。请务必将显示的值替换为你自己的值：

$AZSubscriptionID = "00000000-0000-0000-0000-000000000000" 
$Location = "westeurope" 
$resource_group_name = "myResourceGroup" 

$aks_cluster_name = "myAKSCluster" 

$SERVICE_ACCOUNT_NAMESPACE = "default" 
$SERVICE_ACCOUNT_NAME = "workload-identity-sa" 

$FedIdCredentialName = "myFedIdentity" 
$MSIName = "myIdentity" 

# Include these variables to access key vault secrets from a pod in the cluster. 
$KVName = "KV-workload-id" 
$KVSecretName= "KV-secret"

将 OIDC 颁发者 URL 保存到环境变量

若要获取 OIDC 颁发者 URL 并将其保存到环境变量，请运行以下命令：

$SERVICE_ACCOUNT_ISSUER =$(az connectedk8s show --n $aks_cluster_name --resource-group $resource_group_name --query "oidcIssuerProfile.issuerUrl" --output tsv)

步骤 1：创建 Kubernetes 服务帐户并将其绑定到 Azure 托管标识

首先，调用 az identity create 命令以创建托管标识：

az identity create --name $MSIName --resource-group $resource_group_name --location $Location --subscription $AZSubscriptionID

接下来，为托管标识的客户端 ID 创建变量：

$MSIId=$(az identity show --resource-group $resource_group_name --name $MSIName --query 'clientId' --output tsv)  
$MSIPrincipalId=$(az identity show --resource-group $resource_group_name --name $MSIName --query 'principalId' --output tsv)

创建 Kubernetes 服务帐户

创建 Kubernetes 服务帐户，并使用在上一步中创建的托管标识的客户端 ID 对其进行批注。复制并粘贴以下 Azure CLI 命令：

$yaml = @" 
apiVersion: v1 
kind: ServiceAccount 
metadata: 
  annotations: 
    azure.workload.identity/client-id: $MSIId 
  name: $SERVICE_ACCOUNT_NAME 
  namespace: $SERVICE_ACCOUNT_NAMESPACE 
"@ 

# Replace variables within the YAML content 
$yaml = $yaml -replace '\$MSIId', $MSIId ` 
              -replace '\$SERVICE_ACCOUNT_NAME', $SERVICE_ACCOUNT_NAME ` 
              -replace '\$SERVICE_ACCOUNT_NAMESPACE', $SERVICE_ACCOUNT_NAMESPACE 

# Apply the YAML content to Kubernetes 
$yaml | kubectl apply -f -

以下输出显示已成功创建的工作负荷标识：

serviceaccount/workload-identity-sa created

步骤 2：在托管标识上创建联合凭据以信任 OIDC 颁发者

若要在托管标识、服务帐户颁发者和使用者之间创建联合标识凭据，请调用 az identity federated-credential create 命令。有关 Microsoft Entra 中联合标识凭据的详细信息，请参阅 Microsoft Entra ID 中的联合标识凭据概述。

# Create a federated credential 
az identity federated-credential create --name $FedIdCredentialName --identity-name $MSIName --resource-group $resource_group_name --issuer $SERVICE_ACCOUNT_ISSUER --subject "system:serviceaccount:${SERVICE_ACCOUNT_NAMESPACE}:${SERVICE_ACCOUNT_NAME}" 

# Show the federated credential 
az identity federated-credential show --name $FedIdCredentialName --resource-group $resource_group_name --identity-name $MSIName

注意

添加联合标识凭据后，传播需要几秒钟时间。缓存刷新之前，立即发出的令牌请求可能会失败。若要防止此问题，请考虑在创建联合标识凭据后添加短暂延迟。

步骤 3：部署应用程序

部署应用程序 Pod 时，清单应引用在创建 Kubernetes 服务帐户步骤中创建的服务帐户。以下清单演示如何引用帐户，特别是帐户 metadata\namespace 和 spec\serviceAccountName 属性。请确保为 image 指定映像，并为 containerName 指定容器名称：

$image = "<image>"  # Replace <image> with the actual image name 
$containerName = "<containerName>"  # Replace <containerName> with the actual container name 

$yaml = @" 
apiVersion: v1 
kind: Pod 
metadata: 
  name: sample-quick-start 
  namespace: $SERVICE_ACCOUNT_NAMESPACE 
  labels: 
    azure.workload.identity/use: "true" # Required. Only pods with this label can use workload identity. 
spec: 
  serviceAccountName: $SERVICE_ACCOUNT_NAME 
  containers: 
    - image: $image 
      name: $containerName 
"@ 

# Replace variables within the YAML content 
$yaml = $yaml -replace '\$SERVICE_ACCOUNT_NAMESPACE', $SERVICE_ACCOUNT_NAMESPACE ` 
                -replace '\$SERVICE_ACCOUNT_NAME', $SERVICE_ACCOUNT_NAME 

# Apply the YAML configuration 
$yaml | kubectl apply -f -

重要

确保使用工作负荷标识的应用程序 Pod 在 Pod 规范中包含标签 azure.workload.identity/use: "true" 。否则，Pod 在重启后会失败。

示例：授予访问 Azure 密钥库的权限

此步骤中的说明介绍如何从 Pod 访问 Azure 密钥保管库中的机密、密钥或证书。本部分中的示例为工作负载标识配置对密钥保管库中机密的访问权限，但你可以执行类似的步骤来配置对密钥或证书的访问权限。

以下示例演示如何使用 Azure 基于角色的访问控制 (Azure RBAC) 权限模型向 Pod 授予访问密钥保管库的权限。有关 Azure Key Vault 的 Azure RBAC 权限模型的详细信息，请参阅使用 Azure RBAC 授予应用程序访问 Azure Key Vault 的权限。

创建启用了清除保护功能和 RBAC 授权的新密钥保管库。如果为清除保护功能和 RBAC 授权配置了现有密钥保管库，也可以使用它：

az keyvault create --name $KVName --resource-group $resource_group_name --location $Location --enable-purge-protection --enable-rbac-authorization

# retrieve the key vault ID for role assignment
$KVId=$(az keyvault show --resource-group $resource_group_name --name $KVName --query id --output tsv)

将 RBAC 密钥库 Secrets Officer 角色分配给自己，以便可以在新的密钥保管库中创建机密。新角色分配可能需要最多 5 分钟完成传播并由授权服务器更新。
```
az role assignment create --assignee-object-id $MSIPrincipalId --role "Key Vault Secrets Officer" --scope $KVId --assignee-principal-type ServicePrincipal
```

在密钥保管库中创建机密：

az keyvault secret set --vault-name $KVName --name $KVSecretName --value "Hello!"

将密钥保管库机密用户角色分配给之前创建的用户分配的托管标识。此步骤授予托管标识从密钥保管库读取机密的权限：
```
az role assignment create --assignee-object-id $MSIPrincipalId --role "Key Vault Secrets User" --scope $KVId --assignee-principal-type ServicePrincipal
```

为密钥保管库 URL 创建环境变量：

$KVUrl=$(az keyvault show --resource-group $resource_group_name --name $KVName --query properties.vaultUri --output tsv)

部署引用上服务帐户和密钥保管库 URL 的 Pod：

$yaml = @" 
apiVersion: v1 
kind: Pod
metadata:
  name: sample-quick-start
  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: $KVUrl 
      - name: SECRET_NAME 
        value: $KVSecretName 
  nodeSelector:
    kubernetes.io/os: linux
"@

# Replace variables within the YAML content 
$yaml = $yaml -replace '\$SERVICE_ACCOUNT_NAMESPACE', $SERVICE_ACCOUNT_NAMESPACE ` 
                -replace '\$SERVICE_ACCOUNT_NAME', $SERVICE_ACCOUNT_NAME ` 
                -replace '\$KVUrl', $KVUrl ` 
                -replace '\$KVSecretName', $KVSecretName 

# Apply the YAML configuration
$yaml | kubectl --kubeconfig $aks_cluster_name apply -f -

后续步骤

在本文中，你已将其配置为使用工作负荷标识来准备应用程序工作负荷以使用该凭据进行身份验证。现在，你已准备好部署应用程序并将其配置为将工作负荷标识与最新版 Azure 标识客户端库配合使用。

通过