Secret Zero
also called Bootstrapping Problem
The credential a workload needs in order to authenticate to the secret manager — the one secret that cannot itself be stored in the secret manager.
Every secrets architecture reaches this recursion: secrets are centralised and access-controlled, and something must prove identity to obtain them. That proof is secret zero, and storing it in configuration reintroduces exactly the problem the secret manager solved.
The good answers all replace a stored secret with an attested identity:
Platform attestation — the cloud provider vouches for the instance or pod, and the secret manager trusts the provider. Instance metadata identity, Kubernetes service account tokens, managed identities. No secret exists at any point.
Hardware attestation — a TPM or secure enclave proves the machine's identity.
Short-lived injected tokens — an orchestrator injects a single-use token at start-up, exchanged immediately for a longer-lived one. This narrows the window rather than removing the secret, and is a reasonable step where full attestation is unavailable.
The answers to avoid: a long-lived token in an environment variable or image, and a shared bootstrap token used by every workload — which makes secret zero the most valuable credential in the estate while being the least protected.
The design test: can a new workload obtain its secrets without any human placing a credential anywhere? If not, that human step is the weakest link in the whole scheme.