Partager via


Utiliser Azure Policy pour affecter des identités managées (préversion)

Azure Policy aide à appliquer les normes organisationnelles et à évaluer la conformité à grande échelle. Avec son tableau de bord de conformité, Azure Policy offre une vue agrégée qui aide les administrateurs à évaluer l’état global de l’environnement. Vous avez la possibilité d’explorer dans le détail jusqu’au niveau par ressource et par stratégie. Il vous aide également à mettre vos ressources en conformité par le biais de la correction en bloc pour les ressources existantes et de la correction automatique pour les nouvelles ressources. Les cas d’usage courants pour Azure Policy comprennent l’implémentation de la gouvernance pour :

  • Cohérence des ressources
  • Conformité aux normes
  • Sécurité
  • Coût
  • Gestion

Les définitions de stratégie pour ces cas d’usage courants sont déjà disponibles dans votre environnement Azure pour vous aider à démarrer.

Les agents Azure Monitor nécessitent une identité managée sur les machines virtuelles Azure supervisées. Ce document décrit le comportement d’une stratégie Azure intégrée fournie par Microsoft qui permet de garantir qu’une identité managée, nécessaire pour ces scénarios, est affectée à des machines virtuelles à grande échelle.

Bien que l’utilisation d’une identité managée affectée par le système soit possible, lorsqu’elle est utilisée à grande échelle (par exemple, pour toutes les machines virtuelles d’un abonnement), cela entraîne un nombre important d’identités créées (et supprimées) dans Microsoft Entra ID. Pour éviter ce surplus d’identités, il est recommandé d’utiliser des identités managées affectées par l’utilisateur, qui peuvent être créées une seule fois et partagées sur plusieurs machines virtuelles.

Définition et détails d’une stratégie

Quand elle est exécutée, la stratégie effectue les actions suivantes :

  1. Créer, si elle n’existe pas, une nouvelle identité managée affectée par l’utilisateur intégrée dans l’abonnement et chaque région Azure basée sur les machines virtuelles qui sont dans l’étendue de la stratégie.
  2. Une fois qu’elle est créée, placez un verrou sur l’identité managée affectée par l’utilisateur afin qu’elle ne soit pas supprimée accidentellement.
  3. Attribuer l’identité managée affectée par l’utilisateur intégrée aux machines virtuelles de l’abonnement et de la région en fonction des machines virtuelles qui sont dans l’étendue de la stratégie.

Notes

Si la machine virtuelle a exactement 1 identité managée affectée par l’utilisateur déjà affectée, la stratégie ignore cette machine virtuelle pour affecter l’identité intégrée. C’est pour s’assurer que l’affectation de la stratégie ne cassent pas les applications qui prennent une dépendance sur le comportement par défaut du point de terminaison de jeton sur IMDS.

Il existe deux scénarios pour utiliser la stratégie :

  • Laisser la stratégie créer et utiliser une identité managée affectée par l’utilisateur « intégrée ».
  • Apporter votre propre identité managée affectée par l’utilisateur.

La stratégie prend les paramètres d’entrée suivants :

  • Apporter votre propre identité managée affectée par l’utilisateur ? - La stratégie doit-elle créer, si elle n’existe pas, une nouvelle identité managée affectée par l’utilisateur ?
    • Si la valeur est true, vous devez spécifier :
      • Nom de l'identité gérée.
      • Groupe de ressources contenant l’identité gérée.
    • Si la valeur est false, aucune entrée supplémentaire n’est nécessaire.
      • La stratégie crée l’identité managée affectée par l’utilisateur requise appelée « identité intégrée » dans un groupe de ressources appelé « built-in-identity-rg ».
  • Restreindre-Apportez-votre-propre-UAMI-à-l'abonnement ? - Lorsque le paramètre Bring-Your-Own-UAMI est défini sur vrai, la politique doit-elle utiliser une identité gérée attribuée par l'utilisateur centralisée ou utiliser une identité pour chaque abonnement ?
    • Si défini sur vrai, aucune entrée supplémentaire n'est nécessaire.
      • La politique utilisera une identité gérée attribuée par l’utilisateur par abonnement.
    • Si cette option est définie sur faux, la politique utilisera une seule identité gérée attribuée à un utilisateur centralisé qui sera appliquée à tous les abonnements couverts par l'attribution de politique. Vous devez spécifier :
      • ID de ressource d'identité gérée attribuée à l'utilisateur

