Implementación y configuración de la identidad de carga de trabajo en una instancia de AKS habilitada por el clúster de Azure Arc (versión preliminar)

Artículo
11/23/2024

Se aplica a: Azure Local, versión 23H2

La federación de identidades de carga de trabajo permite configurar una identidad administrada asignada por el usuario o un registro de aplicaciones en el identificador de Microsoft Entra para confiar en tokens de un proveedor de identidades externo (IdP), como Kubernetes, lo que permite el acceso a los recursos protegidos por Microsoft Entra, como Azure Key Vault o Azure Blob Storage.

Azure Kubernetes Service (AKS) habilitado por Azure Arc es un servicio de Kubernetes administrado que permite implementar fácilmente clústeres de Kubernetes habilitados para la identidad de carga de trabajo. En este artículo se describe cómo realizar las siguientes tareas:

Cree un clúster de AKS Arc con la identidad de carga de trabajo habilitada (versión preliminar).
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.

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. Azure Kubernetes Service, habilitado por las versiones preliminares de Azure Arc, están parcialmente cubiertos por el soporte técnico al cliente de la mejor manera posible.

Nota:

En versión preliminar pública, AKS en Azure Stack HCI admite la habilitación de la identidad de carga de trabajo durante la creación del clúster de AKS. Sin embargo, la habilitación de la identidad de carga de trabajo después de la creación del clúster o la deshabilitación posterior no se admite actualmente.

Requisitos previos

Antes de implementar un clúster de Kubernetes con Azure Arc habilitado, debe tener los siguientes requisitos previos:

Si no tiene una suscripción a Azure, cree una cuenta gratuita de Azure antes de empezar.
En este artículo se requiere la versión 1.4.23 o posterior de la CLI de Azure. Si usa Azure Cloud Shell, ya está instalada la versión más reciente.

Exportación de variables de entorno

Para ayudar a simplificar los pasos para configurar las identidades necesarias, los siguientes comandos definen las variables de entorno a las que se hace referencia en los ejemplos de este artículo. Reemplace los valores siguientes por los que considere adecuados:

$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" 

# To access key vault secrets from a pod in the cluster, include these variables:
$KVName = "KV-workload-id" 
$KVSecretName= "KV-secret"

Establecimiento de la suscripción activa

En primer lugar, establezca la suscripción como la suscripción activa actual. Ejecute el comando az account set con el identificador de suscripción:

az login  
az account set -s $AZSubscriptionID

Crear un grupo de recursos

Un grupo de recursos de Azure es un grupo lógico en el que se implementan y administran recursos de Azure. Cuando crea un grupo de recursos, se le pide que especifique una ubicación. Esta ubicación es la ubicación de almacenamiento de los metadatos del grupo de recursos y donde se ejecutan los recursos en Azure si no se especifica otra región durante la creación de recursos.

Para crear un grupo de recursos, ejecute el comando az group create:

az group create --name $resource_group_name --location $Location

En la salida de ejemplo siguiente se muestra la creación correcta de un grupo de recursos:

{ 
  "id": "/subscriptions/<guid>/resourceGroups/myResourceGroup", 
  "location": "westeurope", 
  "managedBy": null, 
  "name": "$resource_group_name", 
  "properties": { 
    "provisioningState": "Succeeded" 
  }, 
  "tags": null 
}

Paso 1: Creación de un clúster de AKS Arc con la identidad de carga de trabajo habilitada

Para crear un clúster de AKS Arc, necesita los $customlocation_ID valores y $logicnet_Id .

$customlocation_ID: el identificador de Azure Resource Manager de la ubicación personalizada. La ubicación personalizada se configura durante la implementación del clúster de Azure Stack HCI. El administrador de infraestructura debe proporcionarle el identificador de Resource Manager de la ubicación personalizada. También puede obtener el identificador de Resource Manager mediante $customlocation_ID = $(az customlocation show --name "<your-custom-location-name>" --resource-group $resource_group_name --query "id" -o tsv), si el administrador de infraestructura proporciona un nombre de ubicación personalizado y un nombre de grupo de recursos.
$logicnet_Id: el identificador de Azure Resource Manager de la red lógica local de Azure creada siguiendo estos pasos. El administrador de infraestructura debe proporcionar el identificador de Resource Manager de la red lógica. También puede obtener el identificador de Resource Manager mediante $logicnet_Id = $(az stack-hci-vm network lnet show --name "<your-lnet-name>" --resource-group $resource_group_name --query "id" -o tsv), si el administrador de infraestructura proporciona un nombre de red lógico y un nombre de grupo de recursos.

