Configure Functions host key storage on Azure Container Apps

Functions access keys are authentication tokens that the Functions runtime uses to secure HTTP-triggered endpoints. When a caller invokes an HTTP function, it includes a key as a ?code= query parameter or an x-functions-key header. The runtime validates the key and authorizes or rejects the request.

Access keys aren't the same as app-level secrets. Access keys protect who can call your functions, while app-level secrets protect what your functions connect to.

When to use access keys

Prerequisites

• An Azure account with an active subscription. Create an account for free.
• Azure CLI version 2.40.0 or higher.
• An existing Azure Functions app in Container Apps or permissions to create one.

Access key types

The Functions runtime manages four types of keys:

Secret name patterns

The naming convention for stored keys depends on the storage backend.

Key Vault

The Key Vault backend stores each key as an individual Key Vault secret using a double-dash (--) convention:

Blob Storage

The Blob Storage backend stores keys as JSON files in the azure-webjobs-secrets blob container. All host-level keys (master, function keys, and system keys) are stored together in a single host.json blob. Per-function keys are stored in separate blobs named after each function.

Container Apps secret store

The Container Apps secret store uses a different convention. The Functions host reads keys from volume-mounted files at /run/secrets/functions-keys/. Each file uses a dotted name (for example, host.master), but Container Apps secret names only allow lowercase alphanumeric characters and dashes. When you mount a secret volume, you must explicitly set the path field to the dotted file name the Functions host expects (for example, secretRef: host-master → path: host.master). The platform doesn't perform any automatic name translation.

Choose a storage backend

Set the AzureWebJobsSecretStorageType environment variable to control where the runtime persists access keys. Azure Container Apps supports three production-grade backends.

Configure the Container Apps secret store

The Container Apps secret store is the recommended backend. Keys stay within the Container Apps platform and require no external storage or Key Vault. Azure Resource Manager activity logs track changes to secrets and environment variables.

With this backend, the Functions host reads keys from files volume-mounted at /run/secrets/functions-keys/. The host doesn't auto-generate keys. You must create each key as a Container Apps secret, and the platform mounts them as files for the host to read.

Step 1: Set the storage type

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

Step 2: Generate and store access key secrets

Generate key values and store them as Container Apps secrets. At minimum, you need the master key and a default host key.

# 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"

FUNC_KEY=$(openssl rand -hex 32)

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

Step 3: Configure the volume mount

Mount the secrets as files at /run/secrets/functions-keys/.

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

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

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

Step 4: Verify

After the app restarts, confirm the keys are working:

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

You can also check the app logs for the message Resolved secret storage provider ContainerAppsSecretsRepository, which confirms the host is using the Container Apps secret store.

Rotate keys

To rotate a key, update the Container Apps secret and restart the app:

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>"

Configure Blob Storage

The Blob Storage backend enables the runtime to auto-generate and manage access keys. Use this option when you already have a storage account for AzureWebJobsStorage and don't need centralized governance.

1. Enable managed identity on your container app (if not already enabled):

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

2. Grant the Storage Blob Data Contributor role on the storage account to the managed identity:

   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"
   

3. Set the storage type:

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

4. The runtime auto-generates keys on the next cold start. Verify:

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

Configure Key Vault

The Key Vault backend stores access keys as Key Vault secrets, providing enterprise-grade auditing and access control.

1. Create a Key Vault (if you don't have one):

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

2. Enable managed identity on your container app (if not already enabled):

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

3. Grant the Key Vault Secrets Officer role to the managed identity. The runtime needs read and write access to create and manage keys:

   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"
   

4. Set the storage type and Key Vault URI:

   For system-assigned identity:

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

   For user-assigned identity, also set the client ID:

   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>"
   

5. Trigger key creation by listing keys:

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

Manage access keys

Regardless of backend, use the following commands to list, create, and delete access keys:

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

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

# Create or overwrite a custom host key
az containerapp function keys set \
  --resource-group "<RESOURCE_GROUP>" \
  --name "<FUNCTIONS_APP_NAME>" \
  --key-name "MyCustomKey" \
  --key-value "<YOUR_KEY_VALUE>" \
  --key-type hostKey

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

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

Call a function with an access key

Pass the key as a query parameter or request header.

# 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>"

Related content

• Functions secrets overview
• Store app-level secrets
• Manage secrets in Azure Container Apps
• Manage Functions keys
• Managed identities in Container Apps
• Azure Functions on Azure Container Apps overview