Utiliser des identités managées par pod Microsoft Entra dans Azure Kubernetes Service (préversion)

Les identités managées par pod Microsoft Entra utilisent des primitives Kubernetes pour associer des identités managées pour les ressources Azure et des identités dans Microsoft Entra ID avec des pods. Les administrateurs créent des identités et des liaisons en tant que primitives Kubernetes qui permettent aux pods d’accéder aux ressources Azure qui reposent sur Microsoft Entra ID en tant que fournisseur d’identité.

Important

Nous vous recommandons d’examiner l’identifiant de charge de travail Microsoft Entra. Cette méthode d’authentification remplace l’identité managée par pod (préversion), qui s’intègre avec les fonctionnalités natives Kubernetes pour opérer une fédération avec tout fournisseur d’identité externe, au nom de l’application.

L'identité managée par pod Microsoft Entra open source (préversion)dans Azure Kubernetes Service est déconseillée depuis le 24/10/2022, et le projet a été archivé en septembre 2023. Si vous souhaitez obtenir plus d’informations, voir l’avis de dépréciation officiel. Le module complémentaire managé AKS commence à être déprécié en septembre 2024.

Pour désactiver le module complémentaire géré par AKS, utilisez la commande suivante : az feature unregister --namespace "Microsoft.ContainerService" --name "EnablePodIdentityPreview".

Avant de commencer

Vous devez avoir installé Azure CLI version 2.20.0 ou une version ultérieure.

Limites

  • 200 identités managées par pod sont autorisées au maximum pour un cluster.
  • 200 exceptions d’identités managées par pod sont autorisées au maximum pour un cluster.
  • Les identités managées par pod sont disponibles uniquement sur les pools de nœuds Linux.
  • Cette fonctionnalité est uniquement prise en charge pour les clusters supportés par des groupes de machines virtuelles identiques.

Installer l’extension Azure CLI aks-preview

Important

Les fonctionnalités d’évaluation AKS sont disponibles en libre-service et font l’objet d’un abonnement. Les préversions sont fournies « en l’état » et « en fonction des disponibilités », et sont exclues des contrats de niveau de service et de la garantie limitée. Les préversions AKS sont, dans la mesure du possible, partiellement couvertes par le service clientèle. Telles quelles, ces fonctionnalités ne sont pas destinées à une utilisation en production. Pour plus d’informations, consultez les articles de support suivants :

Exécutez la commande suivante pour installer l’extension aks-preview :

az extension add --name aks-preview

Exécutez la commande suivante pour effectuer la mise à jour vers la dernière version de l’extension publiée :

az extension update --name aks-preview

Inscrire l’étiquette de fonctionnalité « EnablePodIdentityPreview »

Inscrivez l’indicateur de fonctionnalité EnablePodIdentityPreview à l’aide de la commande az feature register, comme indiqué dans l’exemple suivant :

az feature register --namespace "Microsoft.ContainerService" --name "EnablePodIdentityPreview"

Quelques minutes sont nécessaires pour que l’état s’affiche Registered (Inscrit). Vérifiez l’état de l’inscription à l’aide de la commande az feature show :

az feature show --namespace "Microsoft.ContainerService" --name "EnablePodIdentityPreview"

Une fois que l’état reflète Inscrit, actualisez l’inscription du fournisseur de ressources Microsoft.ContainerService à l’aide de la commande az provider register :

az provider register --namespace Microsoft.ContainerService

Options du mode d’opération

L’identité managée par pod Microsoft Entra prend en charge deux modes d’opération :

  • Mode standard : dans ce mode, les deux composants suivants sont déployés sur le cluster AKS :
    • Managed Identity Controller (MIC) : contrôleur Kubernetes qui surveille les modifications apportées aux pods, AzureIdentity et AzureIdentityBinding, via le serveur d’API Kubernetes. Lorsqu’il détecte une modification pertinente, le MIC ajoute ou supprime AzureAssignedIdentity en fonction des besoins. Plus précisément, quand un pod est planifié, le MIC affecte l’identité managée sur Azure au groupe de machines virtuelles identiques sous-jacent que le pool de nœuds utilise au cours de la phase de création. Quand tous les pods utilisant l’identité sont supprimés, il supprime l’identité du groupe de machines virtuelles identiques du pool de nœuds, sauf si la même identité managée est utilisée par d’autres pods. Le MIC effectue des actions similaires quand AzureIdentity ou AzureIdentityBinding sont créés ou supprimés.
    • Node Managed Identity (NMI) : pod qui s’exécute en tant que DaemonSet sur chaque nœud du cluster AKS. L’identité NMI intercepte les demandes de jeton de sécurité adressées à l’Instance Metadata Service Azure sur chaque nœud, les redirige vers elle-même et vérifie si le pod a accès à l’identité pour laquelle il demande un jeton et récupère le jeton auprès du locataire Microsoft Entra pour le compte de l’application.
  • Mode managé : ce mode offre uniquement le pod NMI. Lorsqu’il est installé via le module complémentaire de cluster AKS, Azure gère la création de primitives Kubernetes (AzureIdentity et AzureIdentityBinding) et l’attribution d’identité en réponse aux commandes CLI par l’utilisateur. Dans le cas contraire, s’il est installé via le graphique Helm, l’identité doit être affectée et gérée manuellement par l’utilisateur. Pour plus d’informations, consultez Identité des pods en mode managé.

