Manage secrets in Azure Container Apps
Azure Container Apps allows your application to securely store sensitive configuration values. Once secrets are defined at the application level, secured values are available to container apps. Specifically, you can reference secured values inside scale rules. For information on using secrets with Dapr, refer to Dapr integration
- Secrets are scoped to an application, outside of any specific revision of an application.
- Adding, removing, or changing secrets doesn't generate new revisions.
- Each application revision can reference one or more secrets.
- Multiple revisions can reference the same secret(s).
An updated or deleted secret doesn't automatically affect existing revisions in your app. When a secret is updated or deleted, you can respond to changes in one of two ways:
- Deploy a new revision.
- Restart an existing revision.
Before you delete a secret, deploy a new revision that no longer references the old secret. Then deactivate all revisions that reference the secret.
Note
Container Apps doesn't support Azure Key Vault integration. Instead, enable managed identity in the container app and use the Key Vault SDK in your app to access secrets.
Defining secrets
Secrets are defined at the application level in the resources.properties.configuration.secrets
section.
"resources": [
{
...
"properties": {
"configuration": {
"secrets": [
{
"name": "queue-connection-string",
"value": "<MY-CONNECTION-STRING-VALUE>"
}],
}
}
}
Here, a connection string to a queue storage account is declared in the secrets
array. In this example, you would replace <MY-CONNECTION-STRING-VALUE>
with the value of your connection string.
Referencing secrets in environment variables
After declaring secrets at the application level as described in the defining secrets section, you can reference them in environment variables when you create a new revision in your container app. When an environment variable references a secret, its value is populated with the value defined in the secret.
Example
The following example shows an application that declares a connection string at the application level. This connection is referenced in a container environment variable and in a scale rule.
In this example, the application connection string is declared as queue-connection-string
and becomes available elsewhere in the configuration sections.
{
"$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"
},
"queue-connection-string": {
"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",
"value": "[parameters('queue-connection-string')]"
}]
},
"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"
}
]
}
}
]
}
}
}
}]
}
Here, the environment variable named connection-string
gets its value from the application-level queue-connection-string
secret. Also, the Azure Queue Storage scale rule's authentication configuration uses the queue-connection-string
secret as to define its connection.
To avoid committing secret values to source control with your ARM template, pass secret values as ARM template parameters.
Next steps
Feedback
Submit and view feedback for