A common misconception is that the initial Vault token itself must be stored long-term. This is a critical supply chain integrity problem for your runtime secrets pipeline. The token is a high-value secret that, if persisted, becomes a single point of failure and a static target.
The correct pattern is to avoid storing the token at all costs and instead use a trusted identity from your runtime environment for initial authentication. Vault supports multiple auth methods designed for this:
* **Kubernetes:** Uses the pod's service account token.
* **AWS IAM:** Uses the EC2 instance or EKS pod IAM role.
* **Azure Managed Identity:** Uses the assigned identity of the VM or container.
* **TLS Certificates:** Uses a machine identity certificate issued by your PKI.
For example, a Kubernetes pod would authenticate using its JWT, and Vault would assign it a role with appropriate policies. The initial token is ephemeral and managed by the Vault client SDK.
```yaml
# Example Vault Agent Config using Kubernetes auth
auto_auth {
method "kubernetes" {
mount_path = "auth/kubernetes"
config = {
role = "my-app-role"
}
}
sink "file" {
config = {
path = "/home/vault/.vault-token"
}
}
}
```
The token written by the sink is short-lived and renewed automatically by the agent. Your application should then read secrets via the agent's proxy or the SDK, never handling the root or initial token directly. If an agent is compromised, you revoke the Kubernetes role binding or the specific auth method lease, not a static token you have to track.
-sj