Quand vous installez l’identité managée par pod Microsoft Entra via le graphique Helm ou le manifeste YAML comme indiqué dans le Guide d’Installation, vous pouvez choisir entre les modes standard et managed. Si, à la place, vous décidez d’installer l’identité managée par pod Microsoft Entra à l’aide du module complémentaire de cluster AKS comme indiqué dans l’article, le programme d’installation utilise le mode managed.

Créer un cluster AKS avec Azure Container Networking Interface (CNI)

Notes

Il s’agit de la configuration recommandée par défaut.

Créez un cluster AKS avec Azure CNI et une identité managée par pod activée. Les commande suivantes utilisent az group create pour créer un groupe de ressources nommé myResourceGroup et la commande az aks create pour créer un cluster AKS nommé myAKSCluster dans le groupe de ressources myResourceGroup.

az group create --name myResourceGroup --location eastus
az aks create -g myResourceGroup -n myAKSCluster --enable-pod-identity --network-plugin azure

Utilisez az aks get-credentials pour vous connecter à votre cluster AKS. Cette commande télécharge et configure également le certificat client kubectl sur votre ordinateur de développement.

az aks get-credentials --resource-group myResourceGroup --name myAKSCluster

Notes

Lorsque vous activez l’identité managée par pod sur votre cluster AKS, une AzurePodIdentityException nommée aks-addon-exception est ajoutée à l’espace de noms kube-system. Une AzurePodIdentityException permet aux pods avec certaines étiquettes d’accéder au point de terminaison Instance Metadata Service (IMDS) Azure sans être interceptés par le serveur NMI. aks-addon-exception permet aux modules complémentaires internes AKS, comme pour une identité managée par pod Microsoft Entra, de fonctionner sans avoir à configurer manuellement de AzurePodIdentityException. Si vous le souhaitez, vous pouvez ajouter, supprimer et mettre à jour une AzurePodIdentityException à l’aide de az aks pod-identity exception add, az aks pod-identity exception delete, az aks pod-identity exception update ou kubectl.

Mettre à jour un cluster AKS existant avec Azure CNI

Mettez à jour un cluster AKS existant avec Azure CNI pour inclure l’identité managée par pod.

az aks update -g $MY_RESOURCE_GROUP -n $MY_CLUSTER --enable-pod-identity

Utilisation du plug-in réseau Kubenet avec des identités managées par pod Microsoft Entra

Important

L’exécution d’une identité managée par pod Microsoft Entra dans un cluster avec Kubenet n’est pas une configuration recommandée pour des raisons de sécurité. La configuration Kubenet par défaut ne permet pas d’empêcher l’usurpation ARP, qui peut être utilisée par un pod pour agir comme un autre pod et accéder à une identité qu’il n’est pas censé avoir. Suivez les étapes d’atténuation et configurez les stratégies avant d’activer une identité managée par pod Microsoft Entra dans un cluster avec Kubenet.

Correction

Pour atténuer la vulnérabilité au niveau du cluster, vous pouvez utiliser la stratégie intégrée Azure « Les conteneurs de cluster Kubernetes doivent utiliser uniquement des fonctionnalités autorisées » pour limiter les attaques de type CAP_NET_RAW.

Ajouter NET_RAW à « Fonctionnalités Drop requises »

image

Si vous n’utilisez pas Azure Policy, vous pouvez combiner le contrôleur d’admission OpenPolicyAgent et le webhook de validation de Gatekeeper. Si Gatekeeper est déjà installé dans votre cluster, ajoutez le modèle ConstraintTemplate de type K8sPSPCapabilities :

kubectl apply -f https://raw.githubusercontent.com/open-policy-agent/gatekeeper-library/master/library/pod-security-policy/capabilities/template.yaml

Ajoutez un modèle pour limiter la génération de Pods à l’aide de la fonctionnalité NET_RAW :

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sPSPCapabilities
metadata:
  name: prevent-net-raw
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Pod"]
    excludedNamespaces:
      - "kube-system"
  parameters:
    requiredDropCapabilities: ["NET_RAW"]

Créer un cluster AKS avec le plug-in réseau Kubenet

