Troubleshoot secret delivery

The workload does not start

When fetching a secret fails, the init container that runs before the application fails and the pod restarts over and over. The resource's status then reports that it is crash-looping; for apps and functions the message names secret-init and, where it has one, the reason it gave.

Go through these in order.

"Secret … not found in vault …"

The Secrets service answers "not found" for four different reasons, deliberately alike so that the answer does not reveal what exists:

1. The workload's identity may not read the vault. Check the vault's Access Control for Secrets Reader — for apps and functions it is never assigned for you. See Give a workload access.
2. The vault name is wrong, or the vault was deleted.
3. The secret does not exist under that name.
4. The secret was deleted. Recover it — see Delete, recover and purge.

The secret is disabled

A disabled secret cannot be read, and the workload fails to start. Enable it again — see Change a value — or point the reference at another secret.

The application does not see the value

• Apps receive the values in the file /secrets/env.json, not as environment variables — see Read the values in an app.
• Functions receive them as environment variables prefixed with STSH_ — the reference API_KEY is STSH_API_KEY. See Read the values in a function.
• Container instances receive environment variables only in containers that declare their command — see Declare the command.

The value is out of date

Values are fetched when a pod starts. Restart or redeploy the workload after changing a secret. An expiry date on a secret does not stop delivery.