Configurez les connexions vers des services distants dans Azure Functions

Cet article est la référence principale sur la manière dont Azure Functions se connecte aux services à distance. Il fournit des directives spécifiques basées sur le type de connexion et la méthode d’authentification.

Important

Utilisez des identités gérées avec Microsoft Entra ID dès que possible. Cette méthode d’authentification élimine les secrets et offre la sécurité la plus élevée.

Catégories de connexion

Les connexions Azure Functions se répartissent dans ces catégories de base :

  • Hôte requis : Connexions dont l’hôte des fonctions doit fonctionner, telles que le stockage et la surveillance.
  • Liens : Connexions que l’hôte gère pour vos déclencheurs et liaisons.
  • SDK client : Connexions que vous créez et gérez dans votre propre code de fonction.

Conseil

Functions prend également en charge les connecteurs gérés (en aperçu), qui permettent de se connecter à des services comme Office 365, Teams et SharePoint avec une gestion intégrée d’OAuth et des webhooks via un espace de noms de connecteur. Pour plus d’informations, voir Utiliser les connecteurs dans Azure Functions.

L’hôte Fonctions exige que votre application dispose de ces connexions nommées spécifiques, qui prennent en charge à la fois l’exécution de fonctions et la journalisation :

Méthodes d’authentification

Important

Lorsque possible, utilisez des identités gérées pour vos connexions. Cette approche élimine complètement les secrets. Lorsque le service cible ne prend pas en charge l'authentification Microsoft Entra ID, utilisez Azure Key Vault pour gérer centralisément les secrets. N’utilisez les secrets partagés directement dans les paramètres d’application qu’en dernier recours.

Functions prend en compte ces méthodes d’authentification lors de la connexion à des services distants :

Méthode d’authentification Security Quand utiliser
Identités gérées Le plus élevé Le service Target prend en charge Microsoft Entra ID. Aucun secret à gérer.
Azure Key Vault Élevé Le service ne prend pas en charge les identités gérées, ou il faut une gestion centralisée des secrets avec rotation.
Secret partagé Faible Ancienne valeur par défaut Migrez vers les identités gérées ou Key Vault dès que possible.

Choisissez votre méthode d’authentification préférée en haut de l’article pour consulter des conseils de configuration détaillés.

Définir les connexions

À l’exécution, votre application de fonctions accède aux informations de connexion sous forme de variables d’environnement depuis ces emplacements :

Environnement Où les réglages sont stockés
Azure Paramètres de l’application (chiffrés au repos)
Développement local local.settings.json (chiffré en option)

Dans les deux environnements, les paramètres sont exposés à votre code sous forme de variables d’environnement. Les réglages spécifiques dont vous avez besoin dépendent à la fois du type de connexion et de la méthode d’authentification que vous choisissez.

Lorsque vous utilisez l'authentification Microsoft Entra pour vous connecter à un service Azure, les paramètres spécifiques de l'application dépendent du service connecté et de l'authenticité d'une identité assignée par le système ou par l'utilisateur pour authentifier la connexion.

Les identités que vous utilisez pour vos connexions doivent avoir des autorisations pour effectuer les actions prévues. Pour la plupart des services Azure, cette exigence signifie que vous devez attribuer un rôle dans Azure RBAC, en utilisant soit des rôles intégrés, soit des rôles personnalisés qui fournissent ces permissions. Pour en savoir plus, voir Accorder des permissions à une identité.

Gardez ces considérations à l’esprit lorsque vous utilisez des connexions identitaires :

  • Dans une application hébergée par Functions, les connexions basées sur l’identité utilisent une identité gérée. L’identité assignée par le système, qui est spécifique à votre application, est utilisée par défaut. Cependant, les identités attribuées par l’utilisateur, qui nécessitent également les *__credential propriétés et *__clientID , sont plus flexibles et recommandées.

  • Lorsque votre application fonctionne dans d’autres contextes, comme le développement local, votre identité de développeur est utilisée à la place. Pour plus d’informations, voir l’article sur le développement local .

  • Les connexions basées sur l’identité ne sont prises en charge que sur la version 4.x et ultérieure de l’exécution des fonctions. Si vous utilisez une application C# ancienne sur la version 1.x de l’exécution Functions, vous devez d’abord migrer vers la version 4.x.

