HashiCorp Vault: secrets management & encryption

Why you need a dedicated secrets manager

Every service in a modern stack needs its own credentials: a database password here, an AWS key there, a TLS certificate somewhere else. By default those live wherever whoever wrote the deploy script put them - a .env file, a CI secret store, a Slack message from years back. Rotating any one of them means finding every place it's hardcoded, and revoking access after an incident means guessing which secrets that person or service could reach. Vault exists because most teams can't actually answer 'which secrets exist, who can read them, and when do they expire' without a system dedicated to tracking it. That's the gap Vault fills.

Vault: unified secrets management and encryption

Vault is HashiCorp's tool for storing, generating, and controlling access to secrets such as API keys, database credentials, certificates, and encryption keys. It exposes secrets through a unified API rather than scattering them across config files, environment variables, or ad-hoc vaults per team, and every read is access-controlled and written to an audit log.

Core capabilities of Vault

• ✓Secure secret storage: Vault encrypts key/value data before it touches disk, so gaining access to the raw storage backend isn't enough to read a secret. It can write to local disk, to Consul, or other supported backends.
• ✓Dynamic secrets: instead of storing a long-lived AWS or database password, Vault generates one on demand. When an app asks for S3 access, Vault mints a fresh AWS keypair with scoped permissions and revokes it automatically once the lease expires.
• ✓Encryption as a service: Vault can encrypt and decrypt data without ever storing it, so a team can push encryption logic into Vault instead of hand-rolling crypto inside an app that writes to a SQL database.
• ✓Leasing and renewal: every secret Vault hands out carries a lease. Clients renew it through a built-in API before it expires; if nobody renews it, Vault revokes it automatically.
• ✓Revocation, including bulk revocation: Vault can pull a single secret or an entire tree at once, every secret a specific user touched, or every secret of one type, which matters when locking things down after a breach.

What you can do with Vault

• •Stop hardcoding database passwords and API keys in app config and let services fetch them from Vault at runtime instead.
• •Hand out short-lived AWS credentials per request instead of a shared long-lived IAM key that never rotates.
• •Encrypt application data, such as fields going into a SQL database, by calling Vault's encryption API instead of managing your own crypto library.
• •Track exactly who read which secret and when, via Vault's audit log, for compliance or incident response.
• •Revoke every secret a compromised service or user could reach in one action after a security incident.

Running Vault locally

Running Vault locally, per the README, means building it from source for development rather than grabbing a packaged release: install Go, set GOPATH and GOBIN, then clone the hashicorp/vault repo outside your GOPATH (it uses Go Modules). Run `make bootstrap` once to pull build tooling, then `make dev` to compile a development binary into `bin/vault`. If you want the web UI baked in, run `make static-dist dev-ui` instead. Running the test suite (`make test`) requires Docker. The README doesn't document a packaged binary or OS-level package-manager install beyond that dev build path.

How applications consume secrets from Vault

An application talks to Vault over its API rather than reading secrets from a file: it authenticates, requests what it needs (say, S3 credentials), and Vault returns a value plus a lease it must renew through the built-in renew API before that lease runs out. For Go apps specifically, HashiCorp publishes github.com/hashicorp/vault/api as an importable client library; note that importing the main hashicorp/vault module itself is explicitly unsupported, only the api and sdk packages are meant to be pulled in. For other languages, the README points to a separate vault-examples repo and a hello-vault-go sample app for integration patterns; beyond that, this repo's README doesn't spell out language-specific usage.

Alternatives to HashiCorp Vault

Frequently asked questions about Vault

Who should try it — and who should skip

Teams running more than a handful of services that each need a database password, an API key, or a certificate are the ones who feel the pain Vault solves; once credentials are scattered across a dozen config files, a central store with leases and an audit trail pays for itself. A single small app with two or three secrets doesn't need this: dropping them in a properly-scoped secret store your cloud provider already offers, or even a well-guarded environment variable, is less operational overhead than standing up and maintaining a Vault cluster. If you're not ready to run and patch another stateful service, skip it until the number of secrets actually hurts.

Related repositories