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

Ce démarrage rapide montre comment configurer une application Durable Functions pour utiliser des connexions basées sur l’identité soit pour le backend de Durable Task Scheduler, soit pour le fournisseur stockage Azure. La plateforme Azure gère une identité gérée depuis Microsoft Entra ID – vous n'avez pas besoin de provisionner ou de faire tourner des secrets.

Ce chemin suppose que votre application est déjà configurée pour utiliser le backend du Durable Task Scheduler. Si votre application utilise toujours le fournisseur stockage Azure, choisissez le chemin stockage Azure dans cet article.

Dans cet article :

Note

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

Si vous n’avez pas de compte Azure, créez un compte gratuit avant de commencer.

Prerequisites

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

  • Projet de Durable Functions existant créé dans le portail Azure ou un projet de Durable Functions local déployé sur Azure.
  • Connaissance de 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 :

Configuration du développement local

Vous avez deux options pour le développement local. Utilisez l’émulateur local Durable Task Scheduler pour des tests rapides sans identifiants Azure. Si vous devez tester des connexions basées sur l’identité avec une ressource en direct du planificateur, utilisez plutôt vos identifiants de développeur.

Option 1 : Utiliser l’émulateur local Durable Task Scheduler

Lorsque vous développez localement, utilisez l’émulateur Durable Task Scheduler afin de pouvoir tester votre application sans identifiants Azure. Configurez les paramètres de votre application pour qu’ils pointent vers l’émulateur et utilisez le hub des tâches par défaut.

{
  "IsEncrypted": false,
  "Values": {
    "FUNCTIONS_WORKER_RUNTIME": "dotnet-isolated",
    "AzureWebJobsStorage": "UseDevelopmentStorage=true",
    "DTS_CONNECTION_STRING": "Endpoint=http://localhost:8080;TaskHub=default;Authentication=None",
    "TASKHUB_NAME": "default"
  }
}

Option 2 : Connexions basées sur l’identité pour le développement local

Strictement parlant, une identité gérée n’est disponible que pour les applications lors de l’exécution sous Azure. Cependant, vous pouvez toujours configurer une application en fonctionnement local pour utiliser des connexions basées sur l’identité en utilisant vos identifiants développeur pour vous authentifier avec votre ressource de planificateur. Ensuite, une fois déployée sur Azure, l’application utilise la configuration d’identité managée à la place.

Lorsque vous utilisez des identifiants développeur, la connexion tente d’obtenir un jeton depuis les emplacements suivants, dans cet ordre :

  1. Un cache local partagé entre les applications Microsoft
  2. Contexte utilisateur actuel dans Visual Studio
  3. Contexte utilisateur actuel dans Visual Studio Code
  4. Contexte utilisateur actuel dans le Azure CLI

Si aucune de ces options ne réussit, vous obtenez une erreur indiquant que l’application ne peut pas récupérer un jeton d’authentification. Vérifiez que vous êtes connecté à l’un des outils listés avec un compte ayant accès à votre ressource de planificateur.

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

  1. Dans vos paramètres locaux, définissez le point de terminaison du planificateur et utilisez Authentication=DefaultAzure pour que l’application utilise vos identifiants de développeur.

    {
      "IsEncrypted": false,
      "Values": {
        "FUNCTIONS_WORKER_RUNTIME": "dotnet-isolated",
        "AzureWebJobsStorage": "UseDevelopmentStorage=true",
        "DTS_CONNECTION_STRING": "Endpoint=https://<your-scheduler-name>.<region>.durabletask.io;TaskHub=<your-task-hub>;Authentication=DefaultAzure",
        "TASKHUB_NAME": "<your-task-hub>"
      }
    }
    
  2. Attribuez à votre identité de développeur le rôle Durable Task Data Contributor sur la ressource Scheduler ou sur la portée spécifique du hub de tâches.

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

Activer une ressource d’identité managée

Activez une identité gérée pour votre application de fonction. 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

Naviguez vers votre ressource de planificateur dans le portail Azure et attribuez le Durable Task Data Contributor rôle à votre identité gérée. Pour un accès à privilèges minimum, attribuez le rôle à l’échelle du hub des tâches plutôt qu’à l’ensemble du planificateur. Si vous utilisez une identité attribuée par l’utilisateur, sélectionnez Identité gérée puis + Select les membres.

Ajouter la 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 Settings, sélectionnez Variables de l’environnement.

  2. Ajoutez ou mettez à jour le DTS_CONNECTION_STRING paramètre pour que l’application se connecte à votre planificateur en utilisant l’identité gérée de l’application.

    Endpoint=https://<your-scheduler-name>.<region>.durabletask.io;TaskHub=<your-task-hub>;Authentication=ManagedIdentity
    

    Si vous utilisez une identité managée attribuée par l’utilisateur, incluez l’ID client dans la chaîne de connexion :

    Endpoint=https://<your-scheduler-name>.<region>.durabletask.io;TaskHub=<your-task-hub>;Authentication=ManagedIdentity;ClientID=<your-user-assigned-identity-client-id>
    
  3. Ajoutez ou mettez à jour le TASKHUB_NAME paramètre avec le même nom du centre des tâches.

  4. Si votre hôte de fonction a besoin d’stockage Azure pour les opérations au niveau hôte, configurez AzureWebJobsStorage séparément. Le back-end du planificateur utilise la chaîne de connexion DTS plutôt que AzureWebJobsStorage pour l’état Durable.

