Gérer les secrets dans Azure Container Apps

Azure Container Apps permet à votre application de stocker en toute sécurité les valeurs de configuration sensibles. Une fois les secrets définis au niveau de l'application, les valeurs sécurisées sont disponibles pour les révisions dans vos applications conteneurs. En outre, vous pouvez faire référence à des valeurs garanties dans les règles de mise à l'échelle. Pour plus d’informations sur l’utilisation des secrets avec Dapr, reportez-vous à Intégration de Dapr.

• Les secrets sont délimités à une application, en dehors de toute révision spécifique d’une application.
• De nouvelles révisions ne sont pas générées par l’ajout, la suppression ou la modification de secrets.
• Chaque révision d’application peut référencer un ou plusieurs secrets.
• Plusieurs révisions peuvent référencer les mêmes secrets.

Un secret mis à jour ou supprimé n’affecte pas automatiquement les révisions existantes dans votre application. Lors de la mise à jour ou de la suppression d’un secret, vous pouvez répondre à ces changements de l’une des deux manières suivantes :

1. Déployer une nouvelle révision.
2. Redémarrer une révision existante.

Avant de supprimer un secret, déployez une nouvelle révision qui ne fait plus référence à l’ancien secret. Désactivez ensuite toutes les révisions qui font référence au secret.

Autorisations pour la gestion des secrets

Azure Container Apps expose des opérations séparées listSecrets pour les applications conteneur, les jobs et les composants Dapr. Ces opérations renvoient des valeurs secrètes en texte clair. Accordez ces autorisations uniquement aux identités qui doivent lire des valeurs secrètes.

Plusieurs rôles intégrés Azure pour Container Apps définissent des autorisations à l’aide de caractères génériques, par souci de simplicité. Les exemples suivants permettent de lire des valeurs secrètes via une autorisation générique ou explicite listSecrets, même lorsque le nom ou la description du rôle suggère un accès plus restreint. Cette liste n'est pas exhaustive ; examinez les rôles intégrés actuels d'Azure pour les conteneurs avant d'en attribuer un.

Les rôles suivants donnent accès aux valeurs secrètes des applications conteneur ou des tâches conteneur :

Rôle prédéfini	Autorisations pertinentes dans la définition du rôle	Opération de mise en correspondance des secrets
Contributeur Container Apps	Microsoft.App/containerApps/*/action	Microsoft.App/containerApps/listSecrets/action
Opérateur Container Apps	Microsoft.App/containerApps/*/action	Microsoft.App/containerApps/listSecrets/action
Contributeur de tâches Container Apps	Microsoft.App/jobs/*/action	Microsoft.App/jobs/listSecrets/action
Opérateur de tâches Container Apps	Microsoft.App/jobs/*/action	Microsoft.App/jobs/listSecrets/action

Les rôles suivants donnent accès aux valeurs secrètes configurées pour les composants Dapr :

Rôle prédéfini	Autorisations pertinentes dans la définition du rôle	Opération de mise en correspondance des secrets
Contributeur Container Apps ManagedEnvironments	Microsoft.App/managedEnvironments/*/action	Microsoft.App/managedEnvironments/daprComponents/listSecrets/action
Contributeur de Container Apps ConnectedEnvironments	Microsoft.App/connectedEnvironments/*, Microsoft.App/connectedEnvironments/daprComponents/listSecrets/action	Microsoft.App/connectedEnvironments/daprComponents/listSecrets/action

L’accès effectif dépend de la portée de l’attribution du rôle. Par exemple, une attribution à l’échelle du groupe de ressources accorde l’autorisation correspondante pour chaque ressource applicable de ce groupe de ressources.

Important

Les descriptions des rôles d’Opérateur d’Applications Conteneurs et d’Opérateur d’Emplois Applications Conteneurs mettent l’accent sur les tâches opérationnelles. Cependant, leurs actions imprévisibles accordent également la permission de lister des secrets. Examinez la liste complète des autorisations d’un poste avant de lui attribuer.

Créez un rôle personnalisé avec des permissions plus étroites

Les rôles intégrés sont une commodité, pas une limite. Si aucun rôle intégré ne correspond au niveau d’accès que vous souhaitez accorder, définissez un rôle personnalisé Azure qui liste uniquement les opérations dont vous avez besoin et omet l’actionlistSecrets.

Par exemple, le rôle personnalisé suivant permet à un utilisateur de voir les tâches et les exécutions et d’arrêter d’exécuter les exécutions, sans accorder l’action listSecrets suivante :

{
  "Name": "Container Apps Jobs Execution Stopper",
  "IsCustom": true,
  "Description": "View Container Apps jobs and stop running executions.",
  "Actions": [
    "Microsoft.App/jobs/read",
    "Microsoft.App/jobs/executions/read",
    "Microsoft.App/jobs/execution/read",
    "Microsoft.App/jobs/stop/action",
    "Microsoft.App/jobs/stop/execution/action",
    "Microsoft.App/managedEnvironments/read"
  ],
  "NotActions": [],
  "AssignableScopes": [
    "/subscriptions/<SUBSCRIPTION_ID>"
  ]
}

Évitez les schémas de jokers comme Microsoft.App/jobs/*/action dans une définition de rôle personnalisée. Ce caractère générique autorise toutes les opérations actuelles et futures qui correspondent au motif, y compris listSecrets.

