Secrets vault
Secrets Vault
A private vault for passwords and API keys, with access tokens for your apps.
What a secrets vault is
A secrets vault is one place for the passwords and API keys of your apps. Your apps read their passwords and keys from the vault instead of config files.
Each app gets a token that sees only its own secrets, and every read is in the audit log. A leaked token stops working the moment you revoke it.
We run the vault server and keep it updated. It unlocks itself after a restart.
Why ours
Its own server
Your secrets are on a server no other customer uses. It gets an address in your private network and a public one for HTTPS.
Encrypted
Every secret is encrypted on disk with AES-256-GCM, with a key of its own for each vault.
Scoped tokens
Give each app a token that sees only the secrets it needs. A token can also be limited to some addresses and to a lifetime.
Works with any language
Any app that can make an HTTPS request can read its secrets.
It grows with you
When the vault fills up with secrets or tokens, it moves to the next package by itself.
Secrets that change
A new value is stored as a new version, and the old one stays readable. Each secret keeps its last 10 versions.
A password or a token can get a new random value on a schedule you set. After each rotation the vault calls your webhook, signed with a secret from the vault settings, so your app hears about it. Rotation is for passwords and tokens you can change on the other side.
A secret can also expire on its own after the time you set.
Who read what
The audit log records every request: what was done, with which token and from which address. Values are never in it. The log is kept for 400 days.
To hand a password to a person, make a one-time link. The value can be read once with the link, then it is deleted. A link can have a passphrase, and three wrong tries delete the secret.
How to start
- Create a vault in the Cloud Panel and pick a package. It gets its own address and a root token.
- Add your secrets. Names can have folders, like prod/db/password.
- Make a token for each app or pipeline with only the secrets it needs.
Example usage
# the app reads its database password at start
curl -s https://acme-3f9a1c.vault.serverscamp.com/v1/secret/prod/db/password \
-H "X-Vault-Token: $VAULT_TOKEN" | jq -r .value
# a token with write access stores a new version
curl -s -X PUT https://acme-3f9a1c.vault.serverscamp.com/v1/secret/prod/db/password \
-H "X-Vault-Token: $VAULT_TOKEN" -d '{"value": "<new password>"}'Also in every vault
Values on demand
The panel lists names and settings. A value is read only when you open it.
Guessing slowed down
Guessing tokens from one address is slowed down.
New root token
A new root token stops the old one at once. Scoped tokens keep working.
Questions
How does my app read a secret?
With an HTTPS request to the vault address, its token in the X-Vault-Token header. The answer is JSON with the value.
What if a token leaks?
Revoke it in the panel. It stops working the moment you revoke it.
Can I get an older value back?
Yes. Older versions of a secret stay readable, up to the last 10.
Can my servers reach it over the private network?
Yes. The vault has an address in your private network next to its public one.
Are values in the audit log?
No. The log shows what was done, with which token and from which address. Values are never in it.
Do I need a network first?
Yes. A vault lives in a private network behind a router, the same way your servers do.