Configurer le stockage des clés d’hôte Functions sur Azure Container Apps

Les clés d’accès Functions sont des jetons d’authentification que le runtime Functions utilise pour sécuriser les points de terminaison HTTP. Lorsqu’un appelant appelle une fonction HTTP, il inclut une clé en tant que ?code= paramètre de requête ou en-tête x-functions-key . Le runtime valide la clé et autorise ou rejette la demande.

Les clés d’accès ne sont pas les mêmes que les secrets au niveau de l’application. Les clés d’accès protègent les personnes qui peuvent appeler vos fonctions, tandis que les secrets au niveau de l’application protègent ce à quoi vos fonctions se connectent.

Quand utiliser des clés d’accès

Scénario	Pourquoi les touches d’accès conviennent-elles?
Webhooks de tiers	Les fournisseurs tels que GitHub, Stripe ou Twilio appellent votre fonction via une URL et un secret. Les clés d’accès s’insèrent directement dans le schéma `?code=` attendu.
Appels de service à service	Le service principal A appelle la fonction B sur HTTP. Une clé partagée est plus simple que de configurer les enregistrements d'application Microsoft Entra pour les appels internes uniquement.
Abonnements Event Grid	Event Grid valide et appelle votre point de terminaison de fonction à l’aide d’une clé système que la plateforme gère automatiquement.
Dev/test l’authentification	Pendant le développement, vous avez besoin d’une authentification de base sans configurer oAuth/OIDC complet. Les clés d’accès fournissent une porte d’authentification à faible friction sans configuration d’identité.
Compatibilité de la migration	Les applications Azure Functions existantes utilisent déjà des clés d’accès. Lors de la migration vers Container Apps, vous avez besoin de la même authentification basée sur des clés pour éviter de perturber les appels.

Note

Pour les API accessibles par l’utilisateur, les charges de travail de confiance zéro ou les scénarios d’autorisation par utilisateur, utilisez Microsoft Entra ID / OAuth 2.0 au lieu des clés d’accès. Les clés d’accès sont des secrets partagés sans piste d’audit au niveau de l’identité.

Conditions préalables

Un compte Azure avec un abonnement actif. Créez un compte gratuitement.
Azure CLI version 2.40.0 ou ultérieure.
Une application Azure Functions existante dans Container Apps ou des autorisations pour en créer une.

Types de clés d’accès

Le runtime Functions gère quatre types de clés :

Type de clé	Scope	Objectif
Clé principale (`_master`)	Application complète de fonctions	Accès au niveau de l’administrateur à toutes les fonctions et aux points de terminaison de gestion `/admin/*`. Ne peut pas être révoqué, uniquement remplacé.
Clés d’hôte (`default` + personnalisées)	Application complète de fonctions	Autoriser les appels à n’importe quelle fonction déclenchée par HTTP dans l’application.
Touches de fonction (`default` + personnalisées)	Fonction unique	Autoriser les appels à une fonction spécifique. Fournit un contrôle plus précis que les clés de l'hôte.
Clés système	Points de terminaison d’extension	Utilisé par des extensions de plateforme telles que les abonnements webhook Event Grid et Durable Functions. Géré automatiquement.

Choisir un back-end de stockage

Définissez la variable d’environnement AzureWebJobsSecretStorageType pour contrôler où le runtime conserve les clés d’accès. Azure Container Apps prend en charge trois back-ends de niveau production.

Back-end	Valeur de réglage	Génère automatiquement des clés	Dépendance externe	Idéal pour
Magasin de secrets des Container Apps	`containerapps`	Non : vous provisionnez des clés en tant que secrets dans Container Apps	None	La plupart des charges de travail (recommandées)
Azure Key Vault	`keyvault`	Non - créer le déclenchement manuellement	instance de Key Vault	Gouvernance centralisée, audit de conformité
Stockage Blob Azure	`blob`	Oui	Compte de stockage	Applications héritées ou compte existant `AzureWebJobsStorage`

Gardez à l’esprit ces considérations en arrière-plan :

L’exécution ne sélectionne pas automatiquement le stockage secret des applications conteneures. Si vous ne le définissez AzureWebJobsSecretStorageType pas ou ne le définissez pas à une valeur non reconnue, l'hôte Functions utilise Stockage Blob quand AzureWebJobsStorage c'est disponible.
Gardez AzureWebJobsStorage la configuration pour les contrôles de santé du stockage et les fonctionnalités dépendantes du stockage.
Ne définissez pas AzureWebJobsSecretStorageType sur files. Le système de fichiers Conteneur Apps est éphémère, donc les clés stockées avec ce backend sont perdues lorsque l’application s’étale à zéro, redémarre ou déploie une nouvelle version.