Warning

Pour les travaux Container Apps, omettre l’action listSecrets d’un rôle personnalisé ne suffit pas à protéger les valeurs des secrets si le rôle accorde également Microsoft.App/jobs/start/action. L’API REST Jobs - Start accepte un modèle d’exécution optionnel qui peut écraser les images du conteneur, les commandes et les variables d’environnement principales et initiales. Un utilisateur capable de lancer un travail et connaissant le nom d’un secret peut consulter ce secret depuis un conteneur de son choix et lire sa valeur à l’intérieur du conteneur. Le conteneur peut également utiliser n’importe quelle identité gérée configurée pour lui être disponible. Considérez l’autorisation de démarrer un emploi comme une autorisation d’utiliser les secrets du poste et les identités gérées disponibles.

Pour plus d’informations, consultez Rôles Azure personnalisés.

Définition de secrets

Les secrets sont définis comme un ensemble de paires nom/valeur. La valeur de chaque secret est spécifiée directement ou en tant que référence à un secret stocké dans Azure Key Vault.

Remarque

Évitez de spécifier la valeur d’un secret directement dans un environnement de production. Utilisez plutôt une référence à un secret stocké dans Azure Key Vault, comme décrit dans la valeur secrète Store dans la section Container Apps.

Stocker une valeur secrète dans des Container Apps

Les éléments suivants sont utilisés lorsque vous définissez des secrets via le portail ou via différentes options de ligne de commande.

Azure

1. Accédez à votre application conteneur dans le portail Azure.

2. Dans la section Sécurité , sélectionnez Secrets.

3. Sélectionnez Ajouter.

4. Dans le volet contextuel Ajouter un secret, entrez les informations suivantes :

   • Nom : Nom du secret.
   • Type : sélectionnez Container Apps Secret.
   • Valeur : Valeur du secret.

5. Sélectionnez Ajouter.

Modèle ARM

Les secrets sont définis au niveau de l’application dans la section resources.properties.configuration.secrets.

