Identités managées pour les ressources Azure – forum aux questions

  • Article

Les identités managées pour les ressources Azure sont une fonctionnalité de Microsoft Entra ID. Les services Azure prenant en charge les identités managées pour ressources Azure sont soumis à leur propre chronologie. Assurez-vous de passer en revue l’état Disponibilité des identités gérées pour votre ressource et les problèmes connus avant de commencer.

Notes

Identités managées pour les ressources Azure est le nouveau nom du service anciennement nommé Managed Service Identity (MSI).

Administration

Comment trouver les ressources qui ont une identité managée ?

Vous pouvez obtenir la liste des ressources qui ont une identité managée affectée par le système en exécutant la commande Azure CLI suivante :

az resource list --query "[?identity.type=='SystemAssigned'].{Name:name,  principalId:identity.principalId}" --output table

Quelles sont les autorisations RBAC Azure nécessaires pour une identité managée sur une ressource ?

  • Identité managée affectée par le système : vous devez disposer d’autorisations d’écriture sur la ressource. Par exemple, pour les machines virtuelles, vous avez besoin de Microsoft.Compute/virtualMachines/write. Cette action est incluse dans les rôles intégrés spécifiques de la ressource, tel que le Contributeur de machines virtuelles.
  • Attribution d’identités managées affectées par l’utilisateur aux ressources : vous devez disposer d’autorisations en écriture sur la ressource. Par exemple, pour les machines virtuelles, vous avez besoin de Microsoft.Compute/virtualMachines/write. Vous aurez également besoin de l’action Microsoft.ManagedIdentity/userAssignedIdentities/*/assign/action sur l’identité affectée par l’utilisateur. Cette action est incluse dans le rôle intégré Opérateur de l’identité managée.
  • Gestion des identités affectées par l’utilisateur : pour créer ou supprimer des identités managées affectées par l’utilisateur, vous avez besoin de l’attribution de rôle Contributeur d’identité managée.
  • Gestion des attributions de rôles pour les identités managées : vous avez besoin de l’attribution de rôle Propriétaire ou Administrateur de l’accès utilisateur sur la ressource à laquelle vous accordez l’accès. Vous aurez besoin de l’attribution de rôle Lecteur à la ressource avec une identité affectée par le système ou à l’identité affectée par l’utilisateur qui reçoit l’attribution de rôle. Si vous n’avez pas d’accès en lecture, vous pouvez effectuer une recherche par « utilisateur, groupe ou principal de service » pour trouver le principal du service de sauvegarde de l’identité au lieu de rechercher par identité managée lors de l’ajout de l’attribution de rôle. En savoir plus sur l’affectation de rôles Azure.

Comment empêcher la création d’identités managées affectées par l’utilisateur ?

Vous pouvez empêcher vos utilisateurs de créer des identités managées affectées par l’utilisateur avec Azure Policy

  1. Connectez-vous au Portail Azure, puis accédez à Stratégie.

  2. Choisissez Définitions

  3. Sélectionnez + Définition de stratégie et entrez les informations nécessaires.

  4. Dans la section Règle de stratégie, collez :

    {
  "mode": "All",
  "policyRule": {
    "if": {
      "field": "type",
      "equals": "Microsoft.ManagedIdentity/userAssignedIdentities"
    },
    "then": {
      "effect": "deny"
    }
  },
  "parameters": {}
}

Une fois la stratégie créée, affectez-la au groupe de ressources que vous souhaitez utiliser.

  1. Accédez aux groupes de ressources.
  2. Recherchez le groupe de ressources que vous utilisez pour le test.
  3. Choisissez Stratégies dans le menu de gauche.
  4. Sélectionnez Attribuer la stratégie
  5. Dans la section De base, indiquez :
    1. Étendue : groupe de ressources utilisé pour le test
    2. Définition de stratégie : stratégie que nous avons créée précédemment.
  6. Conservez les valeurs par défaut pour tous les autres paramètres, puis choisissez Vérifier + créer

À ce stade, toute tentative de création d’une identité managée affectée par l’utilisateur dans le groupe de ressources échoue.

Capture d’écran montrant une violation de stratégie.

Concepts

Les identités managées ont-elles un objet de sauvegarde d’application ?

Non, les identités managées et les inscriptions d’applications Microsoft Entra ne sont pas les mêmes dans le répertoire.

Les inscriptions d’applications ont deux composants : un objet application et un objet principal de service. Les identités managées des ressources Azure ont un seul de ces composants : un objet principal de service.

Les identités managées n’ont pas d’objet application dans l’annuaire, qui est l’objet couramment utilisé pour accorder des autorisations d’application pour MS Graph. Au lieu de cela, les autorisations MS Graph pour les identités managées doivent être accordées directement au principal de service.

Quelles sont les informations d’identification associées à une identité managée ? Quelle est la durée de validité et quelle est la fréquence de rotation ?

Notes

Le mode d’authentification des identités managées est un détail d’implémentation interne susceptible d’être modifié sans préavis.

Les identités managées utilisent l’authentification par certificat. Les informations d’identification de chaque identité managée ont une date d’expiration de 90 jours et elles sont renouvelées après 45 jours.

Quelle identité IMDS a-t-il par défaut si je ne spécifie pas l’identité dans la demande ?

  • Si l’identité managée affectée par le système est activée et qu’aucune identité n’est spécifiée dans la requête, Azure Instance Metadata Service (IMDS) utilise par défaut l’identité managée affectée par le système.
  • Si l’identité managée affectée par le système n’est pas activée et qu’il n’existe qu’une seule identité managée affectée par l’utilisateur, IMDS utilise par défaut l’identité managée affectée par ce seul utilisateur.

    Si une autre identité managée affectée par l’utilisateur est affectée à la ressource pour une raison quelconque, vos demandes adressées à IMDS commencent à échouer avec l’erreur Multiple user assigned identities exist, please specify the clientId / resourceId of the identity in the token request. Nous vous recommandons vivement de spécifier explicitement une identité dans votre requête, même si une seule identité gérée attribuée à un utilisateur existe actuellement pour la ressource.

  • Si l’identité managée affectée par le système n’est pas activée et qu’il existe plusieurs identités managées affectées par l’utilisateur, la spécification d’une identité managée dans la requête est obligatoire.

Limites

La même identité managée peut-elle être utilisée dans plusieurs régions ?

En deux mots, oui, vous pouvez utiliser des identités managées affectées par l’utilisateur dans plusieurs régions Azure. La réponse plus longue est que, si des identités managées affectées par l’utilisateur sont créées en tant que ressources régionales, le principal de service (Service Principal/SP) associé créé dans Microsoft Entra ID est disponible globalement. Le principal de service peut être utilisé à partir de n’importe quelle région Azure et sa disponibilité dépend de celle de Microsoft Entra ID. Par exemple, si vous avez créé une identité managée affectée par l'utilisateur dans la région Sud-Centre et que cette région devient indisponible, ce problème n’affecte que les activités de plan de contrôle sur l’identité managée proprement dite. Les activités effectuées par des ressources déjà configurées pour utiliser des identités managées ne seront pas affectées.

Les identités managées pour les ressources Azure fonctionnent-elles avec Azure Cloud Services (classique) ?

Les identités managées pour les ressources Azure ne prennent pas en charge Azure Services cloud (classique) pour l’instant. «

Quelle est la limite de sécurité des identités managées pour les ressources Azure ?

La limite de sécurité de l’identité est la ressource à laquelle elle est jointe. Par exemple, la limite de sécurité activée pour une machine virtuelle avec des identités managées pour des ressources Azure est la machine virtuelle. Tout code s’exécutant sur cette machine virtuelle est en mesure d’appeler les identités managées pour des jetons de point de terminaison et de requête. L’expérience est similaire lorsque vous travaillez avec d’autres ressources qui prennent en charge les identités managées.

Les identités managées sont-elles recréées automatiquement si je déplace un abonnement vers un autre répertoire ?

Non, si vous déplacez un abonnement vers un autre annuaire, vous devez les recréer manuellement et accorder à nouveau les attributions de rôle Azure.

  • Pour les identités managées affectées par le système : désactivez et réactivez-les.
  • Pour les identités managées affectées par l’utilisateur : supprimez, recréez et joignez-les à nouveau aux ressources nécessaires (par exemple, des machines virtuelles)

Puis-je utiliser une identité managée pour accéder à une ressource dans un autre répertoire/abonné ?

Non, les identités managées ne prennent actuellement pas en charge les scénarios inter-annuaires.

Existe-t-il des limites de taux qui s’appliquent aux identités managées ?

Les limites des identités managées dépendent des limites de service Azure, des limites d’Azure Instance Metadata Service (IMDS) et des limites de service de Microsoft Entra.

  • Les limites de service Azure définissent le nombre d’opérations de création qui peuvent être effectuées au niveau du locataire et de l’abonnement. Les identités managées attribuées par l’utilisateur ont également des limitations sur la façon dont elles peuvent être nommées.
  • IMDS En général, les demandes adressées à IMDS sont limitées à cinq par seconde. Celles qui dépassent ce seuil sont rejetées avec une réponse 429. Les demandes adressées à la catégorie Identité managée sont limitées à 20 par seconde et à 5 simultanément. Pour plus d’informations, consultez l’article sur Azure Instance Metadata Service (Windows).
  • Service Microsoft Entra Chaque identité managée compte dans la limite de quota d’objets dans un locataire Microsoft Entra, comme décrit dans Limites Microsoft Entra et restrictions de service.

Est-il possible de déplacer une identité managée affectée par l’utilisateur à un autre groupe de ressources/abonnement ?

Le déplacement d’une identité managée affectée par l’utilisateur à un autre groupe de ressources.

Les jetons d’identité managée sont-ils mis en cache ?

Les jetons d’identité managée sont mis en cache par l’infrastructure Azure sous-jacente à des fins de performances et de résilience : les services back-end pour les identités managées conservent un cache par URI de ressource pendant 24 heures environ. Cela peut prendre plusieurs heures pour que les modifications d’autorisations d’une identité managée pour prendre effet, par exemple. Aujourd’hui, il n’est pas possible de forcer l’actualisation du jeton d’une identité managée avant son expiration. Pour plus d’informations, consultez Limitation de l’utilisation des identités managées pour l’autorisation.

Les identités managées sont-elles supprimées de manière réversible ?

Oui, les identités managées sont supprimées de manière réversible pendant 30 ours. Vous pouvez afficher le principal du service d’identité managée supprimé de manière réversible, mais vous ne pouvez pas le restaurer ou le supprimer définitivement.

Qu’arrive-t-il aux jetons après la suppression d’une identité managée ?

Lorsqu’une identité managée est supprimée, une ressource Azure qui a été précédemment associée à cette identité ne peut plus demander de nouveaux jetons pour cette identité. Les jetons émis avant la suppression de l’identité seront toujours valides jusqu’à leur expiration d’origine. Certains systèmes d’autorisation des points de terminaison cibles peuvent effectuer d’autres vérifications dans le répertoire de l’identité, auquel cas la demande échoue, car l’objet est introuvable. Toutefois, certains systèmes, comme Azure RBAC, continueront d’accepter les demandes de ce jeton jusqu’à ce qu’il expire.

Étapes suivantes