Give a workload access to a vault

A workload reads its secrets as its own managed identity. That identity needs the Secrets Reader role on the vault — on the vault itself is enough, and grants nothing beyond it.

Assign Secrets Reader on the vault

1. Open the app, function namespace or container instance and copy the Principal ID from the Managed Identity card on its Overview. On a function namespace the card is shown only to people who may also read apps (apps/read); otherwise list the identities in its resource group with stsh identity list -g <resource-group> -o json and take its principalId.
2. Open the vault and its Access Control tab, and choose Add role assignment.
3. Paste the Principal ID into the search field — searching by name only looks at the first 20 managed identities — and pick the role Secrets Reader.
4. Choose Add assignment. The identity is listed as a Service principal, and the workload can read the vault from its next start.

More about workload identities: Managed identities.

Assigning roles needs rbac/members/write on the vault; vault Owners have it.

When it happens for you

Creating or changing a container instance whose containers reference a vault, and deploying a blueprint, assign Secrets Reader on the vault to the workload's identity automatically, using your own permissions. If you may not assign roles on that vault, the change is refused with:

This instance's identity could not be granted Secrets Reader on vault '<vault>': <status>. Only an owner of the vault can make that grant.

and a request for temporary Owner access is filed for you, which a vault owner can approve.

App Service and Functions do not assign it: grant Secrets Reader yourself before you save secret references, or the workload's pods will not start.

For functions the identity is the function namespace's: the grant lets every function in the namespace read the vault, not only the functions that reference it.