Vous pouvez configurer votre application de fonctions pour utiliser une identité au lieu d’une chaîne de connexion lors de la connexion au compte de stockage par défaut (AzureWebJobsStorage) et à d’autres connexions requises par l’hôte.

Le support AzureWebJobsStorage de l’identité gérée varie selon le plan d’hébergement :

Plan d’hébergement MI pour le stockage hôte Configuration requise pour Azure Files Recommendation
Consommation flexible Prise en charge complète None (pas d’Azure Files) Recommandé pour le MI
Dédié (App Service) Prise en charge complète Aucun (pas de mise à l’échelle dynamique) MI complet, aucun contournement nécessaire
Consommation Blobs, files d’attente, tables Key Vault ou supprimer Azure Files Stocker WEBSITE_AZUREFILESCONNECTIONSTRING dans Key Vault
Elastic Premium Blobs, files d’attente, tables Key Vault ou supprimer Azure Files Stocker WEBSITE_AZUREFILESCONNECTIONSTRING dans Key Vault

Avant d’utiliser des identités gérées pour des connexions nécessitant l’hôte, considérez ces limitations :

  • Pour les forfaits Consommation et Premium, mettez en place l’une de ces solutions de contournement pour Azure Files :

    • Stockez uniquement la WEBSITE_AZUREFILESCONNECTIONSTRING chaîne de connexion dans Key Vault, qui est l’option la plus sécurisée suivante.
    • Créez une application Consommation ou un forfait Premium qui fonctionne sans Azure Files. Il y a des impacts sur les performances lorsqu’on joue sans Azure Files. Pour plus d’informations, consultez Créer une application sans Azure Files.

  • Ces déclencheurs dépendent de AzureWebJobsStorage pour fonctionner correctement :

    • Service de stockage Blob Azure
    • Hubs d'événements Azure
    • Durable Functions (par défaut)
    • Minuteur

    Si votre application utilise l’une de ces extensions, assurez-vous que sa version prend également en charge les identités gérées.

  • AzureWebJobsStorage maintient les artefacts de déploiement dans les builds côté serveur (à distance) dans un plan Linux Consumption. Dans ce scénario, vous devez déployer et exécuter votre application depuis un package de déploiement externe.

  • D’autres composants de votre application de fonctions peuvent réutiliser la AzureWebJobsStorage connexion, ce qui peut inclure des extensions de liaison de stockage ou des clients de stockage créés via le Kit de développement logiciel (SDK) Azure. Lorsque vous utilisez des identités gérées, créez de nouveaux paramètres d’application pour ces composants non hôtes, même lorsqu’ils prennent en charge les identités gérées.

Ces paramètres spécifiques de l’application définissent des connexions basées sur l’identité à la fois à AzureWebJobsStorage et à APPLICATIONINSIGHTS_CONNECTION_STRING :

Setting Description
AzureWebJobsStorage__blobServiceUri L’URI pour Stockage Blob dans le compte de stockage par défaut. Requise pour les clouds souverains ou un DNS de stockage personnalisé, tels que : https://mystorageaccount.blob.contoso.com. HTTPS est obligatoire.
AzureWebJobsStorage__queueServiceUri L’URI du stockage en file d’attente dans le compte de stockage par défaut. Requise pour les clouds souverains ou un DNS de stockage personnalisé, tels que : https://mystorageaccount.queue.contoso.com. HTTPS est obligatoire.
AzureWebJobsStorage__tableServiceUri L’URI du service Table Storage du compte de stockage par défaut. Requise pour les clouds souverains ou un DNS de stockage personnalisé, tels que : https://mystorageaccount.table.contoso.com. HTTPS est obligatoire.
AzureWebJobsStorage__credential Définissez sur managedidentity pour utiliser l’authentification par identité managée. Une identité gérée doit être disponible dans l’environnement d’hébergement.
AzureWebJobsStorage__clientId ou
AzureWebJobsStorage__managedIdentityResourceId		 Retourne une identité spécifique attribuée par l’utilisateur, servant à obtenir un jeton d’accès dans le cadre de l’authentification par identité managée. Lorsque aucun n’est défini, l’identité assignée par le système de l’application est utilisée.
APPLICATIONINSIGHTS_AUTHENTICATION_STRING Permet la connexion à Application Insights grâce à l’authentification Microsoft Entra. Définir sur Authorization=AAD (attribué par le système) ou sur ClientId=<YOUR_CLIENT_ID>;Authorization=AAD (attribué par l’utilisateur).