Modèles des noms secrets

La convention d’affectation de noms pour les clés stockées dépend du serveur principal de stockage.

Le magasin de secrets Container Apps utilise une convention différente. L’hôte Functions lit les clés à partir de fichiers montés sur un volume dans /run/secrets/functions-keys/. Chaque fichier utilise un nom en pointillé (par exemple), host.mastermais les noms de secrets Container Apps autorisent uniquement les caractères alphanumériques minuscules et les tirets. Lorsque vous montez un volume secret, vous devez définir explicitement le champ path sur le nom de fichier en pointillé attendu par l'hôte des fonctions (par exemple, secretRef: host-master → path: host.master). La plateforme n’effectue aucune traduction automatique de noms.

Type de clé	Nom du secret Container Apps (tirets)	Montage de volume `path` (points)
Clé principale	`host-master`	`host.master`
Clé d’hôte par défaut	`host-function-default`	`host.function.default`
Clé d’hôte personnalisée	`host-function-<name>`	`host.function.<name>`
Clé de fonction par défaut pour une fonction spécifique	`functions-<functionname>-default`	`functions.<functionName>.default`
Clé de fonction personnalisée pour une fonction spécifique	`functions-<functionname>-<keyname>`	`functions.<functionName>.<keyName>`
Clé système	`host-systemkey-<extension>`	`host.systemKey.<extension>`

Le serveur principal Key Vault stocke chaque clé en tant que secret Key Vault individuel à l’aide d’une convention de double tiret (--) :

Type de clé	Modèle de nom de secret	Example
Clé principale	`host--masterKey--master`	`host--masterKey--master`
Clé de fonction (par défaut)	`host--functionKey--default`	`host--functionKey--default`
Clé de fonction (personnalisée)	`host--functionKey--<name>`	`host--functionKey--MyApiClient`
Clé système	`host--systemKey--<extension>`	`host--systemKey--eventgrid_extension`
Clé par fonction	`function--<functionName>--<keyName>`	`function--myhttpfunc--default`

Le serveur principal Stockage Blob stocke les clés en tant que fichiers JSON dans le conteneur d’objets blob azure-webjobs-secrets. Toutes les clés au niveau de l’hôte (master, clés de fonction et clés système) sont stockées ensemble dans un objet blob unique host.json . Les clés par fonction sont stockées dans des objets blob distincts nommés après chaque fonction.

Chemin d’accès d’objet blob	Contenu
`<SITE_SLOT_NAME>/host.json`	Fichier JSON contenant `masterKey`, `functionKeys`et `systemKeys`
`<SITE_SLOT_NAME>/<FUNCTION_NAME>.json`	Fichier JSON contenant des clés pour une fonction spécifique

Conseil / Astuce

Lors de la résolution des problèmes, recherchez ces modèles dans votre magasin principal pour vérifier que les clés sont correctement configurées.

Configurer le magasin de secrets de Container Apps

Le magasin de secrets Container Apps est le serveur backend recommandé. Les clés restent dans la plateforme Container Apps et ne nécessitent aucun stockage externe ni Key Vault. Azure Resource Manager journaux d'activités suivent les modifications apportées aux secrets et aux variables d'environnement.

Avec ce back-end, l’hôte Functions lit les clés à partir de fichiers montés sur un volume dans /run/secrets/functions-keys/. L’hôte ne génère pas automatiquement les clés. Vous devez créer chaque clé en tant que secret Container Apps, et la plateforme les monte en tant que fichiers pour que l’hôte lise.

Important

Le stockage des secrets de Container Apps est en lecture seule du point de vue de l’hôte. L’hôte lit les fichiers de clés montés, mais n’y écrit jamais. Si une clé requise est manquante, l’hôte ne le génère pas automatiquement.

Accédez à votre application conteneur Functions dans le portail Azure.
Sous Paramètres, sélectionnez Variables d’environnement.
Sélectionnez Ajouter, puis entrez les valeurs suivantes :

Propriété Valeur

Nom AzureWebJobsSecretStorageType

Valeur containerapps
Sélectionnez Enregistrer, puis sélectionnez Appliquer pour confirmer les modifications.

