Partager via


Démarrage rapide : configurer Durable Functions avec une identité managée

Une identité managée à partir du service de gestion des accès Microsoft Entra ID permet à votre application d’accéder à d’autres ressources protégées par Microsoft Entra, telles qu’un compte Stockage Azure, sans gérer manuellement les secrets. L’identité est managée par la plateforme Azure. Vous n’avez donc pas besoin d’approvisionner ou de faire pivoter les secrets. La méthode recommandée pour authentifier l’accès aux ressources Azure consiste à utiliser une telle identité.

Dans ce guide de démarrage rapide, vous allez suivre les étapes de configuration d’une application Durable Functions à l’aide du fournisseur Stockage Azure par défaut pour utiliser des connexions basées sur des identités pour l’accès au compte de stockage.

Remarque

L’identité managée est prise en charge dans les versions 2.7.0 et ultérieures des extensions Durable Functions.

Si vous ne disposez pas d’un compte Azure, créez-en un gratuitement avant de commencer.

Prérequis

Pour effectuer ce démarrage rapide, les éléments suivants sont requis :

  • Un projet de fonctions durables existant créé dans le portail Azure ou un projet de Durable Functions local déployé sur Azure.
  • Familiarité dans l’exécution d’une application Durable Functions dans Azure.

Si vous n’avez pas de projet Durable Functions existant déployé dans Azure, nous vous recommandons de commencer par l’un des guides de démarrage rapide suivants :

Développement local

Utiliser l’émulateur de Stockage Azure

Lorsque vous développez localement, nous vous recommandons d’utiliser Azurite, qui est l’émulateur local de Stockage Azure. Configurez votre application sur l’émulateur en spécifiant "AzureWebJobsStorage": "UseDevelopmentStorage = true" dans le local.settings.json.

Connexions basées sur des identités pour le développement local

Un sens stricte du terme, une identité managée n’est disponible que pour les applications lors de l’exécution sur Azure. Toutefois, vous pouvez toujours configurer une application en cours d’exécution locale pour utiliser la connexion basée sur l’identité à l’aide de vos informations d’identification de développeur afin de vous authentifier auprès des ressources Azure. Ensuite, lorsqu’elle est déployée sur Azure, l’application utilise à la place votre configuration d’identité managée.

Lorsque vous utilisez les informations d’identification du développeur, la connexion tente d’obtenir un jeton à partir des emplacements suivants, dans l’ordre indiqué, pour accéder à vos ressources Azure :

  • Un cache local partagé entre les applications Microsoft
  • Le contexte utilisateur actuel dans Visual Studio
  • Le contexte utilisateur actuel dans Visual Studio Code
  • Le contexte utilisateur actuel dans Azure CLI

Si aucune de ces options ne réussit, une erreur indiquant que l’application ne peut pas récupérer le jeton d’authentification pour vos ressources Azure s’affiche.

Configurer le runtime pour utiliser l’identité du développeur local

  1. Spécifiez le nom de votre compte Stockage Azure dans local.settings.json, par exemple :

    {
       "IsEncrypted": false,
       "Values": {
          "AzureWebJobsStorage__accountName": "<<your Azure Storage account name>>",
          "FUNCTIONS_WORKER_RUNTIME": "dotnet-isolated"
       }
    }
    
  2. Accédez à la ressource de compte Stockage Azure sur le Portail Azure, accédez à l’onglet Contrôle d’accès (IAM), puis cliquez sur Ajouter une attribution de rôle. Recherchez les rôles suivants :

    • Contributeur aux données en file d’attente du stockage
    • Contributeur aux données Blob du stockage
    • Contributeur aux données de table du stockage

    Attribuez-vous les rôles en cliquant sur « + Sélectionner des membres » et en recherchant votre adresse e-mail dans la fenêtre contextuelle. (Cette adresse e-mail est celle que vous utilisez pour vous connecter à des applications Microsoft, à Azure CLI ou à des éditeurs dans la famille Visual Studio.)

    Capture d’écran montrant l’attribution d’accès à l’utilisateur.

