Partager via

Utiliser un principal de service avec Azure Kubernetes Service (AKS)

Les clusters Azure Kubernetes Service (AKS) nécessitent un principal de service Microsoft Entra ou une identité managée pour créer et gérer dynamiquement d’autres ressources Azure. Cet article explique comment créer un principal de service Microsoft Entra et l’utiliser avec votre cluster AKS.

Remarque

Pour une sécurité optimale et une facilité d’utilisation, nous vous recommandons d’utiliser des identités managées plutôt que des principaux de service pour autoriser l’accès à partir d’un cluster AKS vers d’autres ressources dans Azure. Une identité managée est un type spécial de principal de service que vous pouvez utiliser pour obtenir les informations d’identification Microsoft Entra sans avoir à gérer et sécuriser les informations d’identification. Pour plus d’informations, consultez Utiliser une identité managée dans AKS.

Prérequis

  • Vous avez besoin d’Azure CLI version 2.0.59 ou ultérieure. Recherchez votre version à l’aide de la az --version commande. Si vous devez installer ou mettre à niveau, voir Installer Azure CLI.
  • Si vous utilisez Azure PowerShell, vous avez besoin d’Azure PowerShell version 5.0.0 ou ultérieure. Recherchez votre version à l’aide de la cmdlet Get-InstalledModule -Name Az. Si vous devez installer ou mettre à niveau, consultez Installer le module PowerShell Azure Az.
  • Vous avez besoin d’autorisations pour inscrire une application auprès de votre locataire Microsoft Entra et affecter l’application à un rôle dans votre abonnement. Si vous n’avez pas les autorisations nécessaires, vous devez demander à votre administrateur Microsoft Entra ID ou abonnement d’attribuer les autorisations nécessaires ou de créer le principal de service pour vous.

Considérations relatives à l’utilisation d’un principal de service