"resources": [
{
    ...
    "properties": {
        "configuration": {
            "secrets": [
            {
                "name": "queue-connection-string",
                "value": "<MY-CONNECTION-STRING-VALUE>"
            }],
        }
    }
}

Ici, une chaîne de connexion à un compte de stockage de files d'attente est déclarée dans le tableau secrets. Dans cet exemple, vous devez remplacer <MY-CONNECTION-STRING-VALUE> par la valeur de votre chaîne de connexion.

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

Lorsque vous créez une application conteneur, les secrets sont définis à l’aide du paramètre --secrets.

• Le paramètre accepte un jeu de paires nom/valeur délimité par des espaces.
• Un signe égal (=) délimite chaque paire.

az containerapp create \
  --resource-group "my-resource-group" \
  --name queuereader \
  --environment "my-environment-name" \
  --image demos/queuereader:v1 \
  --secrets "queue-connection-string=<CONNECTION_STRING>"

Ici, une chaîne de connexion à un compte de stockage de files d'attente est déclarée dans le paramètre --secrets. Remplacez <CONNECTION_STRING> par la valeur de votre chaîne de connexion.

PowerShell

Quand vous créez une application conteneur, les secrets sont définis comme un ou plusieurs objets Secret passés dans le paramètre ConfigurationSecrets.

$EnvId = (Get-AzContainerAppManagedEnv -ResourceGroupName my-resource-group -EnvName my-environment-name).Id
$TemplateObj = New-AzContainerAppTemplateObject -Name queuereader -Image demos/queuereader:v1
$SecretObj = New-AzContainerAppSecretObject -Name queue-connection-string -Value $QueueConnectionString

$ContainerAppArgs = @{
    Name = 'my-resource-group'
    Location = '<location>'
    ResourceGroupName = 'my-resource-group'
    ManagedEnvironmentId = $EnvId
    TemplateContainer = $TemplateObj
    ConfigurationSecret = $SecretObj
}

New-AzContainerApp @ContainerAppArgs

Ici, une chaîne de connexion à un compte de stockage de file d’attente est déclarée. La valeur de queue-connection-string provient d’une variable d’environnement nommée $QueueConnectionString.

Référencer le secret de Key Vault

Lorsque vous définissez un secret, vous créez une référence à un secret stocké dans Azure Key Vault. Container Apps récupère automatiquement la valeur secrète de Key Vault et la rend disponible en tant que secret dans votre application conteneur.

Pour référencer un secret à partir de Key Vault, vous devez d’abord activer l’identité managée dans votre application conteneur et accorder à l’identité l’accès aux secrets Key Vault.

Pour activer l’identité managée dans votre application conteneur, consultez Identités managées.

Pour accorder l’accès aux secrets de Key Vault, attribuez le rôle Azure RBAC Key Vault Secrets User à l'identité gérée.

Azure

1. Accédez à votre application conteneur dans le portail Azure.

2. Sous la section Sécurité , sélectionnez Identité.

3. Dans l’onglet Affectée par le système, définissez État sur Activé.

Remarque

Vous pouvez également utiliser une identité managée attribuée par l'utilisateur, qui peut être réutilisée sur plusieurs ressources et persiste indépendamment du cycle de vie de l’application. Pour l’utiliser, sélectionnez l’onglet Affecté par l’utilisateur et choisissez une identité existante.

1. Sélectionnez Enregistrer pour activer l’identité managée affectée par le système.

2. Une fenêtre contextuelle s’affiche pour confirmer que vous souhaitez activer l’identité managée affectée par le système et inscrire votre application conteneur avec Microsoft Entra ID. Sélectionnez Oui.

3. Dans la section Sécurité , sélectionnez Secrets.

4. Sélectionnez Ajouter.

5. Dans le volet contextuel Ajouter un secret, entrez les informations suivantes :

   • Nom : Nom du secret.
   • Type : sélectionnez référence Key Vault.
   • URL du secret Key Vault : URI de votre secret dans Key Vault. Cette URI a le format suivant : https://<YOUR_KEY_VAULT_NAME>.vault.azure.net/secrets/<YOUR_SECRET_NAME>/<32_DIGIT_HEX_ID>
   • Identité : sélectionnez Système affecté.

6. Sélectionnez Ajouter.

Modèle ARM

Les secrets sont définis au niveau de l’application dans la section resources.properties.configuration.secrets.

"resources": [
{
    ...
    "properties": {
        "configuration": {
            "secrets": [
            {
                "name": "queue-connection-string",
                "keyVaultUrl": "<KEY_VAULT_SECRET_URI>",
                "identity": "system"
            }],
        }
    }
}

Ici, une chaîne de connexion à un compte de stockage de files d'attente est déclarée dans le tableau secrets. Sa valeur est automatiquement récupérée à partir de Key Vault à l’aide de l’identité spécifiée. Pour utiliser une identité managée utilisateur, remplacez system par l’ID de ressource de l’identité.

Remplacez <KEY_VAULT_SECRET_URI> par l’URI de votre secret dans Key Vault.

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

Lorsque vous créez une application conteneur, les secrets sont définis à l’aide du paramètre --secrets.

• Le paramètre accepte un jeu de paires nom/valeur délimité par des espaces.
• Un signe égal (=) délimite chaque paire.
• Pour spécifier une référence Key Vault, utilisez le format <SECRET_NAME>=keyvaultref:<KEY_VAULT_SECRET_URI>,identityref:<MANAGED_IDENTITY_ID>. Par exemple, queue-connection-string=keyvaultref:https://mykeyvault.vault.azure.net/secrets/queuereader,identityref:/subscriptions/ffffffff-eeee-dddd-cccc-bbbbbbbbbbb0/resourcegroups/my-resource-group/providers/Microsoft.ManagedIdentity/userAssignedIdentities/my-identity.

az containerapp create \
  --resource-group "my-resource-group" \
  --name queuereader \
  --environment "my-environment-name" \
  --image demos/queuereader:v1 \
  --user-assigned "<USER_ASSIGNED_IDENTITY_ID>" \
  --secrets "queue-connection-string=keyvaultref:<KEY_VAULT_SECRET_URI>,identityref:<USER_ASSIGNED_IDENTITY_ID>"

Ici, une chaîne de connexion à un compte de stockage de files d'attente est déclarée dans le paramètre --secrets. Remplacez <KEY_VAULT_SECRET_URI> par l’URI de votre secret dans Key Vault. Remplacez <USER_ASSIGNED_IDENTITY_ID> par l’ID de ressource de l’identité d'utilisateur attribuée.

Remarque

L'identité attribuée à l'utilisateur doit avoir les autorisations nécessaires pour lire le secret dans le coffre de clés. L’identité affectée par le système ne peut pas être utilisée avec la commande create, car elle n’est disponible qu’après la création de l’application conteneur.

PowerShell

Les références des secrets dans Key Vault ne sont pas prises en charge dans PowerShell.

Remarque

Si vous utilisez UDR avec Pare-feu Azure, vous devez ajouter la balise de service AzureKeyVault et le nom de domaine complet login.microsoft.com à la liste d'autorisation de votre pare-feu. Reportez-vous à configuring UDR avec Pare-feu Azure pour déterminer les balises de service supplémentaires dont vous avez besoin.

URI de secret Key Vault et rotation des secrets

L’URI du secret Key Vault doit se trouver dans l’un des formats suivants :

• https://myvault.vault.azure.net/secrets/mysecret/ec96f02080254f109c51a1f14cdb1931 : Référencer une version spécifique d’un secret.
• https://myvault.vault.azure.net/secrets/mysecret : Référencer la version la plus récente d’un secret.

Si aucune version n’est spécifiée dans l’URI, l’application utilise la dernière version qui existe dans le coffre de clés. Lorsque des versions plus récentes deviennent disponibles, l’application récupère automatiquement la dernière version dans les 30 minutes. Toutes les révisions actives qui référencent le secret dans une variable d’environnement sont automatiquement redémarrées pour récupérer la nouvelle valeur.

Pour contrôler totalement la version à utiliser d’un secret, spécifiez la version dans l’URI.

Référencement des secrets dans des variables d’environnement

Après avoir déclaré des secrets au niveau de l’application, comme décrit dans la section définition des secrets, vous pouvez les référencer dans des variables d’environnement lorsque vous créez une révision dans votre application conteneur. Lorsqu’une variable d’environnement fait référence à un secret, sa valeur est remplie avec la valeur définie dans le secret.

Exemple

L’exemple suivant montre une application qui déclare une chaîne de connexion au niveau de l’application. Cette connexion est référencée dans une variable d’environnement de conteneur et dans une règle d’échelle.

Azure

Une fois que vous avez défini un secret dans votre application conteneur, vous pouvez le référencer dans une variable d’environnement lorsque vous créez une révision.

1. Accédez à votre application conteneur dans le portail Azure.

2. Dans la section Application, sélectionnez Révisions et répliques.

3. Dans la page Révisions et réplicas , sélectionnez Créer une nouvelle révision.

4. Dans la page Créer et déployer une nouvelle révision, sous l’onglet Conteneur, sous la section Image conteneur, sélectionnez un conteneur.

5. Sélectionnez Modifier.

6. Dans le volet de contexte Modifier un conteneur, sélectionnez l’onglet Variables d’environnement.

7. Sélectionnez Ajouter.

8. Saisissez les informations suivantes :

   • Nom : Nom de la variable d’environnement.
   • Source : Sélectionnez Référencer un secret.
   • Valeur : sélectionnez le secret que vous avez défini précédemment.

9. Cliquez sur Enregistrer.

10. Dans la page Créer et déployer une nouvelle révision, sélectionnez Créer pour créer la nouvelle révision.

Modèle ARM

Dans cet exemple, la chaîne de connexion de l'application est déclarée sous forme de queue-connection-string et devient accessible ailleurs dans les sections de configuration.

{
    "$schema": "https://schema.management.azure.com/schemas/2019-08-01/deploymentTemplate.json#",
    "contentVersion": "1.0.0.0",
    "parameters": {
        "location": {
            "type": "String"
        },
        "environment_id": {
            "type": "String"
        },
        "key_vault_secret_uri": { ⬅️
            "type": "String"      ⬅️
        }                         ⬅️
    },
    "variables": {},
    "resources": [
    {
        "name": "queuereader",
        "type": "Microsoft.App/containerApps",
        "apiVersion": "2022-03-01",
        "kind": "containerapp",
        "location": "[parameters('location')]",
        "properties": {
            "managedEnvironmentId": "[parameters('environment_id')]",
            "configuration": {
                "activeRevisionsMode": "single",
                "secrets": [                                              ⬅️
                {                                                         ⬅️
                    "name": "queue-connection-string",                    ⬅️
                    "keyVaultUrl": "[parameters('key_vault_secret_uri')", ⬅️
                    "identity": "system"                                  ⬅️ 
                }]                                                        ⬅️
            },
            "template": {
                "containers": [
                    {
                        "image": "myregistry/myQueueApp:v1",
                        "name": "myQueueApp",
                        "env": [
                            {
                                "name": "QueueName",
                                "value": "myqueue"
                            },
                            {
                                "name": "ConnectionString",            ⬅️
                                "secretRef": "queue-connection-string" ⬅️
                            }
                        ]
                    }
                ],
                "scale": {
                    "minReplicas": 0,
                    "maxReplicas": 10,
                    "rules": [
                        {
                            "name": "myqueuerule",
                            "azureQueue": {
                                "queueName": "demoqueue",
                                "queueLength": 100,
                                "auth": [
                                    {
                                        "secretRef": "queue-connection-string", ⬅️
                                        "triggerParameter": "connection"        ⬅️
                                    }
                                ]
                            }
                        }
                    ]
                }
            }
        }
    }]
}

Ici, la variable d’environnement nommée connection-string obtient sa valeur du secret queue-connection-string au niveau de l’application. En outre, la configuration d’authentification de la règle de mise à l’échelle de Stockage File d’attente Azure utilise le secret queue-connection-string pour définir sa connexion.

Pour éviter de valider des valeurs de secret dans le contrôle de code source avec votre modèle ARM, transmettez les valeurs de secret en tant que paramètres de modèle ARM.

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

Dans cet exemple, vous créez une application conteneur à l'aide du Azure CLI avec un secret référencé dans une variable d'environnement. Pour référencer un secret dans une variable d’environnement dans le Azure CLI, définissez sa valeur sur secretref:, suivie du nom du secret.

az containerapp create \
  --resource-group "my-resource-group" \
  --name myQueueApp \
  --environment "my-environment-name" \
  --image demos/myQueueApp:v1 \
  --user-assigned "<USER_ASSIGNED_IDENTITY_ID>" \
  --secrets "queue-connection-string=keyvaultref:<KEY_VAULT_SECRET_URI>,identityref:<USER_ASSIGNED_IDENTITY_ID>" \
  --env-vars "QueueName=myqueue" "ConnectionString=secretref:queue-connection-string"

Ici, la variable d’environnement nommée connection-string obtient sa valeur du secret queue-connection-string au niveau de l’application.

PowerShell

Les références des secrets dans Key Vault ne sont pas prises en charge dans PowerShell.

Dans cet exemple, vous créez un conteneur à l’aide de Azure PowerShell avec un secret référencé dans une variable d’environnement. Pour référencer le secret dans une variable d’environnement avec PowerShell, définissez sa valeur sur secretref:, suivi du nom du secret.

$EnvId = (Get-AzContainerAppManagedEnv -ResourceGroupName my-resource-group -EnvName my-environment-name).Id

$SecretObj = New-AzContainerAppSecretObject -Name queue-connection-string -Value $QueueConnectionString
$EnvVarObjQueue = New-AzContainerAppEnvironmentVarObject -Name QueueName -Value myqueue
$EnvVarObjConn = New-AzContainerAppEnvironmentVarObject -Name ConnectionString -SecretRef queue-connection-string -Value secretref
$TemplateObj = New-AzContainerAppTemplateObject -Name myQueueApp -Image demos/myQueueApp:v1 -Env $EnvVarObjQueue, $EnvVarObjConn

$ContainerAppArgs = @{
    Name = 'myQueueApp'
    Location = '<location>'
    ResourceGroupName = 'my-resource-group'
    ManagedEnvironmentId = $EnvId
    TemplateContainer = $TemplateObj
    ConfigurationSecret = $SecretObj
}

New-AzContainerApp @ContainerAppArgs

Ici, la variable d’environnement nommée ConnectionString obtient sa valeur du secret $QueueConnectionString au niveau de l’application.

Montage des secrets dans un volume

Après avoir déclaré des secrets au niveau de l’application, comme décrit dans la section définition des secrets, vous pouvez les référencer dans des montages de volume lorsque vous créez une révision dans votre application conteneur. Lorsque vous montez des secrets dans un volume, chaque secret est monté en tant que fichier dans le volume. Le nom de fichier est le nom du secret, et le contenu du fichier est la valeur du secret. Vous pouvez charger tous les secrets dans un montage de volume, ou vous pouvez charger des secrets spécifiques.

Exemple

Azure

Une fois que vous avez défini un secret dans votre application de conteneur, vous pouvez y faire référence lors du montage d'un volume lorsque vous créez une nouvelle révision.

1. Accédez à votre application conteneur dans le portail Azure.

2. Dans la section Application, sélectionnez Révisions et répliques.

3. Dans la page Révisions et réplicas , sélectionnez Créer une nouvelle révision.

4. Dans la page Créer et déployer une nouvelle révision, sous l’onglet Conteneur, sous la section Image conteneur, sélectionnez un conteneur.

5. Sélectionnez Modifier.

6. Dans le volet contextuel Modifier un conteneur, sélectionnez l’onglet Montages de volume.

7. Sélectionnez Créer un nouveau volume.

8. Dans le volet contextuel Ajouter un volume, entrez les informations suivantes :

   • Type de volume : Sélectionnez Secret.
   • Nom :mysecrets
   • Monter tous les secrets : activé

   Remarque

   Si vous souhaitez charger des secrets spécifiques, désactivez Monter tous les secrets et sélectionnez les secrets que vous souhaitez charger.

9. Sélectionnez Ajouter.

10. Dans le volet de contexte Modifier un conteneur, sous Nom du volume, sélectionnez mysecrets.

11. Sous Chemin de montage, entrez /mnt/secrets.

12. Cliquez sur Enregistrer.

13. Dans la page Créer et déployer une nouvelle révision, sélectionnez Créer pour créer la nouvelle révision avec le montage du volume.

Modèle ARM

Dans cet exemple, deux secrets sont déclarés au niveau de l’application. Ces secrets sont montés dans un volume nommé mysecrets de type Secret. Le volume est monté au niveau du chemin /mnt/secrets. L’application peut ensuite référencer les secrets dans le montage de volume.

{
    "$schema": "https://schema.management.azure.com/schemas/2019-08-01/deploymentTemplate.json#",
    "contentVersion": "1.0.0.0",
    "parameters": {
        "location": {
            "type": "String"
        },
        "environment_id": {
            "type": "String"
        },
        "key_vault_secret_uri": {
            "type": "Securestring"
        },
        "api-key": {
            "type": "Securestring"
        }
    },
    "variables": {},
    "resources": [
    {
        "name": "queuereader",
        "type": "Microsoft.App/containerApps",
        "apiVersion": "2022-11-01-preview",
        "kind": "containerapp",
        "location": "[parameters('location')]",
        "properties": {
            "managedEnvironmentId": "[parameters('environment_id')]",
            "configuration": {
                "activeRevisionsMode": "single",
                "secrets": [
                    {
                        "name": "queue-connection-string",
                        "keyVaultUrl": "[parameters('key_vault_secret_uri')",
                        "identity": "system"
                    },
                    {
                        "name": "api-key",
                        "value": "[parameters('api-key')]"
                    }
                ]
            },
            "template": {
                "containers": [
                    {
                        "image": "myregistry/myQueueApp:v1",
                        "name": "myQueueApp",
                        "volumeMounts": [
                            {
                                "name": "mysecrets",
                                "mountPath": "/mnt/secrets"
                            }
                        ]
                    }
                ],
                "volumes": [
                    {
                        "name": "mysecrets",
                        "storageType": "Secret"
                    }
                ]
            }
        }
    }]
}

Pour charger des secrets spécifiques et spécifier leur chemin dans le volume monté, vous définissez les secrets dans le tableau secrets de l’objet volume. L’exemple suivant montre comment charger uniquement le secret queue-connection-string dans le montage du volume mysecrets avec le nom de fichier connection-string.txt.

{
    "properties": {
        ...
        "configuration": {
            ...
            "secrets": [
                {
                    "name": "queue-connection-string",
                    "keyVaultUrl": "[parameters('key_vault_secret_uri')",
                    "identity": "system"
                },
                {
                    "name": "api-key",
                    "value": "[parameters('api-key')]"
                }
            ]
        },
        "template": {
            "containers": [
                {
                    "image": "myregistry/myQueueApp:v1",
                    "name": "myQueueApp",
                    "volumeMounts": [
                        {
                            "name": "mysecrets",
                            "mountPath": "/mnt/secrets"
                        }
                    ]
                }
            ],
            "volumes": [
                {
                    "name": "mysecrets",
                    "storageType": "Secret",
                    "secrets": [
                        {
                            "secretRef": "queue-connection-string",
                            "path": "connection-string.txt"
                        }
                    ]
                }
            ]
        }
        ...
    }
    ...
}

Dans votre application, vous pouvez lire le secret à partir d’un fichier qui se trouve dans /mnt/secrets/connection-string.txt.

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

Dans cet exemple, deux secrets sont déclarés au niveau de l’application. Ces secrets sont montés dans un volume nommé mysecrets de type Secret. Le volume est monté au niveau du chemin /mnt/secrets. L’application peut ensuite lire les secrets en tant que fichiers dans le montage de volume.

az containerapp create \
  --resource-group "my-resource-group" \
  --name myQueueApp \
  --environment "my-environment-name" \
  --image demos/myQueueApp:v1 \
  --user-assigned "<USER_ASSIGNED_IDENTITY_ID>" \
  --secrets "queue-connection-string=keyvaultref:<KEY_VAULT_SECRET_URI>,identityref:<USER_ASSIGNED_IDENTITY_ID>" "api-key=$API_KEY" \
  --secret-volume-mount "/mnt/secrets"

Pour charger des secrets spécifiques et indiquer leur chemin dans le volume monté, définissez votre application à l’aide de YAML.

PowerShell

Le montage de secrets en tant que volume n’est pas pris en charge dans PowerShell.

Résoudre les problèmes des références de Key Vault

Lorsque vous référencez des secrets à partir de Azure Key Vault, vous pouvez rencontrer des problèmes lors de la récupération ou de la synchronisation des secrets. Voici les erreurs et résolutions courantes :

Error	La cause	Résolution
Identité gérée non activée	L’application conteneurisée n’a pas d’identité managée affectée.	Activez l'identité managée gérée par le système ou par l'utilisateur sur votre application de conteneur. Consultez Identités managées.
Identité introuvable	L’identité managée spécifiée n’existe pas ou n’est pas affectée à l’application conteneur.	Vérifiez que l’identité est créée et affectée à l’application conteneur dans la section Identité .
Secret désactivé dans Key Vault	Le secret est désactivé dans la ressource Key Vault.	Accédez à votre Key Vault dans le portail Azure et activez le secret.
Échec de l’authentification	L’identité managée ne dispose pas des autorisations requises pour lire le secret.	Accordez le rôle utilisateur des secrets de Key Vault à l'identité gérée sur votre Key Vault. Voir Utilisateur des secrets Key Vault.
Autorisation RBAC refusée	L’identité managée dispose d’autorisations insuffisantes pour accéder au Key Vault.	Vérifiez l’attribution de rôle RBAC sur le coffre de clés et assurez-vous qu'elle inclut des autorisations de lecture pour les secrets.

Étapes suivantes

conteneurs