Ejecute el comando az aksarc create con el --enable-oidc-issuer --enable-workload-identity parámetro . Proporcione los identificadores entra-admin-group-object-ids y asegúrese de que es miembro del grupo de administración de id. de Entra de Microsoft para el acceso al modo proxy:

az aksarc create  
-n $aks_cluster_name -g $resource_group_name  
--custom-location $customlocation_ID --vnet-ids $logicnet_Id  
--aad-admin-group-object-ids <entra-admin-group-object-ids> 
--generate-ssh-keys  
--enable-oidc-issuer --enable-workload-identity

Transcurridos unos minutos, el comando se completa y devuelve información en formato JSON sobre el clúster.

La extensión de identidad de carga de trabajo puede tardar algún tiempo en implementarse después de crear correctamente un clúster aprovisionado. Use el comando siguiente 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/"}

En Azure Portal, puede ver la extensión wiextension en la sección Propiedades del clúster de Kubernetes.

Importante

Como parte de la mejora de seguridad de los clústeres de AKS Arc, la habilitación de la identidad de carga de trabajo desencadena dos cambios. En primer lugar, la clave de firma de la cuenta de servicio de Kubernetes gira automáticamente cada 45 días y permanece válida durante 90 días. En segundo lugar, la marca está deshabilitada, lo que reduce la --service-account-extend-token-expiration validez del token de un año a un máximo de 24 horas.

Guardar la dirección URL del emisor de OIDC en una variable de entorno

Una vez creado correctamente el clúster de AKS, puede obtener la dirección URL del emisor de OIDC y guardarlo 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 2: Creación de una cuenta de servicio de Kubernetes y enlacela a la identidad administrada de Azure

En primer lugar, cree una identidad administrada. Ejecute el comando az identity create :

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 creada en el paso anterior:

az connectedk8s proxy -n $aks_cluster_name -g $resource_group_name

Abra una nueva ventana de . Copie y pegue los siguientes comandos de la CLI:

$yaml = @" apiVersion: v1 kind: ServiceAccount metadata: annotations: azure.workload.identity/client-id: $MSIId name: $SERVICE_ACCOUNT_NAME namespace: $SERVICE_ACCOUNT_NAMESPACE "@ $yaml = $yaml -replace '\$MSIId', $MSIId ` -replace '\$SERVICE_ACCOUNT_NAME', $SERVICE_ACCOUNT_NAME ` -replace '\$SERVICE_ACCOUNT_NAMESPACE', $SERVICE_ACCOUNT_NAMESPACE $yaml | kubectl apply -f -

La siguiente salida muestra la creación correcta de la cuenta de servicio:

serviceaccount/workload-identity-sa created

Paso 3: Creación de una credencial federada en la identidad administrada para confiar en el emisor de OIDC

En primer lugar, cree una credencial de identidad federada. Llame al comando az identity federated-credential create para crear la credencial de identidad federada entre la identidad administrada, el emisor de la cuenta de servicio y el asunto. 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 4: 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, ha implementado un clúster de Kubernetes y lo ha configurado para usar una identidad de carga de trabajo como 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.

Compartir a través de

Implementación y configuración de la identidad de carga de trabajo en una instancia de AKS habilitada por el clúster de Azure Arc (versión preliminar)

Requisitos previos

Exportación de variables de entorno

Establecimiento de la suscripción activa

Crear un grupo de recursos

Paso 1: Creación de un clúster de AKS Arc con la identidad de carga de trabajo habilitada

Guardar la dirección URL del emisor de OIDC en una variable de entorno

Paso 2: Creación de una cuenta de servicio de Kubernetes y enlacela a la identidad administrada de Azure

Creación de una cuenta de servicio de Kubernetes

Paso 3: Creación de una credencial federada en la identidad administrada para confiar en el emisor de OIDC

Paso 4: Implementación de la aplicación

Ejemplo: Concesión de permisos para acceder a Azure Key Vault

Pasos siguientes

Comentarios

Recursos adicionales