Parce que la valeur du double soulignement (__) est interprétée à l’exécution comme un deux-points (:), la série de réglages est interprétée comme des propriétés de l’objet AzureWebJobsStorage . Par exemple, considérez ces AzureWebJobsStorage réglages de connexion :

  • AzureWebJobsStorage__blobServiceUri=https://<STORAGE_ACCOUNT_NAME>.blob.core.windows.net
  • AzureWebJobsStorage__queueServiceUri=https://<STORAGE_ACCOUNT_NAME>.queue.core.windows.net
  • AzureWebJobsStorage__tableServiceUri=https://<STORAGE_ACCOUNT_NAME>.table.core.windows.net
  • AzureWebJobsStorage__credential=managedidentity
  • AzureWebJobsStorage__clientId=<MY_USER_ASSIGNED_IDENTITY_ID>

À l’exécution, l’hôte interprète ces paramètres comme un paramètre complexe AzureWebJobsStorage.

"AzureWebJobsStorage":
{
    "blobServiceUri": "https://<STORAGE_ACCOUNT_NAME>.blob.core.windows.net",
    "queueServiceUri": "https://<STORAGE_ACCOUNT_NAME>.queue.core.windows.net",
    "tableServiceUri": "https://<STORAGE_ACCOUNT_NAME>.table.core.windows.net",
    "credential": "managedidentity",
    "clientId": "<MY_USER_ASSIGNED_IDENTITY_ID>"
}

Vous devez également accorder des autorisations pour l’identité dans le compte de stockage par défaut afin que l’hôte puisse se connecter avec suffisamment d’autorisations pour effectuer les tâches requises. Pour savoir comment, voir Accorder des autorisations à une identité.

Accorder des autorisations à une identité

Lorsque vous utilisez des identités gérées avec l’authentification Microsoft Entra ID, vous devez spécifiquement attribuer des permissions à l’identité que votre application utilise lors de la connexion au service distant. La façon la plus simple d’accorder les permissions de privilège minimum à votre application est d’assigner des rôles intégrés.

Gardez ces recommandations à l’esprit lorsque vous accordez des autorisations RBAC aux identités de votre application :

  • Dans la mesure du possible, respectez le principe du moindre privilège en accordant à l’identité uniquement les privilèges minimums requis. Par exemple, si l’application n’a besoin de lire que d’une source de données, utilisez un rôle qui n’a la permission que de lire et pas d’écrire des données.
  • N’utilisez pas de rôles intégrés larges comme Propriétaire, même juste pour faire fonctionner l’application.
  • Après avoir créé ou modifié une attribution de rôle, cela peut prendre jusqu’à 10 minutes pour que le changement se propage. Pendant ce temps, votre fonction peut recevoir des erreurs d’autorisation (403) même si le rôle est correctement attribué. Si vous rencontrez des erreurs immédiatement après avoir créé une attribution de rôle, attendez quelques minutes et réessayez.
  • Lorsque plusieurs connexions nécessitent des permissions pour le même service, utilisez le rôle qui constitue le sous-ensemble minimum de permissions pour toutes les connexions à ce service.
  • Plusieurs liaisons nécessitent des autorisations plus larges dans votre compte de stockage que celles requises par la AzureWebJobsStorage connexion.
  • Pour accéder aux clés dans Key Vault en utilisant des identités gérées, assignez votre application au rôle d’utilisateur Key Vault Secrets. Vous pouvez également utiliser une stratégie d’accès Key Vault pour attribuer à l’identité gérée l’autorisation Get pour les secrets. Pour plus d’informations, consultez accorder à une identité dans votre application l’accès à votre coffre de clés.
  • Cet article concerne uniquement les rôles intégrés qui fournissent des permissions minimales. Selon les besoins de votre application, vous devrez peut-être créer vos propres rôles personnalisés.

