Alright, so you've got Vault running, maybe in your k3s cluster. You know about secrets engines, but Cubbyhole always seems... weird.
Think of it as a tiny, temporary secret locker *for a single client token*. It's not for storing your database creds. The big use case? One-time credentials or secure data handoff.
Here's a real one: bootstrapping a service in your pod. Your init container gets a Vault token with limited permissions. It writes a more powerful, wrapped token into its *own* Cubbyhole. The main app container reads from that same Cubbyhole using the same token, unwraps it, and gets its real long-term token. The Cubbyhole data is destroyed when the init container's token expires.
```yaml
# init container writes wrapped secret to its cubbyhole
vault write cubbyhole/bootstrap token=$(vault token create -policy=app-policy -wrap-ttl=5m -field=wrapping_token)
# main app reads and unwraps
vault unwrap $(vault read -field=token cubbyhole/bootstrap)
```
The key: only the token that wrote it can read it. It's a secure way to pass data between two processes that share the same initial trust.
yaml all the things
That's the textbook example, sure. But you're glossing over the operational risk. You now have a more powerful, long-lived token floating in your main container's memory, derived from a bootstrap process that hinges on the security of that initial, short-lived token.
If your init container got compromised, the attacker could just as easily write a malicious wrapped token to the cubbyhole. The main container would blindly unwrap it. You've traded a static secret for a slightly more dynamic one, but the chain of trust is only as strong as that first token's issuance, which is often automated and poorly audited.
It's clever, I'll give you that. But it feels like solving a secret distribution problem by adding another layer of indirection, not actual isolation.
Trust but verify
Okay, that bootstrap example is the first time Cubbyhole has actually clicked for me, thanks. So it's like a secure pipe that only exists for the life of that one token.
But I'm trying to picture setting this up in, say, a GitHub Actions workflow. Would the "init container" step be the job that gets the initial Vault token, and then it uses the Cubbyhole to pass something to a later step? Since steps share the same workspace, is that even the right mental model, or is there a better fit for a CI/CD pipeline?
Learning by breaking
That bootstrap example is solid, but I'll give you the operational headache I ran into with it. The timing. If your main container takes a few extra seconds to spin up, the wrapped token in the cubbyhole can expire before it's read. I've had pods fail because the init container's short-lived token died a few seconds before the app's readiness probe passed.
It works, but you need to be really precise with those TTLs and container startup order.