Propriété	Valeur
Nom	`AzureWebJobsSecretStorageType`
Valeur	`containerapps`

az containerapp update \
  --resource-group "<RESOURCE_GROUP>" \
  --name "<FUNCTIONS_APP_NAME>" \
  --set-env-vars "AzureWebJobsSecretStorageType=containerapps"

Étape 2 : Générer et stocker des secrets de clé d’accès

Générez des valeurs de clé et stockez-les en tant que secrets de Container Apps. Au minimum, vous avez besoin de la clé principale et d’une clé hôte par défaut.

Portal
Service de contrôle d’accès Azure (CLI)

Dans votre application conteneur Functions, sous Paramètres, sélectionnez Secrets.
Sélectionnez Ajouter et entrez les valeurs suivantes :

Propriété Valeur

Nom host-master

Type Secret Container Apps

Valeur Valeur de clé générée de manière aléatoire.
Cliquez sur Ajouter.
Répétez cette opération pour host-function-default avec une nouvelle valeur générée aléatoirement.
Pour ajouter une clé par fonction, ajoutez un secret nommé functions-<functionname>-default (tout en minuscules).

Propriété	Valeur
Nom	`host-master`
Type	Secret Container Apps
Valeur	Valeur de clé générée de manière aléatoire.

# Generate random key values
MASTER_KEY=$(openssl rand -hex 32)
HOST_DEFAULT_KEY=$(openssl rand -hex 32)

# Store as Container Apps secrets
az containerapp secret set \
  --resource-group "<RESOURCE_GROUP>" \
  --name "<FUNCTIONS_APP_NAME>" \
  --secrets "host-master=$MASTER_KEY" "host-function-default=$HOST_DEFAULT_KEY"

Pour ajouter une clé par fonction (par exemple, pour une fonction nommée MyHttpFunc) :

FUNC_KEY=$(openssl rand -hex 32)

az containerapp secret set \
  --resource-group "<RESOURCE_GROUP>" \
  --name "<FUNCTIONS_APP_NAME>" \
  --secrets "functions-myhttpfunc-default=$FUNC_KEY"

Note

Les noms de secrets de Container Apps autorisent uniquement les caractères alphanumériques minuscules et les tirets. Vous devez définir explicitement le path champ dans la configuration du volume sur le nom de fichier en pointillé attendu par l’hôte Functions (par exemple, secretRef: host-master → path: host.master). Sans explicite path, le fichier sur le disque conserve le nom en pointillés et l’hôte Functions ne trouve pas la clé.

Étape 3 : Configurer le montage du volume

Montez les secrets en tant que fichiers à l’adresse /run/secrets/functions-keys/.

Portal
Service de contrôle d’accès Azure (CLI)

Dans votre application conteneur Functions, sous Application, sélectionnez Révisions et réplicas.
Sélectionnez Créer une révision.
Dans l’onglet Échelle et volumes , sous Volumes, sélectionnez Ajouter.
Saisissez les valeurs suivantes :

Propriété Valeur

Type de volume Secret

Nom functions-keys
Pour chaque secret, définissez le champ Chemin sur le nom de fichier avec points attendu par l’hôte Functions (par exemple, définissez host-master sur le chemin d’accès host.master et host-function-default sur le chemin host.function.default).
Cliquez sur Ajouter.
Sous l’onglet Conteneur , sélectionnez votre conteneur, puis sélectionnez Modifier.
Sélectionnez l’onglet Montages de volume , puis sélectionnez Ajouter.
Saisissez les valeurs suivantes :

Propriété Valeur

Nom du volume functions-keys

Chemin de montage /run/secrets/functions-keys
Sélectionnez Enregistrer, puis créez pour déployer la nouvelle révision.

Propriété	Valeur
Type de volume	Secret
Nom	`functions-keys`

Propriété	Valeur
Nom du volume	`functions-keys`
Chemin de montage	`/run/secrets/functions-keys`

Exportez le YAML de votre application, ajoutez le volume et le montage de volume, puis appliquez-les :

# Export current config
az containerapp show \
  --resource-group "<RESOURCE_GROUP>" \
  --name "<FUNCTIONS_APP_NAME>" \
  --output yaml > app.yaml

Modifiez app.yaml pour ajouter le volume et le montage de volume sous les sections appropriées :

