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

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

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)

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 \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --enable-pod-identity \
    --network-plugin azure \
    --generate-ssh-keys

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

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 --resource-group $MY_RESOURCE_GROUP --name $MY_CLUSTER --enable-pod-identity

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

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 »

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 \
    --resource-group $MY_RESOURCE_GROUP \
    --name $MY_CLUSTER \
    --enable-pod-identity \
    --enable-pod-identity-with-kubenet \
    --generate-ssh-keys

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 --resource-group $MY_RESOURCE_GROUP --name $MY_CLUSTER --enable-pod-identity --enable-pod-identity-with-kubenet

Créer une identité

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 --resource-group ${IDENTITY_RESOURCE_GROUP} --name ${IDENTITY_NAME} --query clientId -o tsv)"
export IDENTITY_RESOURCE_ID="$(az identity show --resource-group ${IDENTITY_RESOURCE_GROUP} --name ${IDENTITY_NAME} --query id -o tsv)"

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 --resource-group myResourceGroup --name myAKSCluster --query nodeResourceGroup -o tsv)

# Obtain the id of the node resource group 
NODES_RESOURCE_ID=$(az group show --name $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}

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.

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 --resource-group ${IDENTITY_RESOURCE_GROUP} --name ${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.