Use secrets in workloads
How apps, functions and container instances receive secrets from a vault when they start.
A workload never stores a secret's value in its own configuration. It stores a reference — which vault, which secret, under which name — and receives the value when its pod starts.
How delivery works
When a pod of a workload with secret references starts, an init container runs before the
application. It signs in as the workload's own managed identity, fetches the current value
of every referenced secret from the Secrets service, and writes them to a volume mounted at
/secrets. The volume lives in memory, so values are never written to disk. Only then does
the application container start.
The workload's identity must be allowed to read the vault, and every referenced secret must exist, not be deleted, and be enabled. If any of that fails, the init container fails and the pod does not start — see Troubleshooting.
By workload type
| Workload | Where you add references | How the application receives the values | Vault access granted for you |
|---|---|---|---|
| App Service | Configuration → Secrets | In the file /secrets/env.json — details |
No |
| Functions | The function's Configuration → Secrets | As environment variables named STSH_<NAME> — details |
No |
| Container instances | A container's environment variables in Components | As environment variables, in every container of the component — details | Yes, when you may grant it |
| Blueprint deploys | Created by the deploy | As the blueprint's components define | Yes, when you may grant it |
When values change
Values are fetched only when a pod starts. After you change or disable a secret, a running workload keeps what it fetched until its pods restart — redeploy or restart the workload to pick up the change.