Gardez à l’esprit les considérations suivantes lors de l’utilisation d’un principal de service Microsoft Entra avec AKS :

  • Le principal de service de Kubernetes fait partie de la configuration du cluster, mais n’utilisez pas cette identité pour déployer le cluster. Au lieu de cela, créez d’abord un principal de service , puis utilisez ce principal de service pour créer le cluster AKS.
  • Chaque principal de service est associé à une application Microsoft Entra. Vous pouvez associer le principal de service d’un cluster Kubernetes à tout nom d’application Microsoft Entra valide (par exemple : https://www.contoso.org/example). L’URL de l’application ne doit pas être un point de terminaison réel.
  • Lorsque vous spécifiez l’ID client du principal de service, utilisez la valeur de l’ID d’application (appId pour Azure CLI ou ApplicationId pour Azure PowerShell).
  • Sur les machines virtuelles (VM) des nœuds agents du cluster AKS, les informations d’identification du principal de service sont stockées dans le fichier /etc/kubernetes/azure.json.
  • Lorsque vous supprimez un cluster AKS que vous avez créé à l’aide de la az aks create commande ou de l’applet New-AzAksCluster de commande, le principal de service créé n’est pas automatiquement supprimé. Consultez les étapes de suppression d’un principal de service.
  • Si vous utilisez le principal du service d’un autre locataire Microsoft Entra, il y a d’autres points à prendre en considération quant aux autorisations disponibles au moment de déployer le cluster. Vous n’avez peut-être pas les autorisations appropriées pour lire et écrire des informations sur le répertoire. Pour plus d’informations, consultez Quelles sont les autorisations utilisateur par défaut dans Microsoft Entra ID ?

Créer un principal de service

  1. Créez un principal de service à l’aide de la commande az ad sp create-for-rbac.

    # Set environment variable
SERVICE_PRINCIPAL_NAME=<your-service-principal-name>

# Create the service principal
az ad sp create-for-rbac --name $SERVICE_PRINCIPAL_NAME

    Votre résultat devrait être semblable à l’exemple de sortie suivant :

    {
  "appId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
  "displayName": "myAKSClusterServicePrincipal",
  "name": "http://myAKSClusterServicePrincipal",
  "password": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
  "tenant": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
}

  2. Copiez les valeurs pour appId et password à partir de la sortie à utiliser lors de la création du cluster AKS.

  1. Créez un principal de service à l’aide de la commande New-AzADServicePrincipal.

    # Set environment variable
$SpName = <your-service-principal-name>

# Create the service principal
New-AzADServicePrincipal -DisplayName $SpName -OutVariable sp

    Votre résultat devrait être semblable à l’exemple de sortie suivant :

    Secret                : System.Security.SecureString
ServicePrincipalNames : {xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx, http://myAKSClusterServicePrincipal}
ApplicationId         : xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
ObjectType            : ServicePrincipal
DisplayName           : myAKSClusterServicePrincipal
Id                    : xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
Type                  :

    Les valeurs sont stockées dans une variable que vous utilisez lors de la création du cluster AKS.

  2. Déchiffrez la valeur stockée dans la chaîne sécurisée Secret à l’aide la commande suivante.

    $BSTR = [System.Runtime.InteropServices.Marshal]::SecureStringToBSTR($sp.Secret)
[System.Runtime.InteropServices.Marshal]::PtrToStringAuto($BSTR)

Créer un cluster AKS avec un principal de service existant

  • Créez un cluster AKS avec un principal de service existant à l'aide de la commande az aks create avec les paramètres --service-principal et --client-secret définis pour spécifier les valeurs appId et password.

    # Set environment variables
RESOURCE_GROUP=<your-resource-group-name>
CLUSTER_NAME=<your-aks-cluster-name>
APP_ID=<app-id>
CLIENT_SECRET=<password-value>

# Create the AKS cluster
az aks create \
    --resource-group $RESOURCE_GROUP \
    --name $CLUSTER_NAME \
    --service-principal $APP_ID \
    --client-secret $CLIENT_SECRET \
    --generate-ssh-keys

  1. Convertissez les principaux de service ApplicationId et Secret en un objet PSCredential à l’aide de la commande suivante.

    $Cred = New-Object -TypeName System.Management.Automation.PSCredential ($sp.ApplicationId, $sp.Secret)

  2. Créez un cluster AKS avec un principal de service existant à l’aide de l’applet New-AzAksCluster de commande et spécifiez le paramètre avec l’objet ServicePrincipalIdAndSecretPSCredential comme valeur.

    # Set environment variables
$ResourceGroupName = <your-resource-group-name>
$ClusterName = <your-aks-cluster-name>

# Create the AKS cluster
New-AzAksCluster -ResourceGroupName $ResourceGroupName -Name $ClusterName -ServicePrincipalIdAndSecret $Cred

Remarque

Si vous utilisez un principal de service existant avec un secret personnalisé, assurez-vous que le secret ne dépasse pas 190 octets.

Déléguer l’accès à d’autres ressources Azure

Vous pouvez utiliser le principal de service du cluster AKS pour accéder à d’autres ressources. Par exemple, si vous souhaitez déployer votre cluster AKS dans un sous-réseau d'un réseau virtuel Azure existant, vous connecter à ACR ou accéder à des clés ou des secrets dans un coffre de clés à partir de votre cluster, vous devez déléguer l'accès à ces ressources au principal de service. Pour déléguer l’accès, attribuez un rôle Azure de contrôle d’accès en fonction du rôle (Azure RBAC) au principal du service.

Lorsque vous attribuez des rôles, vous spécifiez l’étendue de l’attribution de rôle, telle qu’un groupe de ressources ou une ressource de réseau virtuel. L’attribution de rôle détermine les autorisations dont dispose le principal de service sur la ressource et leur étendue.

Important

Les autorisations accordées à un principal de service associé à un cluster peuvent prendre jusqu’à 60 minutes pour se propager.

Créer une attribution de rôle

Remarque

L’étendue d’une ressource doit être un ID de ressource complet, tel que /subscriptions/\<guid\>/resourceGroups/myResourceGroup ou /subscriptions/\<guid\>/resourceGroups/myResourceGroupVnet/providers/Microsoft.Network/virtualNetworks/myVnet.

  • Créez une affectation de rôle à l’aide de la commande az role assignment create. Spécifiez la valeur de l’ID d’application du principal de service pour le --assignee paramètre et l’étendue de l’attribution de rôle pour le --scope paramètre. L’exemple suivant assigne les autorisations au principal de service pour accéder aux secrets dans un Key Vault :

    az role assignment create \
    --assignee <app-id> \
    --scope "/subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.KeyVault/vaults/<vault-name>" \
    --role "Key Vault Secrets User"

  • Créez une attribution de rôle à l'aide du cmdlet New-AzRoleAssignment. Spécifiez la valeur de l’ID d’application du principal de service pour le -ApplicationId paramètre et l’étendue de l’attribution de rôle pour le -Scope paramètre. L'exemple suivant attribue au principal du service les autorisations pour accéder aux secrets dans un coffre de clés :

    New-AzRoleAssignment -ApplicationId <app-id> `
    -Scope "/subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.KeyVault/vaults/<vault-name>" `
    -RoleDefinitionName "Key Vault Secrets User"

Accorder l’accès à Azure Container Registry

Si vous utilisez Azure Container Registry (ACR) comme magasin d’images conteneur, vous devez accorder des autorisations au principal de service pour que votre cluster AKS puisse lire et extraire des images. Nous vous recommandons de suivre les étapes de l’authentification auprès d’Azure Container Registry à partir d’Azure Kubernetes Service pour s’intégrer à un registre et attribuer le rôle approprié pour le principal de service.

Accorder l’accès aux ressources réseau

Si vous utilisez une mise en réseau avancée avec un réseau virtuel et un sous-réseau ou des adresses IP publiques dans différents groupes de ressources, vous pouvez affecter le rôle intégré Contributeur de réseau sur le sous-réseau au sein du réseau virtuel. Vous pouvez également créer un rôle personnalisé avec des autorisations d’accès aux ressources réseau dans ce groupe de ressources. Pour plus d’informations, consultez Autorisations de service AKS.

Accorder l’accès aux disques de stockage

Si vous devez accéder aux ressources de disque existantes dans un autre groupe de ressources, attribuez l’un des ensembles d’autorisations de rôle suivants :

Accorder l’accès à Azure Container Instances

Si vous utilisez kubelet virtuel pour intégrer AKS et exécuter Azure Container Instances (ACI) dans un groupe de ressources distinct du cluster AKS, vous devez attribuer des autorisations contributeur au principal du service de cluster AKS pour le groupe de ressources ACI.

Supprimer un principal de service

  • Recherchez l’ID client du principal de service (servicePrincipalProfile.clientId) et supprimez le principal de service à l’aide de la az ad sp delete commande avec le --id paramètre. La commande [az aks show][az-aks-show] récupère l’ID client du cluster AKS spécifié.

    # Set environment variables
RESOURCE_GROUP=<your-resource-group-name>
CLUSTER_NAME=<your-aks-cluster-name>

# Delete the service principal
az ad sp delete --id $(az aks show \
    --resource-group $RESOURCE_GROUP \
    --name $CLUSTER_NAME \
    --query servicePrincipalProfile.clientId \
    --output tsv)

  • Recherchez l'ID client du principal de service (ServicePrincipalProfile.ClientId) et supprimez le principal de service à l'aide du cmdlet Remove-AzADServicePrincipal avec le paramètre -ApplicationId. L’applet de commande [Get-AzAksCluster][get-azakscluster] récupère l’ID client du cluster AKS spécifié.

    # Set environment variables
$ResourceGroupName = <your-resource-group-name>
$ClusterName = <your-aks-cluster-name>
$ClientId = (Get-AzAksCluster -ResourceGroupName myResourceGroup -Name myAKSCluster ).ServicePrincipalProfile.ClientId

# Delete the service principal
Remove-AzADServicePrincipal -ApplicationId $ClientId

Résoudre les problèmes d'identifiants du principal de service

Azure CLI met en cache les informations d’identification du principal de service des clusters AKS.

Azure PowerShell met en cache les informations d’identification du principal de service des clusters AKS.

Si ces informations d’identification expirent, vous pouvez rencontrer des erreurs pendant le déploiement du cluster AKS. S’il existe un problème avec les informations d’identification mises en cache, vous pouvez recevoir un message d’erreur similaire au message d’erreur suivant :

Operation failed with status: 'Bad Request'.
Details: The credentials in ServicePrincipalProfile were invalid. Please see https://aka.ms/aks-sp-help for more details.
Details: adal: Refresh request failed. Status Code = '401'.

Vous pouvez vérifier la date d’expiration des informations d’identification de votre principal de service à l’aide de la commande az ad app credential list avec la requête "[].endDateTime". La sortie vous présente la endDateTime de vos informations d’identification.

az ad app credential list \
    --id <app-id> \
    --query "[].endDateTime" \
    --output tsv
  • Vérifiez la date d’expiration de vos identifiants de service principal à l’aide de la cmdlet Get-AzADAppCredential. La sortie vous présente la EndDate de vos informations d’identification.
Get-AzADAppCredential -ApplicationId <app-id>

Le délai d’expiration par défaut pour les informations d’identification du principal de service est d’un an. Si vos informations d’identification datent de plus d’un an, vous pouvez réinitialiser les informations d’identification existantes ou créer un principal de service.

Contenu connexe

  • Last updated on