Utilisation de la stratégie

Création de l’affectation de stratégie

La définition de stratégie peut être affectée à différentes étendues dans Azure : abonnement au groupe d’administration ou groupe de ressources spécifique. Étant donné que les stratégies doivent être appliquées tout le temps, l’opération d’affectation est effectuée en utilisant une identité managée associée à l’objet d’affectation de stratégie. L’objet d’affectation de stratégie prend en charge l’identité managée affectée par le système et affectée par l’utilisateur. Par exemple, Joe peut créer une identité managée affectée par l’utilisateur appelée PolicyAssignmentMI. La stratégie intégrée crée une identité managée affectée par l’utilisateur dans chaque abonnement et dans chaque région avec les ressources qui sont dans l’étendue de l’affectation de stratégie. Les identités managées affectées par l’utilisateur créées par la stratégie ont le format resourceId suivant :

/subscriptions/votre-id-abonnement/resourceGroups/built-in-identity-rg/providers/Microsoft.ManagedIdentity/userAssignedIdentities/built-in-identity-{région}

Par exemple :

/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/built-in-identity-rg/providers/Microsoft.ManagedIdentity/userAssignedIdentities/built-in-identity-eastus

Autorisation requise

Pour que l’identité managée PolicyAssignmentMI puisse affecter la stratégie intégrée dans l’étendue spécifiée, elle a besoin des autorisations suivantes, exprimées sous la forme d’une affectation de rôle RBAC Azure (contrôle d’accès en fonction du rôle Azure) :

Principal Rôle / Action Étendue Objectif
PolicyAssigmentMI Opérateur d’identités managées /subscription/subscription-id/resourceGroups/built-in-identity
OU
Apporter votre propre identité managée affectée par l’utilisateur
Obligatoire pour affecter l’identité intégrée aux machines virtuelles.
PolicyAssigmentMI Contributeur /subscription/subscription-id> Obligatoire pour créer le groupe de ressources qui détient l’identité managée intégrée dans l’abonnement.
PolicyAssigmentMI Contributeur d’identités gérées /subscription/subscription-id/resourceGroups/built-in-identity Obligatoire pour créer une identité managée affectée par l’utilisateur.
PolicyAssigmentMI Administrateur de l'accès utilisateur /subscription/subscription-id/resourceGroups/built-in-identity
OU
Apporter votre propre identité managée affectée par l’utilisateur
Obligatoire pour définir un verrou sur l’identité managée affectée par l’utilisateur créée par la stratégie.

Comme l’objet d’affectation de stratégie doit disposer de cette autorisation à l’avance, PolicyAssignmentMI ne peut pas être une identité managée affectée par le système pour ce scénario. L’utilisateur effectuant la tâche d’affectation de stratégie doit pré-autoriser PolicyAssignmentMI à l’avance avec les attributions de rôles ci-dessus.

Comme vous pouvez le voir, le rôle de privilège minimum résultant requis est « contributeur » dans l’étendue de l’abonnement.

Problèmes connus

La condition de concurrence possible avec un autre déploiement qui modifie les identités affectées à une machine virtuelle peut entraîner des résultats inattendus.

S’il existe deux déploiements parallèles ou plus qui mettent à jour la même machine virtuelle et qu’ils modifient tous la configuration d’identité de la machine virtuelle, il est possible, sous des conditions de concurrence spécifiques, que toutes les identités attendues NE soient PAS affectées aux machines. Par exemple, si la stratégie de ce document met à jour les identités managées d’une machine virtuelle et qu’en même temps un autre processus apporte également des modifications à la section des identités managées, il n’est pas garanti que toutes les identités attendues soient correctement affectées à la machine virtuelle.

Étapes suivantes