How to store application secrets on Azure

Why this matters

Application secrets are the values that let your code open a database, call a payment API, or sign a token. They end up in app settings, config files, container images, and CI variables. Each copy is another place to leak and another place to update when the value changes. Azure Key Vault gives you one store for those values, with access control, versioning, and a record of who read them.

Managed identities are the part that makes this practical. An App Service, Function, Container App, or AKS workload can get an identity in Microsoft Entra ID. You grant that identity read access to a vault. The app fetches the secret at run time. No password or client secret sits in your deployment pipeline.

Keep the scope tight. A vault per environment and per application boundary is easier to reason about than one shared vault. When a secret leaks, you rotate it and revoke one identity instead of hunting through every app. This guide covers secret values, not cryptographic keys. Key management has its own rules.

Before you start

Write down the secrets the app needs. Group them by environment and by the system they talk to. Include connection strings, API keys, signing secrets, and webhook secrets. Note which team owns each one and what breaks if it changes. This list becomes your rotation plan.

Decide the permission model before you create the first secret. Azure Key Vault supports vault access policies and Azure RBAC. Pick Azure RBAC for new vaults unless you have a reason to stay on access policies. RBAC lets you grant a role at the vault, resource group, or individual secret level. It also keeps permissions in the same model as the rest of Azure.

Plan the network path. If the app runs in Azure and the vault is private, use a private endpoint and a private DNS zone. If the app runs outside Azure, decide whether a public endpoint with firewall rules is acceptable or whether you need a site-to-site path. Do not open the vault to all networks as a shortcut.

Check soft delete and purge protection. Soft delete keeps a deleted vault or secret for a recovery window. Purge protection stops anyone, including an admin, from permanently deleting the vault before that window ends. Turn both on for production vaults. They are hard to add after an incident.

How to do it

The flow is the same for a web app, a function, or a container. Create the vault, set the permission model, create an identity for the workload, grant read access, add the secret, and point the app at it. The steps below walk through that path with Azure RBAC and a system-assigned managed identity.

Use a versionless secret identifier in app configuration. When you add a new version, the same identifier points to the latest value. That keeps deployments from pinning an old secret. If you need a canary, pin the version in a staging slot, test, then switch the slot.

Treat the vault as a dependency. If the vault is unreachable or the identity is wrong, the app should fail fast at startup with a clear error. Do not fall back to a hardcoded secret. A fallback hides the problem and trains people to keep a copy in code.

Rotate on a schedule and on demand. Add a new version, update the downstream system if it must accept the new value, then let the app pick it up. Keep the old version enabled until you confirm the new one works, then disable it. Do not delete versions right away.

1. Inventory the secrets and owners. List every secret the app reads, its environment, and the person who owns rotation. Mark the ones that can be replaced without a vendor change. This list drives the rest of the work.
2. Create a vault per environment. Put development, staging, and production in separate vaults with separate access. Use a naming pattern that includes the app, environment, and region. Keep the resource group and subscription boundaries clear.
3. Set the vault to Azure RBAC. Open the vault in the Azure portal, go to Access configuration, and choose Azure role-based access control. Do this before you add secrets so you do not need to migrate permissions later. Check that your own account has Key Vault Secrets Officer or an equivalent role.
4. Turn on soft delete and purge protection. On the vault properties, confirm soft delete is on and enable purge protection. Do this for every vault that holds production values. Record the recovery window in your runbook.
5. Create a managed identity for the app. In the App Service, Function, or Container App, turn on the system-assigned identity. For AKS, use a workload identity. Copy the object ID or client ID; you will use it in the role assignment.
6. Grant least privilege. Assign Key Vault Secrets User to the app identity at the narrowest scope that works. Use the vault scope for shared secrets or a single secret for a narrow need. Do not assign Owner, Contributor, or Key Vault Administrator to the app.
7. Add the secret and use a versionless reference. Use az keyvault secret set or the portal to add the name and value. Copy the secret identifier without the version segment. Put that identifier in App Configuration or the app setting that supports Key Vault references.
8. Read at startup and cache. Use the Azure SDK for your language with DefaultAzureCredential, or use a Key Vault reference in App Service. Read the value once at startup and keep it in memory. Add a refresh path that re-reads after rotation or on a restart.
9. Rotate with a new version. Add a new version of the secret, update the downstream system, and restart or refresh the app. Verify the new value works before you disable the old version. Keep an audit note of who rotated it and when.

How to check it worked

Run the app with the production identity and no secret in the environment. The app should start and reach the database or API. If it fails, read the error: a 403 means the role assignment is missing or too narrow; a 404 means the secret name or vault name is wrong.

Use az keyvault secret show with your own account to confirm the secret exists and has the version you expect. Then try the same command with the app identity, if you have a way to run as that identity. The app identity should read the secret but should not list all secrets.

Test rotation. Add a test version, force the app to refresh, and check the app logs for the new version or a successful connection. Disable the test version and confirm the app still works on the previous one. This proves the rollback path.

Check the deployment output and the app settings. No secret value should appear there. Also check CI logs and container image layers. A secret pasted into a build arg can survive in the image history.

Mistakes to avoid

Putting the secret in app settings and calling it done. A Key Vault reference is not a secret in the app setting; it is a pointer. If the value itself sits in the setting, you still have sprawl. Giving the app broad roles is another common mistake. Key Vault Secrets User is enough to read secret values. Key Vault Contributor can manage the vault, and Owner can change access. An app that only needs one secret should not be able to read every secret in the subscription.

Mixing access policies and RBAC makes it hard to answer who can read a secret. Pick one model and use it across the vault. If you inherit an old vault, document the exception and plan the move. Skipping rotation because it is hard creates secrets that never change. Build the rotation runbook before you need it. Test it in staging.

Using the production vault for local development hands out production read access for convenience. Developers should use a dev vault and their own identity, or a short-lived dev secret. Pinning a secret version in production blocks rotation until you redeploy. Use a versionless identifier unless you have a specific canary reason.

If you want an outside read on the identity and access side, Cloudverg's Cloud security review at $6,500/month is one option. It is a read-only review of up to five cloud accounts or subscriptions with a ranked fix list.

Frequently asked questions