Les autorisations nécessaires dépendent du type de connexion :

  • AzureWebJobsStorage: Le rôle de propriétaire des données du Blob de stockage fournit les permissions minimales de compte de stockage pour la connexion requise AzureWebJobsStorage par l’hôte. Ce rôle donne le niveau d’accès au stockage dont l’hôte des fonctions a besoin tout en respectant le principe du moindre privilège.

    Pour certains types de problèmes, Fonctions peut lancer des événements de diagnostic pour vous aider à dépanner, même lorsque votre application ne peut pas démarrer. Vous devez également ajouter le rôle Storage Table Data Contributor , qui donne accès à Table Storage où ces événements de diagnostic sont persistés. Sans ces permissions supplémentaires, vous pourriez voir des avertissements dans vos journaux indiquant l’impossibilité d’écrire ces événements.

    Plusieurs autres fixations pourraient nécessiter un rôle un peu plus large. La colonne Stockage requis par l’hôte de la table dans l’onglet Liaisons liste ces exigences de rôle.

  • APPLICATIONINSIGHTS_AUTHENTICATION_STRING: Le rôle Monitoring Metrics Publisher accorde les autorisations minimales dont l’hébergeur a besoin pour se connecter à Application Insights pour la journalisation.

Note

Lorsque vous utilisez APPLICATIONINSIGHTS_AUTHENTICATION_STRING pour vous connecter à Application Insights à l’aide de l’authentification Microsoft Entra, vous devez également désactiver l’authentification locale pour Application Insights. Cette configuration nécessite l'authentification de Microsoft Entra pour que la télémétrie soit intégrée dans votre espace de travail.

Note

Utilisez Key Vault uniquement pour les connexions qui ne prennent pas actuellement en charge Microsoft Entra ID avec des identités gérées Azure.

Comme certains services ne prennent pas encore en charge l'authentification Microsoft Entra, votre application peut encore nécessiter des secrets dans certains cas. Dans ces cas, Azure Key Vault peut aider à simplifier le cycle de gestion de l’authentification basée sur les secrets. Votre application peut utiliser Key Vault pour stocker et accéder plus sûrement aux secrets partagés, y compris la chaîne de connexion de compte de stockage par défaut. Bien que les connexions utilisent toujours des secrets partagés, Key Vault offre un niveau de sécurité supérieur pour vos secrets, incluant la maintenance et la rotation des clés. Votre application peut se connecter à Key Vault en utilisant des identités gérées, même lorsque le service lui-même ne prend pas encore en charge les connexions basées sur l'identité gérée.

Lorsque vous utilisez Key Vault, créez votre paramètre d’application pour la connexion en utilisant une référence Key Vault au lieu du véritable secret. Pour plus d’informations, consultez les paramètres de l’application source dans Key Vault.

Gardez ces éléments à l’esprit lorsque vous maintenez des connexions dans Key Vault :

  • Pour accéder aux clés dans le coffre, vous devez accorder une identité dans votre application pour accéder à votre coffre-fort.

  • Vous pouvez utiliser Key Vault pour stocker les paramètres de vos connexions d’identité gérée. Lorsque votre application utilise Key Vault, les références doivent utiliser un séparateur de clé de : ou /, comme Storage1:blobServiceUri. Lorsque vous utilisez le délimiteur de paramètres d’application classique, __les noms de référence ne se résolvent pas correctement.

Vous pouvez configurer le AzureWebJobsStorage paramètre pour qu’il retourne une référence Key Vault contenant la chaîne de connexion au lieu de retourner la chaîne de connexion elle-même. Pour savoir comment procéder, consultez Utiliser des références Key Vault en tant que paramètres d’application.

Azure Files ne prend pas actuellement en charge les connexions d'identité gérée. En raison de cette limitation, utilisez Key Vault pour sécuriser le WEBSITE_AZUREFILESCONNECTIONSTRING paramètre, qui est nécessaire pour l’échelle dynamique des forfaits Consommation et Premium. Le plan Flex Consumption est aussi un plan dynamique qui n'utilise pas Azure Files et prend entièrement en charge les connexions d'identité gérées.

Caution

Évitez de travailler directement avec des secrets partagés. Dans la mesure du possible, utilisez une méthode d’authentification plus sécurisée pour vos connexions.