Vérifier votre configuration

Pour confirmer que votre configuration d’identité managée fonctionne :

  1. Dans le portail Azure, allez dans votre application de fonctions et déclenchez votre orchestration Durable Functions.
  2. Vérifiez que l’orchestration s’achève correctement en interrogeant le point de terminaison d’état ou en vérifiant l’onglet Surveillance.
  3. Si vous voyez des erreurs d’authentification, vérifiez que :
    • L’identité managée dispose du rôle Durable Task Data Contributor sur la ressource du planificateur ou dans la portée du hub de tâches.
    • Les DTS_CONNECTION_STRING réglages et TASKHUB_NAME sont corrects.
    • L’application utilise l’identité attendue lors de l’exécution sous Azure.

Configuration du développement local

Vous avez deux options pour le développement local. Utilisez Azurite pour effectuer des tests locaux rapides sans Azure informations d’identification. Si vous devez tester des connexions basées sur des identités par rapport à un compte de stockage Azure réel, utilisez plutôt vos informations d’identification de développeur.

Option 1 : Utiliser l’émulateur de stockage Azure

Lorsque vous développez localement, il est recommandé 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.

Option 2 : Connexions basées sur l’identité pour le développement local

Strictement, une identité managée est uniquement disponible 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 pour vous authentifier auprès de Azure ressources. Ensuite, lorsqu’elle est déployée sur Azure, l’application utilise plutôt 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 cet ordre :

  1. Un cache local partagé entre les applications Microsoft
  2. Contexte utilisateur actuel dans Visual Studio
  3. Contexte utilisateur actuel dans Visual Studio Code
  4. Contexte utilisateur actuel dans le Azure CLI

Si aucune de ces options ne réussit, vous obtenez une erreur indiquant que l’application ne peut pas récupérer un jeton d’authentification. Vérifiez que vous êtes connecté à l'un des outils répertoriés avec un compte qui a accès à votre compte stockage Azure.

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 à votre ressource de compte stockage Azure dans le portail Azure.

  3. Sélectionnez l’onglet Access Control (IAM), puis sélectionnez Add role assignment.

  4. Attribuez chacun des rôles suivants à vous-même. Pour chaque rôle, sélectionnez « + Sélectionner des membres » et recherchez l’e-mail que vous utilisez pour vous connecter à Visual Studio, Visual Studio Code ou le Azure CLI.

    • Contributeur aux données de queue de stockage
    • Contributeur aux données du Blob de stockage
    • Contributeur aux données de la table de stockage

    Note

    Il s’agit des trois rôles requis pour votre identité managée lors du déploiement sur Azure. Consultez Attribuer des rôles d’accès à l’identité managée.

    Capture d'écran de l’attribution de rôles de Contributeur de données de stockage pour un utilisateur dans le portail Azure, page Contrôle d'accès.

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

Activer une 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 basé sur un rôle (RBAC) à votre identité managée :

  • Contributeur aux données de queue de stockage
  • Contributeur aux données du Blob de stockage
  • Contributeur aux données de la table de stockage

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

Screenshot de l’attribution de rôles d’accès au stockage à une identité managée dans le portail Azure.

Ajouter la 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 Settings, sélectionnez Variables de l’environnement.

  2. Dans la liste des paramètres, recherchez AzureWebJobsStorage, puis sélectionnez l’icône Supprimer. Capture d'écran de la variable d’environnement AzureWebJobsStorage dans les paramètres de l’application de fonctions du portail Azure.

  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 :

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

    • Cloud hors 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 endpoints) 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’onglet des points de terminaison du compte de stockage montrant les URI des services blob, file d'attente et table.

    Note

    Si vous utilisez Azure Government ou tout autre cloud distinct du Azure global, vous devez utiliser l'option qui fournit des URI de service spécifiques au lieu du nom du compte de stockage uniquement. Pour plus d’informations sur l’utilisation de stockage Azure avec Azure Government, consultez le Develop à l’aide de l’API de 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 la ressource d’identité managée affectée par l’utilisateur montrant la valeur de l’ID client.

    Note

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

Vérifier votre configuration

Pour confirmer que votre configuration d’identité managée fonctionne :

  1. Dans le portail Azure, accédez à votre application de fonction et déclenchez votre orchestration de Durable Functions (par exemple, à l’aide d’une fonction de déclencheur HTTP).
  2. Assurez-vous que l’orchestration s’est achevée correctement en interrogeant le point de terminaison d’état ou en consultant l’onglet Surveiller.
  3. Si vous voyez des erreurs d’authentification, vérifiez que :
    • Les trois rôles de contributeur de données de stockage sont attribués à l’identité appropriée.
    • Le paramètre AzureWebJobsStorage chaîne de connexion est supprimé.
    • Les AzureWebJobsStorage__accountName paramètres (ou URI de service) sont corrects.

Étapes suivantes