Les identités managées dans Azure

Les identités managées permettent de déléguer la gestion et l’authentification d’identité utilisable au sein d’Azure.

Il existe deux types d’identités managées : celles créées par le système lors de l’instanciation d’une ressource Azure et celles créées par un utilisateur, qui peuvent être affectées à un ensemble de ressources Azure.

Une identité managée personnalisée est une ressource Azure comme une autre. Les avantages par rapport à un service principal sont multiples :

• Il n’y pas besoin d’avoir de droits dans l’Active Directory pour les créer ;
• On pourra les associer directement à des ressources Azure et les utiliser sans passer par un secret ou un certificat. C’est Azure qui s’occupe pour nous des mécanismes d’authentification.

Quelle utilisation des identités managées ?

De manière générale, les identités managées permettent de gérer l’accès à toute ressource Azure gérant l’authentification dans Azure AD. En effet, cette dernière permet (quand c’est possible) de remplacer la gestion des clés diverses et variées des différents services.

Les identités permettent donc d’avoir une réelle authentification Azure AD sur le service, sans avoir à mettre en place une application Azure AD et de gérer ses identifiants (ID et Secret) nécessaires au flux client credential.

Pour résumer, le principal avantage est de permettre de sécuriser les accès au service avec une authentification forte sans avoir à gérer la moindre information confidentielle. En effet, les identités étant directement assignées aux services Azure, ils gèrent de manière autonome ces problématiques. Le service s’occupe de s’authentifier auprès de l’Azure AD et de récupérer le token. Celui-ci est ensuite soit utilisé par le service directement pour appeler un autre service Azure, soit récupéré dans le code par les développeurs, un endpoint REST étant mis à disposition dans les espaces applicatifs (VM, Apps services, function, etc.).

A noter : la librairie Microsoft.identity.web fournit les classes d’abstractions qui vont bien…

Comme précisé plus haut, il existe deux types d’identité managées pour deux types d’usages :

1. L’identité assignée par le système : elle correspond à l’identité du service. Elle sera différente d’un service à l’autre. Plus simple à gérer, elle est automatiquement créée et supprimée (si l’option est cochée) avec la ressource Azure.
2. L’identité assigné par les utilisateurs correspond à une ressource Azure autonome qu’on assigne ensuite aux services souhaités. L’intérêt est qu’elle permet une plus grande flexibilité et d’avoir une même identité partagée par plusieurs services. On peut donc organiser les accès aux services par type et « rôle » logique des composants de l’architecture applicative.

A noter : on peut assigner plusieurs identités de ce type pour un seul service, on choisit ensuite laquelle utiliser lors des appels.

Comment créer et utiliser les identités managées ?

Comme toute ressource Azure, nous conseillons de les déployer à l’aide d’outils de templating/InfraAsCode (ARM, Terraform…). Les ressource de type managed identity sont déployées avec le reste de l’infra applicative suivant votre stratégie DevOps. Par exemple, ci-dessous dans un template ARM créant l’ensemble des identités nécessaires à votre application :

Elles sont ensuite assignées aux ressources Azure de la même manière (template ARM), comme c’est le cas ci-dessous, comme identité disponible dans une Logic Apps :

Il reste donc aux développeurs et intégrateurs à les utiliser dans leurs implémentations, comme ci-dessous dans une action LogicApps pour appeler une API custom sécurisée :

Ou dans votre code pour accéder à SQL Server par exemple :

Puis :

Nous avons donc vu l’intérêt d’utiliser des identités managées pour accéder à vos ressources Azure sans avoir à gérer des secrets dans vos déploiements.

Pour clôturer ce Mois de l’Identité, nous vous invitons à consulter le dernier article de cette série, consacré à la gestion des rôles applicatifs dans Azure AD.