Réduisez les risques potentiels liés à la perte ou à la compromission de secrets en utilisant des identités gérées grâce à l’authentification Microsoft Entra ID. Lorsque le service distant ne prend pas en charge les identités gérées, utilisez au moins Azure Key Vault, qui maintient les secrets partagés de manière plus sécurisée.

Si, pour une raison quelconque, vous ne pouvez pas utiliser une méthode d’authentification plus sécurisée, la plateforme chiffre les données dans les paramètres de votre application pendant qu’elle est au repos. Migrez vos applications de l’utilisation des secrets partagés vers une méthode d’authentification plus sécurisée dès que possible.

Définissez la chaîne de connexion du compte de stockage par défaut dans le paramètre AzureWebJobsStorage. Ce réglage est le comportement de connexion par défaut lorsque vous créez votre application de fonction.

Gérer les connexions clients SDK

Lorsque vous créez vos propres connexions SDK client dans le code de fonction, réutilisez toujours les instances client entre les invocations plutôt que d’en créer de nouvelles. Cette bonne pratique sur tous les plans d’hébergement réduit la latence, évite l’épuisement des sockets et améliore l’efficacité des ressources.

Réutiliser les instances clients

Suivez ces directives lorsque vous utilisez un client spécifique à un service dans une application Azure Functions :

  • Ne créez pas un nouveau client à chaque invocation de fonction.
  • Créez un client unique partagé que chaque invocation de fonction puisse réutiliser.
  • Envisagez de créer un client unique et partagé dans une classe assistante si différentes fonctions utilisent le même service.

L’approche recommandée dépend de votre langage :

Utilisez l’injection de dépendances pour enregistrer les clients singleton ou à scope.

Voir les exemples de code client pour des motifs complets dans chaque langage.

Limites de connexion dans un plan de consommation

Note

Les limites de connexion dure décrites dans cette section ne s’appliquent qu’au plan de consommation hérité. Le plan Flex Consumption ne fonctionne pas dans le même environnement sandbox et n’impose pas ces limites. Cependant, la réutilisation des clients reste recommandée sur tous les plans pour des performances optimales.

Dans le plan Consumption hérité, les applications fonctionnelles s’exécutent dans un environnement bac à sable qui limite le nombre de connexions sortantes à 600 actives (1 200 au total) par instance. Lorsque vous atteignez cette limite, l’hôte Functions consigne le message suivant dans les journaux : Host thresholds exceeded: Connections. Pour plus d’informations, voir les limites du service Functions.

Cette limite s’effectue par instance. Quand le contrôleur de mise à l’échelle ajoute des instances d’application de fonction pour gérer plus de requêtes, chaque instance dispose d’une limite de connexion indépendante. Cela signifie qu’il n’y a pas de limite globale de connexions, et que vous pouvez avoir plus de 600 connexions actives sur toutes les instances actives.

Lorsque vous dépannez les problèmes de connexion, assurez-vous que Application Insights est activé pour votre application fonctionnelle. Application Insights vous permet d’afficher les métriques pour vos applications de fonction comme les exécutions. Pour plus d’informations, consultez l’article Afficher les données de télémétrie dans Application Insights.

Exemples de code client

Cette section présente les meilleures pratiques en matière de création et d’utilisation de clients à partir de votre code Function.

Requêtes HTTP

Enregistrer un HttpClient partagé en utilisant l’injection de dépendances afin que toutes les invocations de fonction réutilisent la même instance. Dans ce cas, vous n’avez pas besoin de libérer le client, car l’environnement d’exécution gère son cycle de vie.

using Microsoft.Azure.Functions.Extensions.DependencyInjection;
using Microsoft.Extensions.DependencyInjection;

[assembly: FunctionsStartup(typeof(MyNamespace.Startup))]

namespace MyNamespace;

public class Startup : FunctionsStartup
{
    public override void Configure(IFunctionsHostBuilder builder)
    {
        builder.Services.AddHttpClient();
    }
}

Ensuite, injectez IHttpClientFactory ou HttpClient dans votre classe de fonctions :

using Microsoft.Azure.Functions.Worker;
using Microsoft.Extensions.Logging;

namespace MyNamespace;