Créez un cluster AKS avec un plug-in réseau Kubenet et une identité managée par pod activée.

az aks create -g $MY_RESOURCE_GROUP -n $MY_CLUSTER --enable-pod-identity --enable-pod-identity-with-kubenet

Mettre à jour un cluster AKS existant avec le plug-in réseau Kubenet

Mettez à jour un cluster AKS existant avec le plug-in réseau Kubenet pour inclure l’identité managée par pod.

az aks update -g $MY_RESOURCE_GROUP -n $MY_CLUSTER --enable-pod-identity --enable-pod-identity-with-kubenet

Créer une identité

Important

Pour créer l’identité, vous devez disposer des autorisations appropriées (par exemple, Propriétaire) sur votre abonnement.

Créez une identité qui sera utilisée par le pod de démonstration avec az identity create et définissez les variables IDENTITY_CLIENT_ID et IDENTITY_RESOURCE_ID.

az group create --name myIdentityResourceGroup --location eastus
export IDENTITY_RESOURCE_GROUP="myIdentityResourceGroup"
export IDENTITY_NAME="application-identity"
az identity create --resource-group ${IDENTITY_RESOURCE_GROUP} --name ${IDENTITY_NAME}
export IDENTITY_CLIENT_ID="$(az identity show -g ${IDENTITY_RESOURCE_GROUP} -n ${IDENTITY_NAME} --query clientId -otsv)"
export IDENTITY_RESOURCE_ID="$(az identity show -g ${IDENTITY_RESOURCE_GROUP} -n ${IDENTITY_NAME} --query id -otsv)"

Attribuer des autorisations pour l’identité managée

L’identité managée qui sera affectée au pod doit se voir accorder des autorisations qui s’alignent sur les mesures qu’elle va prendre.

Pour exécuter la démonstration, l’identité managée IDENTITY_CLIENT_ID doit avoir des autorisations de contributeur de machine virtuelle dans le groupe de ressources qui contient le groupe de machines virtuelles identiques de votre cluster AKS.

# Obtain the name of the resource group containing the Virtual Machine Scale set of your AKS cluster, commonly called the node resource group
NODE_GROUP=$(az aks show -g myResourceGroup -n myAKSCluster --query nodeResourceGroup -o tsv)

# Obtain the id of the node resource group 
NODES_RESOURCE_ID=$(az group show -n $NODE_GROUP -o tsv --query "id")

# Create a role assignment granting your managed identity permissions on the node resource group
az role assignment create --role "Virtual Machine Contributor" --assignee "$IDENTITY_CLIENT_ID" --scope $NODES_RESOURCE_ID

Créer une identité de pod

Créez une identité managée par pod pour le cluster à l’aide de az aks pod-identity add.

export POD_IDENTITY_NAME="my-pod-identity"
export POD_IDENTITY_NAMESPACE="my-app"
az aks pod-identity add --resource-group myResourceGroup --cluster-name myAKSCluster --namespace ${POD_IDENTITY_NAMESPACE}  --name ${POD_IDENTITY_NAME} --identity-resource-id ${IDENTITY_RESOURCE_ID}

Notes

La variable « POD_IDENTITY_NAME » doit être un nom de sous-domaine DNS valide, tel que défini dans RFC 1123.

Notes

Lorsque vous affectez l’identité managée par pod à l’aide de pod-identity add, l’interface Azure CLI tente d’accorder le rôle d’opérateur d’identités managées sur l’identité managée par pod (IDENTITY_RESOURCE_ID) à l’identité du cluster.

Azure créera une ressource AzureIdentity dans votre cluster représentant l’identité dans Azure, et une ressource AzureIdentityBinding qui connecte AzureIdentity à un sélecteur. Vous pouvez afficher ces ressources avec

kubectl get azureidentity -n $POD_IDENTITY_NAMESPACE
kubectl get azureidentitybinding -n $POD_IDENTITY_NAMESPACE

Exécuter un exemple d’application

Pour qu’un pod utilise l’identité managée par pod Microsoft Entra, le pod a besoin d’une étiquette aadpodidbinding avec une valeur qui correspond à un sélecteur issu d’une AzureIdentityBinding. Par défaut, le sélecteur correspond au nom de l’identité managée par pod, mais il peut également être défini à l’aide de l’option --binding-selector lors de l’appel de az aks pod-identity add.

Pour exécuter un exemple d’application à l’aide d’une identité managée par pod Microsoft Entra, créez un fichier demo.yaml avec le contenu suivant. Remplacez POD_IDENTITY_NAME, IDENTITY_CLIENT_ID et IDENTITY_RESOURCE_GROUP par les valeurs issues des étapes précédentes. Remplacez SUBSCRIPTION_ID par l’ID de votre abonnement.

Notes

