Vault
gunkanmaki.vault
A Docker Compose file for Vault alone, generated from the catalog and checked by the safety inspector. No account needed.
Secrets management server providing static and dynamic credentials, encryption as a service, PKI issuance and leasing, with pluggable authentication methods and policy-based access control.
Vault stores secrets behind an authenticated API and issues many of them dynamically: a database backend creates a short-lived user on request and revokes it when the lease expires, so long-lived credentials never sit in a configuration file. Authentication is pluggable — tokens, AppRole, OIDC, cloud identity — and access is granted by policies attached to the resulting identity rather than to a person or machine directly. A transit backend performs encryption and decryption without releasing key material, letting applications encrypt data they cannot decrypt on their own. The server starts sealed and serves nothing until unsealed with a quorum of key shares.
You know it worked when
- The status endpoint reports the server initialised and unsealed.
- A token authenticates and its policy restricts it to the intended paths.
- A static secret written to a key-value engine reads back correctly.
- A dynamic credential is issued with a lease and stops working once revoked.
- A restart leaves the server sealed, and unsealing restores access to the same data.
Known sharp edges
- The server starts sealed after every restart and serves nothing until unsealed, so a container restart without auto-unseal means manual intervention.
- Unseal key shares and the initial root token are displayed once at initialisation and cannot be recovered afterwards.
- Development mode holds everything in memory and unseals automatically, which makes it easy to build a working configuration that vanishes on restart.
- Dynamic credentials expire with their lease, so a consumer that does not renew loses access part-way through an operation rather than at a predictable point.