Connexions basées sur des identités pour l’application déployée sur Azure

Activer la ressource d’identité managée

Pour commencer, activez une identité managée pour votre application. Votre application de fonction doit avoir une identité managée affectée par le système ou une identité managée affectée par l’utilisateur(-trice). Pour activer une identité managée pour votre application de fonction et pour en savoir plus sur les différences entre les deux types d’identités, voir la présentation de l’identité managée.

Attribuer des rôles d’accès à l’identité managée

Accédez à la ressource Stockage Azure de votre application sur le Portail Azure et attribuez trois rôles de contrôle d’accès en fonction du rôle (RBAC) à votre ressource d’identité managée :

  • Contributeur aux données en file d’attente du stockage
  • Contributeur aux données Blob du stockage
  • Contributeur aux données de table du stockage

Pour trouver votre ressource d’identité, sélectionnez Attribuer l’accès à l’Identité managée, puis + Sélectionner des membres

Capture d’écran montrant l’attribution d’accès à l’identité managée.

Ajouter une configuration d’identité managée à votre application

Avant de pouvoir utiliser l’identité managée de votre application, apportez des modifications aux paramètres de l’application :

  1. Dans le Portail Azure, dans le menu des ressources de votre application de fonction, sous Paramètres, sélectionnez Variables d’environnement.

  2. Dans la liste des paramètres, recherchez AzureWebJobsStorage, puis sélectionnez l’icône Supprimer. Capture d’écran du paramètre de stockage par défaut.

  3. Ajoutez un paramètre pour lier votre compte de stockage Azure à l’application.

    Utilisez l’une des méthodes suivantes en fonction du cloud dans lequel votre application s’exécute :

    • Cloud Azure : si votre application s’exécute dans Azure global, ajoutez le paramètre AzureWebJobsStorage__accountName qui identifie un nom de compte de stockage Azure. Exemple de valeur : mystorageaccount123

    • Cloud non-Azure : si votre application s’exécute dans un cloud en dehors d’Azure, vous devez ajouter les trois paramètres suivants pour fournir des URI de service spécifiques (ou points de terminaison) du compte de stockage au lieu d’un nom de compte.

      • Nom du paramètre : AzureWebJobsStorage__blobServiceUri

        Exemple de valeur : https://mystorageaccount123.blob.core.windows.net/

      • Nom du paramètre : AzureWebJobsStorage__queueServiceUri

        Exemple de valeur : https://mystorageaccount123.queue.core.windows.net/

      • Nom du paramètre : AzureWebJobsStorage__tableServiceUri

        Exemple de valeur : https://mystorageaccount123.table.core.windows.net/

    Vous pouvez obtenir les valeurs de ces variables d’URI dans les informations sur le compte de stockage depuis l’onglet Points de terminaison.

    Capture d’écran de l’exemple de point de terminaison.

    Remarque

    Si vous utilisez Azure Government ou tout autre cloud distinct d’Azure global, vous devez utiliser l’option qui fournit des URI de service spécifiques au lieu d’uniquement le nom du compte de stockage. Pour plus d’informations sur l’utilisation de Stockage Azure avec Azure Government, consultez Développer à l’aide de l’API Stockage dans Azure Government.

  4. Terminez votre configuration d’identité managée (n’oubliez pas de cliquer sur « Appliquer » après avoir apporté des modifications au paramètre) :

    • Si vous utilisez une identité affectée par le système, n’apportez aucune autre modification.

    • Si vous utilisez une identité affectée par l’utilisateur, ajoutez les paramètres suivants dans la configuration de votre application :

      • AzureWebJobsStorage__credential, entrez managedidentity

      • AzureWebJobsStorage__clientId, obtenez cette valeur GUID à partir de votre ressource d’identité managée

      Capture d’écran de l’ID client d’identité utilisateur.

    Remarque

    Durable Functions ne prend pas en charge managedIdentityResourceId lors de l’utilisation de l’identité affectée par l’utilisateur. Utilisez clientId à la place.