Configuración de la identidad de carga de trabajo en un clúster de AKS Edge Essentials (versión preliminar)
Azure Kubernetes Service (AKS) Edge Essentials es una implementación local de Kubernetes de Azure Kubernetes Service (AKS) que automatiza la ejecución de aplicaciones en contenedores a escala. En este artículo se describe cómo realizar las siguientes tareas:
- Cree una cuenta de servicio de Kubernetes y enlazarla a la identidad administrada de Azure.
- Cree una credencial federada en la identidad administrada para confiar en el emisor de OIDC.
- Implementación de aplicación.
- Ejemplo: conceda a un pod del clúster acceso a secretos en un almacén de claves de Azure.
Para obtener información general conceptual sobre la federación de identidades de carga de trabajo, consulte Federación de identidades de carga de trabajo en Kubernetes habilitado para Azure Arc (versión preliminar).
Importante
Estas características en versión preliminar están disponibles de forma automática. Las versiones preliminares se proporcionan "tal cual" y "como están disponibles", y están excluidas de los Acuerdos de nivel de servicio y garantía limitada. Las versiones preliminares de Azure Kubernetes Service Edge Essentials están parcialmente cubiertas por el soporte técnico al cliente de la mejor manera posible.
Nota:
En esta versión preliminar pública, AKS Edge Essentials permite habilitar la identidad de la carga de trabajo durante la implementación inicial del script de inicio rápido de Azure IoT Operations. Esta característica no está disponible para otros escenarios de AKS Edge Essentials.
Requisitos previos
Antes de usar la federación de identidades de carga de trabajo para un clúster de AKS Edge Essentials, debe implementar el script de inicio rápido de la operación de Azure IoT, tal como se describe en Creación y configuración de un clúster de AKS Edge Essentials que pueda ejecutar operaciones de Azure IoT. El script habilita automáticamente la característica de federación de identidades de carga de trabajo en el clúster de AKS Edge Essentials.
Después de implementar el clúster de AKS Edge Essentials, puede usar el siguiente comando para comprobar el estado de la extensión de identidad de carga de trabajo:
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
En Azure Portal, puede ver la wiextension
extensión en la sección Propiedades del clúster de Kubernetes.
Exportación de variables de entorno
Para ayudar a simplificar los pasos para configurar las identidades necesarias, los pasos siguientes definen las variables de entorno a las que se hace referencia en los ejemplos de este artículo. No olvide reemplazar los valores mostrados por sus propios valores:
$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"
Guardar la dirección URL del emisor de OIDC en una variable de entorno
Para obtener la dirección URL del emisor de OIDC y guardarla en una variable de entorno, ejecute el siguiente comando:
$SERVICE_ACCOUNT_ISSUER =$(az connectedk8s show --n $aks_cluster_name --resource-group $resource_group_name --query "oidcIssuerProfile.issuerUrl" --output tsv)
Paso 1: Creación de una cuenta de servicio de Kubernetes y enlacela a la identidad administrada de Azure
En primer lugar, llame al comando az identity create para crear una identidad administrada:
az identity create --name $MSIName --resource-group $resource_group_name --location $Location --subscription $AZSubscriptionID
A continuación, cree variables para el identificador de cliente de la identidad administrada:
$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)
Creación de una cuenta de servicio de Kubernetes
Cree una cuenta de servicio de Kubernetes y anote con el identificador de cliente de la identidad administrada que creó en el paso anterior. Copie y pegue los siguientes comandos de la CLI de Azure:
$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 -
En la salida siguiente se muestra la identidad de carga de trabajo creada correctamente:
serviceaccount/workload-identity-sa created
Paso 2: Creación de una credencial federada en la identidad administrada para confiar en el emisor de OIDC
Para crear la credencial de identidad federada entre la identidad administrada, el emisor de la cuenta de servicio y el firmante, llame al comando az identity federated-credential create . Para más información sobre las credenciales de identidad federada en Microsoft Entra, consulte Introducción a las credenciales de identidad federada en 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
Nota:
Después de agregar una credencial de identidad federada, se tarda unos segundos en propagarse. Es posible que las solicitudes de token realizadas inmediatamente después produzcan un error hasta que se actualice la memoria caché. Para evitar este problema, considere la posibilidad de agregar un breve retraso después de crear la credencial de identidad federada.
Paso 3: Implementación de la aplicación
Al implementar los pods de aplicación, el manifiesto debe hacer referencia a la cuenta de servicio creada en el paso Crear cuenta de servicio de Kubernetes. En el manifiesto siguiente se muestra cómo hacer referencia a la cuenta, específicamente las metadata\namespace
propiedades y spec\serviceAccountName
. Asegúrese de especificar una imagen para image
y un nombre de contenedor para 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 -
Importante
Asegúrese de que los pods de aplicación que usan la identidad de carga de trabajo incluyan la etiqueta azure.workload.identity/use: "true"
en la especificación del pod. De lo contrario, los pods no se pueden realizar después de reiniciar.
Ejemplo: Concesión de permisos para acceder a Azure Key Vault
Las instrucciones de este paso describen cómo acceder a secretos, claves o certificados en un almacén de claves de Azure desde el pod. Los ejemplos de esta sección configuran el acceso a secretos en el almacén de claves para la identidad de carga de trabajo, pero puede realizar pasos similares para configurar el acceso a claves o certificados.
En el ejemplo siguiente se muestra cómo usar el modelo de permisos de control de acceso basado en rol (RBAC) de Azure para conceder al pod acceso al almacén de claves. Para más información sobre el modelo de permisos RBAC de Azure para Azure Key Vault, consulte Concesión de permisos a las aplicaciones para que accedan a una instancia de Azure Key Vault mediante RBAC de Azure.
Cree un almacén de claves con protección de purga y autorización de RBAC habilitada. También puede usar un almacén de claves existente si está configurado para la protección de purga y la autorización de 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)
Asigne el rol Oficial de secretos de Key Vault de RBAC a sí mismo para poder crear un secreto en el nuevo almacén de claves. Las nuevas asignaciones de roles pueden tardar hasta cinco minutos en propagarse y actualizarse mediante el servidor de autorización.
az role assignment create --assignee-object-id $MSIPrincipalId --role "Key Vault Secrets Officer" --scope $KVId --assignee-principal-type ServicePrincipal
Cree un secreto en un almacén de claves:
az keyvault secret set --vault-name $KVName --name $KVSecretName --value "Hello!"
Asigne el rol Usuario de secretos del almacén de claves a la identidad administrada asignada por el usuario que creó anteriormente. En este paso se concede el permiso de identidad administrada para leer secretos del almacén de claves:
az role assignment create --assignee-object-id $MSIPrincipalId --role "Key Vault Secrets User" --scope $KVId --assignee-principal-type ServicePrincipal
Cree una variable de entorno para la dirección URL del almacén de claves:
$KVUrl=$(az keyvault show --resource-group $resource_group_name --name $KVName --query properties.vaultUri --output tsv)
Implemente un pod que haga referencia a la cuenta de servicio y la dirección URL del almacén de claves:
$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 -
Pasos siguientes
En este artículo, lo configuró para usar una identidad de carga de trabajo en preparación para que las cargas de trabajo de la aplicación se autentiquen con esa credencial. Ahora está listo para implementar la aplicación y configurarla para usar la identidad de carga de trabajo con la versión más reciente de la biblioteca cliente de Azure Identity.