properties:
  template:
    volumes:
      - name: functions-keys
        storageType: Secret
        secrets:
          - secretRef: host-master
            path: host.master
          - secretRef: host-function-default
            path: host.function.default
    containers:
      - name: <CONTAINER_NAME>
        volumeMounts:
          - volumeName: functions-keys
            mountPath: /run/secrets/functions-keys

Appliquez la configuration mise à jour :

az containerapp update \
  --resource-group "<RESOURCE_GROUP>" \
  --name "<FUNCTIONS_APP_NAME>" \
  --yaml app.yaml

Étape 4 : Vérifier

Une fois l’application redémarrée, vérifiez que les clés fonctionnent :

az containerapp function keys list \
  --resource-group "<RESOURCE_GROUP>" \
  --name "<FUNCTIONS_APP_NAME>" \
  --key-type hostKey

Vous pouvez également vérifier les journaux de l’application pour le message Resolved secret storage provider ContainerAppsSecretsRepository, qui confirme que l’hôte utilise le magasin de secrets Container Apps.

Faire tourner les clés

Pour faire pivoter une clé, mettez à jour le secret Container Apps et redémarrez l’application :

NEW_KEY=$(openssl rand -hex 32)

az containerapp secret set \
  --resource-group "<RESOURCE_GROUP>" \
  --name "<FUNCTIONS_APP_NAME>" \
  --secrets "host-function-default=$NEW_KEY"

az containerapp revision restart \
  --resource-group "<RESOURCE_GROUP>" \
  --name "<FUNCTIONS_APP_NAME>" \
  --revision "<REVISION_NAME>"

Note

Tous les réplicas partagent les mêmes secrets montés. Après un redémarrage, chaque réplica récupère les valeurs de clé mises à jour.

Configurez Key Vault ou Stockage Blob comme le store

Configurez Key Vault
Configurez le Stockage Blob

Le serveur principal Key Vault stocke les clés d’accès en tant que secrets Key Vault, fournissant un audit et un contrôle d’accès de niveau entreprise.

