Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
When you run Azure Functions on Azure Container Apps, you work with two categories of secrets:
| Category | Description | Consumed by |
|---|---|---|
| App-level secrets | Configuration values your function code reads at runtime, such as database connection strings, API keys, and trigger/binding credentials. | Your code and the Functions runtime bindings. |
| Functions access keys | Authentication tokens (access keys) that secure HTTP-triggered function endpoints, including master, host, function, and system keys. | External callers of your HTTP functions (services, webhooks, developers). |
These two categories differ in direction:
| App-level secrets | Functions access keys | |
|---|---|---|
| Direction | Outbound - your function authenticates to other services | Inbound - callers authenticate to your function |
| Who holds the secret | Your function app | The caller (webhook provider, service, developer) |
| What it protects | What your function connects to | Who can invoke your HTTP endpoint |
| Validated by | The target service | The Functions runtime |
App-level secrets
App-level secrets are the credentials your function code and bindings need to connect to external services. You can store them in two ways:
| Option | Best for | Rotation | Audit | Guide |
|---|---|---|---|---|
| Container Apps secrets | Dev/test, simple single-app workloads | Manual | Activity logs only | Store app-level secrets |
| Key Vault references | Production, multi-app, compliance | Automatic (versionless URI) | Full Key Vault diagnostics | Store app-level secrets |
Tip
Start with Container Apps secrets for simplicity. Move to Key Vault references when you need centralized management, automatic rotation, or compliance-grade auditing.
Functions access keys
Access keys provide lightweight shared-secret authentication for HTTP endpoints. Use access keys when callers can't present Microsoft Entra ID tokens, such as third-party webhooks, service-to-service calls, or during development.
Set the AzureWebJobsSecretStorageType environment variable to choose a storage backend:
| Backend | Setting value | Best for | Guide |
|---|---|---|---|
| Container Apps secret store | containerapps |
Most workloads - no external dependencies (Recommended) | Configure host keys |
| Azure Key Vault | keyvault |
Centralized governance, compliance auditing | Configure host keys |
| Azure Blob Storage | blob |
Legacy apps or existing AzureWebJobsStorage dependency |
Configure host keys |
| Local file system | files |
Not recommended on Container Apps - see warning | N/A |
Keep these backend considerations in mind:
- The runtime doesn't automatically select Container Apps secret storage. If you don't set
AzureWebJobsSecretStorageTypeor set it to an unrecognized value, the Functions host uses Blob Storage whenAzureWebJobsStorageis available. - Keep
AzureWebJobsStorageconfigured for storage health checks and storage-dependent features. - Don't set
AzureWebJobsSecretStorageTypetofiles. The Container Apps file system is ephemeral, so keys stored with this backend are lost when the app scales to zero, restarts, or deploys a new revision.
Next steps
Choose the guide that matches the type of secret you need to manage:
- Store app-level secrets for Functions on Container Apps
- Configure Functions host key storage on Container Apps