Liaisons d’identité pour Azure Kubernetes Service (AKS) (préversion)

La liaison d’identité est une fonctionnalité actuellement en préversion pour Azure Kubernetes Service (AKS) qui étend les capacités existantes de l’identité de charge de travail afin de résoudre les contraintes de montée en charge associées aux informations d’identification fédérées (FIC) sur les identités gérées attribuées par l’utilisateur (UAMI). Avec l’identité de charge de travail pour AKS, une UAMI unique ne peut pas être associée à plus de 20 FIC. Les déploiements sur des plateformes Kubernetes importantes peuvent s’étendre sur plus de 20 clusters (chacun ayant un émetteur unique) ou inclure de nombreuses <namespace, service-account> combinaisons nécessitant un mappage vers le même UAMI, ce qui peut épuiser le quota FIC.

Les liaisons d’identité résolvent cette limitation en autorisant plusieurs clusters AKS à partager le même UAMI à l’aide d’un seul FIC par UAMI. Cette approche augmente considérablement la scalabilité et simplifie les opérations pour les environnements AKS à grande échelle qui nécessitent l’authentification Microsoft Entra.

Qu’est-ce qu’une liaison d’identité ?

Une liaison d’identité est un mappage de ressources entre un cluster UAMI et un cluster AKS avec des charges de travail qui ont besoin de l’authentification Microsoft Entra avec cette identité.

Supposons que vous disposez d’un UAMI, MI-1, nécessaire pour les charges de travail exécutées dans des clusters AKS-cluster-1, AKS-cluster-2 et AKS-cluster-3. Vous pouvez créer trois liaisons d’identité pour mapper MI-1 pour chacun de ces clusters :

• Liaison d’identité IB-A pour le mappage MI-1 à AKS-cluster-1.
• Liaison d’identité IB-B pour le mappage MI-1 à AKS-cluster-2.
• Liaison d’identité IB-C pour le mappage MI-1 à AKS-cluster-3.

Même si le même UAMI est nécessaire sur plusieurs clusters, un seul certificat d'identité fédérée est créé par UAMI, ce qui résout la limitation de 20 FIC précédente. Lors de la création d’une liaison d’identité, AKS génère automatiquement (ou réutilise) le FIC unique correspondant à cette UAMI. Les diagrammes suivants illustrent les différences entre le modèle d’identité de charge de travail précédent et le nouveau modèle de liaisons d’identité :

Une fois que vous avez créé la liaison d’identité et que l’UAMI est autorisé pour le cluster, vous devez définir ClusterRole et ClusterRoleBinding des objets qui spécifient les espaces de noms et les comptes de service (de manière granulaire ou collective) autorisés à utiliser cette identité managée pour l’acquisition de jetons Microsoft Entra.

Utiliser des liaisons d’identité avec des bibliothèques clientes d'Azure Identity

Pour utiliser des liaisons d’identité avec vos charges de travail d’application, procédez comme suit :

1. Vérifiez que vous utilisez le package Azure Identity minimum requis.
2. Utilisez WorkloadIdentityCredential et adhérez à la fonctionnalité. Cette fonctionnalité n’est pas prise en charge dans ManagedIdentityCredential ou DefaultAzureCredential.

Le tableau suivant présente les versions minimales du package et explique comment activer les liaisons d’identité pour chaque langue prise en charge :

Questions Fréquemment Posées (FAQ)

L'uniformité de l'identité (l'uniformité de l'espace de noms et du compte de service) est-elle nécessaire entre les clusters utilisant le même UAMI ?

Non. Les liaisons d'identité ne nécessitent pas de similitude entre les espaces de noms et le compte de service. Il appartient à l’opérateur de cluster d’autoriser explicitement les espaces de noms et les comptes de service à l’intérieur de chaque cluster autorisés à utiliser l’identité managée via le contrôle d’accès en fonction du rôle (RBAC).

Puis-je créer plusieurs liaisons d’identité pour le même UAMI ?

Yes. L’URL de l’émetteur OIDC gérée par AKS pour cette UAMI est la même dans toutes les liaisons d’identités référençant la même identité managée.

Quelles sont les autorisations requises pour créer des liaisons d’identité ?

Autorisations Azure Resource Manager (ARM) requises :

• Microsoft.ContainerService/managedClusters/identityBindings/*
• Microsoft.ManagedIdentity/userAssignedIdentities/federatedIdentityCredentials/*

Autorisations Kubernetes requises :

• Possibilité de créer ClusterRole et ClusterRoleBinding d’objets (administrateur de cluster ou équivalent).

Que devient la FIC créée automatiquement après la suppression de tous les liens d'identité pour un UAMI ?

Il n’existe aucune GC automatique de la mémoire des FIC aujourd’hui quand la dernière liaison d’identité référençant une UAMI est supprimée. Les opérateurs doivent nettoyer manuellement les FIC uniquement après avoir vérifié que toutes les liaisons d’identités de l’UAMI ont été supprimées pour éviter de perturber les dépendances restantes.

Quelles conditions préalables pour la mise en réseau existent concernant les liaisons d’identité ?

Auparavant, l’identité de la charge de travail nécessitait une sortie vers login.microsoftonline.com pour que les charges de travail puissent échanger les jetons de compte de service contre des jetons d’accès Microsoft Entra. Avec les liaisons d’identités, les demandes d’échange de jetons sont acheminées via un proxy de liaison d’identité spécifique au cluster géré par AKS. Il n'est pas nécessaire d'avoir une sortie directe vers login.microsoftonline.com pour l'échange de jetons.

Quelles limitations existent pour les liaisons d’identité ?

Les liaisons d’identité ne sont pas encore prises en charge sur les clusters configurés avec l’intégration du réseau virtuel du serveur d’API.

Contenu connexe

• Configurer des liaisons d’identité pour Azure Kubernetes Service (AKS)