public class MyFunction(HttpClient httpClient, ILogger<MyFunction> logger)
{
    [Function("MyFunction")]
    public async Task Run([TimerTrigger("0 */5 * * * *")] TimerInfo timer)
    {
        var response = await httpClient.GetAsync("https://example.com");
        logger.LogInformation("Response status: {Status}", response.StatusCode);
    }
}

Azure Cosmos DB clients

Enregistrez un CosmosClient unique dans votre startup afin que toutes les fonctions partagent une seule connexion. La documentation Azure Cosmos DB recommande d’utiliser un client singleton pendant toute la durée de vie de votre application.

using Microsoft.Azure.Cosmos;
using Microsoft.Azure.Functions.Extensions.DependencyInjection;
using Microsoft.Extensions.DependencyInjection;

[assembly: FunctionsStartup(typeof(MyNamespace.Startup))]

namespace MyNamespace;

public class Startup : FunctionsStartup
{
    public override void Configure(IFunctionsHostBuilder builder)
    {
        builder.Services.AddSingleton(_ =>
        {
            var connectionString = Environment.GetEnvironmentVariable("CosmosDBConnection");
            return new CosmosClient(connectionString);
        });
    }
}

Ensuite, injectez CosmosClient dans votre classe de fonctions :

using Microsoft.Azure.Cosmos;
using Microsoft.Azure.Functions.Worker;
using Microsoft.Extensions.Logging;

namespace MyNamespace;

public class MyCosmosFunction(CosmosClient cosmosClient, ILogger<MyCosmosFunction> logger)
{
    private readonly Container _container = cosmosClient.GetContainer("mydb", "mycontainer");

    [Function("MyCosmosFunction")]
    public async Task Run([TimerTrigger("0 */5 * * * *")] TimerInfo timer)
    {
        var item = new { id = "myId", partitionKey = "myPartitionKey", data = "example" };
        await _container.UpsertItemAsync(item, new PartitionKey("myPartitionKey"));
        logger.LogInformation("Item upserted");
    }
}

Connexions SqlClient

Le code de votre fonction peut utiliser le fournisseur de données .NET Framework pour SQL Server (SqlClient) afin d’établir des connexions à une base de données relationnelle SQL. Ce fournisseur est également le fournisseur sous-jacent pour les cadres de données qui dépendent d’ADO.NET, tels qu’Entity Framework. Contrairement aux connexions HttpClient et DocumentClient, ADO.NET implémente par défaut le regroupement de connexions. Cependant, comme vous êtes toujours susceptible d’avoir un nombre insuffisant de connexions, vous devez optimiser les connexions à la base de données. Pour plus d’informations, consultez Regroupement de connexions SQL Server (ADO.NET).

Conseil

Certaines infrastructures de données, comme Entity Framework, obtiennent généralement les chaînes de connexion auprès de la section ConnectionStrings d’un fichier de configuration. Dans ce cas, vous devez ajouter explicitement les chaînes de connexion de base de données SQL à la collection Chaînes de connexion de vos paramètres d’application de fonction et dans le fichier local.settings.json de votre projet local. Si vous créez une instance de SqlConnection dans votre code de fonction, stockez la valeur de la chaîne de connexion dans les paramètres Application avec vos autres connexions.

Configuration d'application Azure

Azure App Configuration est un service Azure que vous pouvez utiliser pour gérer centralisément les paramètres d’application. App Configuration prend en charge les paires clé-valeur hiérarchiques et le versioning, et il s’intègre à Azure Key Vault pour une gestion des secrets plus sécurisée. Pour plus d’informations, consultez Présentation d’Azure App Configuration ?

Pour une meilleure sécurité, votre application de fonctions utilise des identités gérées avec l’authentification Microsoft Entra pour accéder aux paramètres dans un magasin d’applications. Pour plus d’informations, consultez Utiliser les références de configuration d’application pour Azure Functions.

Note

Lorsqu’on utilise Azure App Configuration pour stocker les paramètres des connexions basées sur l’identité gérée, les références doivent utiliser un séparateur de clé de : ou / dans le format <CONNECTION_NAME_PREFIX>:fullyQualifiedNamespace. Lorsque vous utilisez le délimiteur de paramètres d’application classique, __les noms de référence ne se résolvent pas correctement.

Contenu connexe

  • Last updated on