Vous exploitez un groupe de machines virtuelles identiques (VM scale set) et plusieurs Function Apps qui doivent accéder à Azure Key Vault et Azure Storage avec une identité commune et réutilisable entre les ressources et les régions. L'identité doit survivre à toute ressource individuelle. Les charges de travail doivent également obtenir des jetons OAuth pour appeler une API partenaire qui fait confiance à Entra ID, sans stocker de secrets. Que devez-vous faire ? Chaque bonne réponse présente une partie de la solution.

Une identité managée affectée par l'utilisateur (UAMI) est la solution appropriée car elle peut être partagée entre plusieurs ressources (VM scale set et Function Apps) et régions, et son cycle de vie est indépendant de celui des ressources individuelles. Attacher l'UAMI et lui attribuer les rôles nécessaires (Key Vault Secrets User, Storage Blob Data Contributor) lui permet d'accéder aux ressources spécifiées. Pour obtenir des jetons OAuth pour l'API partenaire, les charges de travail doivent demander des jetons à l'aide du point de terminaison d'identité managée (IMDS pour les VM, point de terminaison de jeton App Service pour les Function Apps), ce qui élimine le besoin de stocker des secrets. Les identités managées affectées par le système ne peuvent pas être partagées entre les ressources. Une inscription d'application avec un secret client nécessiterait la gestion et le stockage d'un secret, ce qui est contraire à l'exigence de ne pas stocker de secrets. L'API Azure AD Graph est obsolète et ne doit pas être utilisée pour de nouvelles implémentations.