Partager via

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

  • Article

Un cluster AKS nécessite un principal de service Microsoft Entra ou une identité managée pour créer et gérer dynamiquement d’autres ressources Azure, telles qu’un Azure Load Balancer ou un Azure Container Registry (ACR).

Remarque

Nous vous recommandons d’utiliser des identités managées pour vous authentifier avec d’autres ressources dans Azure. Il s’agit de la méthode d’authentification par défaut pour votre cluster AKS. Pour plus d’informations sur l’utilisation d’une identité managée avec votre cluster, consultez Utiliser une identité managée affectée par le système.

Cet article vous montre comment créer et utiliser un principal de service pour vos clusters AKS.

Avant de commencer

Pour créer un principal de service Microsoft Entra, vous devez disposer des autorisations suffisantes pour inscrire une application auprès de votre client Microsoft Entra et l’affecter à un rôle dans votre abonnement. Si vous n’avez pas les autorisations nécessaires, vous devrez demander à votre administrateur Microsoft Entra ID ou à votre administrateur d’abonnement de vous attribuer les autorisations nécessaires ou de créer au préalable un principal de service que vous pourrez utiliser avec votre cluster AKS.

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 adéquates pour lire et écrire des informations d’annuaire. Pour plus d’informations, consultez Quelles sont les autorisations utilisateur par défaut dans Microsoft Entra ID ?

Prérequis

  • Si vous utilisez Azure CLI, vous avez besoin d’Azure CLI version 2.0.59 ou ultérieure. Exécutez az --version pour trouver la version. 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. Exécutez Get-InstalledModule -Name Az pour trouver la version. Si vous devez installer ou mettre à niveau, consultez Installer le module PowerShell Azure Az.

Créer manuellement un principal de service

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

    az ad sp create-for-rbac --name myAKSClusterServicePrincipal

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

    {
  "appId": "559513bd-0c19-4c1a-87cd-851a26afd5fc",
  "displayName": "myAKSClusterServicePrincipal",
  "name": "http://myAKSClusterServicePrincipal",
  "password": "e763725a-5eee-40e8-a466-dc88d980f415",
  "tenant": "72f988bf-86f1-41af-91ab-2d7cd011db48"
}

  2. Copiez les valeurs de appId et password à partir de la sortie. Vous les utilisez lors de la création d’un cluster AKS dans la section suivante.

Spécifier un principal de service pour un cluster AKS

  • Utilisez un principal de service existant pour un nouveau cluster AKS à l’aide de la commande az aks createet utilisez les paramètres --service-principal et --client-secret pour spécifier appId et password de la sortie que vous avez reçue dans la section précédente.

    az aks create \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --service-principal <appId> \
    --client-secret <password>

    Notes

    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 de réseau virtuel Azure existant ou vous connecter à ACR (Azure Container Registry), vous devez déléguer l’accès à ces ressources au principal du service. L’autorisation accordée à un cluster à l’aide d’une identité managée affectée par le système peut prendre jusqu’à 60 minutes.

  • Créez une affectation de rôle à l’aide de la commande az role assignment create. Affectez appId à une étendue spécifique, comme un groupe de ressources ou une ressource de réseau virtuel. Le rôle définit les autorisations dont dispose le principal de service sur la ressource.

    Notes

    L’élément --scope 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.

    az role assignment create --assignee <appId> --scope <resourceScope> --role Contributor

Les sections suivantes détaillent les délégations courantes que vous serez peut-être amené à affecter.

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 d’utiliser la commande az aks create ou az aks update pour l’intégration à un registre et l’attribution du rôle approprié au principal de service. Pour connaître les étapes détaillées, consultez S’authentifier avec Azure Container Registry à partir d’Azure Kubernetes Service.

Mise en réseau

Vous pouvez utiliser un réseau avancé dans lequel le réseau virtuel et le sous-réseau, ou les adresses IP publiques, se trouvent dans un autre groupe de ressources. Attribuez le rôle intégré Contributeur de réseaux sur le sous-réseau dans le 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.

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 :

Azure Container Instances

Si vous utilisez Virtual Kubelet pour intégrer à AKS et choisissez d’exécuter Azure Container Instances (ACI) dans un groupe de ressources distinct sur le cluster AKS, le principal du service du cluster AKS doit disposer de l’autorisation Contributeur sur le groupe de ressources ACI.

Autres considérations

Lorsque vous utilisez AKS et un principal de service Microsoft Entra, tenez compte des éléments suivants :

  • Le principal de service de Kubernetes fait partie de la configuration du cluster, mais n’utilisez pas cette identité pour déployer le cluster.
  • Par défaut, les informations d’identification du principal du service sont valides pendant un an. Vous pouvez à tout moment mettre à jour ou faire pivoter les informations d’identification du principal du service.
  • 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 appId.
  • Sur les machines virtuelles du nœud de l’agent du cluster Kubernetes, les informations d’identification du principal du service sont stockées dans le fichier /etc/kubernetes/azure.json.
  • Si vous supprimez un cluster AKS qui a été créé à l’aide de la commande az aks create, le principal de service créé n’est pas automatiquement supprimé.

    • Pour supprimer le principal de service, demandez le servicePrincipalProfile.clientId de vos clusters, et supprimez-le à l’aide de la commande az ad sp delete. Remplacez les valeurs du paramètre -g pour le nom du groupe de ressources et du paramètre -n pour le nom du cluster :

      az ad sp delete --id $(az aks show -g myResourceGroup -n myAKSCluster --query servicePrincipalProfile.clientId -o tsv)

Dépanner

Azure CLI met en cache les informations d’identification du principal de service des clusters AKS. Si ces informations d’identification expirent, vous rencontrez des erreurs pendant le déploiement du cluster AKS. Si vous exécutez la commande az aks create et recevez un message d’erreur similaire au message suivant, cela peut indiquer un problème avec les informations d’identification du principal de service mises en cache :

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

az ad app credential list --id <app-id> --query "[].endDateTime" -o tsv

Le délai d’expiration par défaut des informations d’identification du principal du service est d’une année. 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.

Résolution des problèmes généraux d’Azure CLI

Azure CLI peut s’exécuter dans plusieurs environnements de shell, mais avec de légères variations en termes de format. Si vous avez des résultats inattendus avec des commandes Azure CLI, consultez Comment utiliser Azure CLI avec succès.

Étapes suivantes

Pour plus d’informations sur les principaux de service Microsoft Entra, consultez Objets du principal de service et application.

Pour plus d’informations sur la mise à jour des informations d’identification, consultez Mettre à jour ou faire pivoter les informations d’identification d’un principal de service dans AKS.