Au cours des étapes précédentes, vous avez créé les variables POD_IDENTITY_NAME, IDENTITY_CLIENT_ID et IDENTITY_RESOURCE_GROUP. Vous pouvez utiliser une commande telle que echo pour afficher la valeur que vous définissez pour les variables, par exemple echo $POD_IDENTITY_NAME.

apiVersion: v1
kind: Pod
metadata:
  name: demo
  labels:
    aadpodidbinding: $POD_IDENTITY_NAME
spec:
  containers:
  - name: demo
    image: mcr.microsoft.com/oss/azure/aad-pod-identity/demo:v1.6.3
    args:
      - --subscriptionid=$SUBSCRIPTION_ID
      - --clientid=$IDENTITY_CLIENT_ID
      - --resourcegroup=$IDENTITY_RESOURCE_GROUP
    env:
      - name: MY_POD_NAME
        valueFrom:
          fieldRef:
            fieldPath: metadata.name
      - name: MY_POD_NAMESPACE
        valueFrom:
          fieldRef:
            fieldPath: metadata.namespace
      - name: MY_POD_IP
        valueFrom:
          fieldRef:
            fieldPath: status.podIP
  nodeSelector:
    kubernetes.io/os: linux

Notez que la définition du pod a une étiquette aadpodidbinding avec une valeur qui correspond au nom de l’identité managée par pod que vous avez exécutée az aks pod-identity add à l’étape précédente.

Déployez demo.yaml dans le même espace de noms que votre identité managée par pod à l’aide de kubectl apply :

kubectl apply -f demo.yaml --namespace $POD_IDENTITY_NAMESPACE

Vérifiez que l’exemple d’application s’exécute correctement avec kubectl logs.

kubectl logs demo --follow --namespace $POD_IDENTITY_NAMESPACE

Vérifiez que les journaux indiquent qu’un jeton a bien été acquis et que l’opération GET a abouti.

...
successfully doARMOperations vm count 0
successfully acquired a token using the MSI, msiEndpoint(http://169.254.169.254/metadata/identity/oauth2/token)
successfully acquired a token, userAssignedID MSI, msiEndpoint(http://169.254.169.254/metadata/identity/oauth2/token) clientID(xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx)
successfully made GET on instance metadata
...

Exécuter une application avec plusieurs identités

Pour permettre à une application d’utiliser plusieurs identités, définissez --binding-selector sur le même sélecteur lors de la création d’identités de pod.

az aks pod-identity add --resource-group myResourceGroup --cluster-name myAKSCluster --namespace ${POD_IDENTITY_NAMESPACE}  --name ${POD_IDENTITY_NAME_1} --identity-resource-id ${IDENTITY_RESOURCE_ID_1} --binding-selector myMultiIdentitySelector
az aks pod-identity add --resource-group myResourceGroup --cluster-name myAKSCluster --namespace ${POD_IDENTITY_NAMESPACE}  --name ${POD_IDENTITY_NAME_2} --identity-resource-id ${IDENTITY_RESOURCE_ID_2} --binding-selector myMultiIdentitySelector

Ensuite, définissez le champ aadpodidbinding du fichier YAML de votre pod sur le sélecteur de liaison que vous avez spécifié.

apiVersion: v1
kind: Pod
metadata:
  name: demo
  labels:
    aadpodidbinding: myMultiIdentitySelector
...

Désactiver l’identité gérée par pod sur un cluster existant

Pour désactiver l’identité gérée par pod sur un cluster existant, supprimez les identités gérées par pod du cluster. Désactivez ensuite la fonctionnalité sur le cluster.

az aks pod-identity delete --name ${POD_IDENTITY_NAME} --namespace ${POD_IDENTITY_NAMESPACE} --resource-group myResourceGroup --cluster-name myAKSCluster
az aks update --resource-group myResourceGroup --name myAKSCluster --disable-pod-identity

Nettoyage

Pour supprimer l’identité managée par pod Microsoft Entra de votre cluster, supprimez l’exemple d’application et l’identité managée par pod du cluster. Supprimez ensuite l’identité et l’attribution de rôle de l’identité de cluster.

kubectl delete pod demo --namespace $POD_IDENTITY_NAMESPACE
az aks pod-identity delete --name ${POD_IDENTITY_NAME} --namespace ${POD_IDENTITY_NAMESPACE} --resource-group myResourceGroup --cluster-name myAKSCluster
az identity delete -g ${IDENTITY_RESOURCE_GROUP} -n ${IDENTITY_NAME}
az role assignment delete --role "Managed Identity Operator" --assignee "$IDENTITY_CLIENT_ID" --scope "$IDENTITY_RESOURCE_ID"

Étapes suivantes

Pour plus d’informations sur les identités managées, consultez Identités managées pour les ressources Azure.