Designing a Maintenance Listener: My Break-Glass Door Into Vault
Why I Need a Break-Glass Option
If all Vault listeners require valid client certificates and my admin cert expires, I’m locked out. That’s secure, but it’s also dangerous if I don’t have a recovery path.
I don’t want to weaken security permanently. I want a break-glass mechanism that:
- is normally unused,
- is limited to
localhostor loopback, - and can be enabled only when I deliberately touch the config.
The Maintenance Listener Idea
Conceptually:
listener "tcp" {
address = "127.0.0.1:18200"
tls_disable = 1
}
Or a TLS listener without tls_require_and_verify_client_cert.
The idea:
- The normal listeners still enforce mTLS for everything (Vault API in test/prod).
- The maintenance listener is reachable only from localhost.
- I use it temporarily to:
- log in with root/admin token,
- re-issue admin client certificates,
- verify and fix PKI/roles.
Then I reload Vault, verify that mTLS works again, and remove or disable the maintenance listener.
Principles I Want to Follow
- No permanent “backdoor” from the internet.
- Break-glass access is:
- local only,
- explicit (config change + restart),
- documented in my own runbooks.
- After using it, I want a clear checklist:
- rotate admin certs,
- test mTLS,
- revert the listener config.