Créez une Key Vault (si vous n'en avez pas) :

az keyvault create \
  --name "<KEYVAULT_NAME>" \
  --resource-group "<RESOURCE_GROUP>" \
  --location "<LOCATION>"

Activez l’identité managée sur votre application conteneur (si elle n’est pas déjà activée) :

az containerapp identity assign \
  --resource-group "<RESOURCE_GROUP>" \
  --name "<FUNCTIONS_APP_NAME>" \
  --system-assigned

Attribuez le rôle Responsable des secrets de Key Vault à l’identité managée. Le runtime a besoin d’un accès en lecture et en écriture pour créer et gérer des clés :

PRINCIPAL_ID=$(az containerapp show \
  --resource-group "<RESOURCE_GROUP>" \
  --name "<FUNCTIONS_APP_NAME>" \
  --query identity.principalId \
  --output tsv)

KEYVAULT_ID=$(az keyvault show \
  --name "<KEYVAULT_NAME>" \
  --query id \
  --output tsv)

az role assignment create \
  --role "Key Vault Secrets Officer" \
  --assignee "$PRINCIPAL_ID" \
  --scope "$KEYVAULT_ID"

Définissez le type de stockage et l’URI Key Vault :

Pour l'identité attribuée par le système :

az containerapp update \
  --resource-group "<RESOURCE_GROUP>" \
  --name "<FUNCTIONS_APP_NAME>" \
  --set-env-vars \
    "AzureWebJobsSecretStorageType=keyvault" \
    "AzureWebJobsSecretStorageKeyVaultUri=https://<KEYVAULT_NAME>.vault.azure.net"

Pour l’identité utilisateur associée, définissez également l’ID client :

az containerapp update \
  --resource-group "<RESOURCE_GROUP>" \
  --name "<FUNCTIONS_APP_NAME>" \
  --set-env-vars \
    "AzureWebJobsSecretStorageType=keyvault" \
    "AzureWebJobsSecretStorageKeyVaultUri=https://<KEYVAULT_NAME>.vault.azure.net" \
    "AzureWebJobsSecretStorageKeyVaultClientId=<USER_ASSIGNED_IDENTITY_CLIENT_ID>"

Déclencher la création de clé en répertoriant les clés :

az containerapp function keys list \
  --resource-group "<RESOURCE_GROUP>" \
  --name "<FUNCTIONS_APP_NAME>" \
  --key-type hostKey

Le serveur principal Stockage Blob permet au runtime de générer et de gérer automatiquement les clés d’accès. Utilisez cette option lorsque vous disposez déjà d’un compte de stockage pour AzureWebJobsStorage lequel vous n’avez pas besoin de gouvernance centralisée.

Activez l’identité managée sur votre application conteneur (si elle n’est pas déjà activée) :

az containerapp identity assign \
  --resource-group "<RESOURCE_GROUP>" \
  --name "<FUNCTIONS_APP_NAME>" \
  --system-assigned

Attribuez le rôle Contributeur aux données Blob du stockage sur le compte de stockage à l’identité managée :

PRINCIPAL_ID=$(az containerapp show \
  --resource-group "<RESOURCE_GROUP>" \
  --name "<FUNCTIONS_APP_NAME>" \
  --query identity.principalId \
  --output tsv)

STORAGE_ID=$(az storage account show \
  --name "<STORAGE_ACCOUNT_NAME>" \
  --resource-group "<RESOURCE_GROUP>" \
  --query id \
  --output tsv)

az role assignment create \
  --role "Storage Blob Data Contributor" \
  --assignee "$PRINCIPAL_ID" \
  --scope "$STORAGE_ID"

Définissez le type de stockage :

az containerapp update \
  --resource-group "<RESOURCE_GROUP>" \
  --name "<FUNCTIONS_APP_NAME>" \
  --set-env-vars "AzureWebJobsSecretStorageType=blob"

Le runtime génère automatiquement des clés au prochain démarrage à froid. Vérifier:

az containerapp function keys list \
  --resource-group "<RESOURCE_GROUP>" \
  --name "<FUNCTIONS_APP_NAME>" \
  --key-type hostKey

Gérer les clés d’accès

Quel que soit le serveur principal, utilisez les commandes suivantes pour répertorier, créer et supprimer des clés d’accès :

Note

Gardez au moins une réplique en fonctionnement pour effectuer ces opérations de gestion des clés.

Listez toutes les clés d’hôte :

az containerapp function keys list \
  --resource-group "<RESOURCE_GROUP>" \
  --name "<FUNCTIONS_APP_NAME>" \
  --key-type hostKey

Listez la clé maîtresse :

az containerapp function keys list \
  --resource-group "<RESOURCE_GROUP>" \
  --name "<FUNCTIONS_APP_NAME>" \
  --key-type masterKey

Créer ou écraser une clé hôte personnalisée :

az containerapp function keys set \
  --resource-group "<RESOURCE_GROUP>" \
  --name "<FUNCTIONS_APP_NAME>" \
  --key-name "MyCustomKey" \
  --key-value "<YOUR_KEY_VALUE>" \
  --key-type hostKey

Affichez une clé spécifique :

az containerapp function keys show \
  --resource-group "<RESOURCE_GROUP>" \
  --name "<FUNCTIONS_APP_NAME>" \
  --key-name "<KEY_NAME>" \
  --key-type hostKey

Supprimer une clé hôte :

az containerapp function keys delete \
  --resource-group "<RESOURCE_GROUP>" \
  --name "<FUNCTIONS_APP_NAME>" \
  --key-name "MyCustomKey" \
  --key-type hostKey

Appeler une fonction avec une clé d’accès

Transmettez la clé en tant que paramètre de requête ou en-tête de requête.

# Query parameter
curl "https://<FUNCTIONS_APP_URL>/api/<FUNCTION_NAME>?code=<HOST_KEY>"

# Header
curl "https://<FUNCTIONS_APP_URL>/api/<FUNCTION_NAME>" \
  -H "x-functions-key: <HOST_KEY>"

Commentaires

Est-ce que cette page vous a été utile?

Last updated on 2026-08-14

Configurer le stockage des clés d’hôte Functions sur Azure Container Apps

Quand utiliser des clés d’accès

Conditions préalables

Types de clés d’accès

Choisir un back-end de stockage

Modèles des noms secrets

Configurer le magasin de secrets de Container Apps

Étape 1 : Définir le type de stockage

Étape 2 : Générer et stocker des secrets de clé d’accès

Étape 3 : Configurer le montage du volume

Étape 4 : Vérifier

Faire tourner les clés

Configurez Key Vault ou Stockage Blob comme le store

Gérer les clés d’accès

Appeler une fonction avec une clé d’accès

Contenu connexe

Commentaires

Ressources supplémentaires