What is HashiCorp Vault?

If you’ve heard about HashiCorp Vault but aren’t sure what it is or why you’d use it, this article is for you. It’s the first part of a series that goes from concept to deployment and day-to-day use. Here we focus on the basics: what Vault is, what problem it solves, and how it’s designed to work.

What is HashiCorp Vault?

HashiCorp Vault is a tool for managing secrets – passwords, API keys, certificates, encryption keys – in a central place. It’s not a password manager for end users and it’s not “a file you encrypt with a password.” It’s a service (a server with an API) that stores secrets, controls who can access them, logs that access, and can generate or rotate secrets on demand.

The core idea: instead of scattering secrets across config files, environment variables, and shared docs, you put them in Vault. Applications and people then ask Vault for the secrets they need, after proving who they are. Vault decides, based on policies, what each identity is allowed to see or do.

What Problem Does It Solve?

Typical pain points Vault addresses:

• Secrets in repos – Accidentally committing a key or password, or juggling separate “secrets” repos that are hard to keep in sync.
• Secrets in config or env – Copy-pasting the same credentials into many servers or containers; no single place to rotate them.
• No clear “who can see what” – Shared spreadsheets or files where access is all-or-nothing and not audited.
• Manual rotation – Changing a password or key means updating many systems by hand and hoping nothing breaks.

Vault gives you one system that can store secrets, control access (via policies and auth methods), audit who read or used what, and generate or rotate secrets (e.g. short-lived DB credentials, PKI certificates) so you don’t have to do it manually everywhere.

How Is It Designed to Work?

Server, not a library

Vault runs as a server (or cluster). You deploy it, unseal it, and configure it. Clients – whether humans with the Vault CLI, applications using the API, or CI/CD – talk to that server over HTTP(S). So “Vault” in practice usually means “the Vault service” plus the vault CLI and/or API clients (e.g. hvac in Python).

Init and unseal

When you first start Vault, it’s sealed: the stored data is encrypted and no one can read it. You run init once (you get unseal keys and a root token) and then unseal the server so it can use its storage. After a restart, you have to unseal again (manually or via a controlled process). This is by design: the server can run without holding the keys to decrypt its own data until an operator unseals it.

Auth methods and policies

To get a secret from Vault, you first authenticate. Vault supports several auth methods: tokens, AppRole (common in CI), OIDC/LDAP for humans, etc. After auth you get a token (or similar) that represents your identity. Policies attached to that identity define what paths it can read or write. So “can this app read secret/myapp/config?” is answered by the policy for the token the app uses.

Secrets engines

Secrets are organised by secrets engines. The one you’ll see most is KV (key-value): you write and read key-value secrets at paths like secret/myapp/db. Other engines do more: PKI for certificates, database for dynamic DB credentials, transit for encryption-as-a-service, and so on. Each engine is enabled at a path (e.g. secret/, pki/) and you use that path in the API or CLI.

Typical flow

1. You deploy and init/unseal Vault (see part 2 in this series for one way to do that).
2. You enable engines (e.g. KV), configure auth (e.g. OIDC, AppRole), and write policies.
3. Users or apps authenticate, get a token, and request secrets from allowed paths.
4. Vault returns the secret (and logs the access). You rotate or revoke as needed.

Who Is It For?

Vault is aimed at operators and developers who need to manage secrets for many systems: multiple apps, databases, CI/CD, cloud APIs. It’s overkill for “one person, one machine, a few passwords” – but once you have several services, environments, or people, centralising and auditing access to secrets becomes valuable. The rest of this series assumes you’re in that situation: you want a Vault instance, maybe integrated with Ansible and a small CLI for daily use (part 2, part 3, part 4).

How It Fits With Other Tools

• Ansible Vault – Encrypts files with a password; great for keeping playbook variables secret, but the password is still “somewhere.” You can keep using Ansible Vault and still introduce HashiCorp Vault as the place where that password (and other secrets) live – see part 3.
• Cloud secret managers – AWS Secrets Manager, GCP Secret Manager, Azure Key Vault, etc. solve a similar problem in one cloud. Vault is provider-agnostic and can run on your own infra or in any cloud; you can also use both (e.g. Vault for app secrets, cloud IAM for cloud APIs).
• Password managers (1Password, etc.) – For human logins to apps and servers. Vault is for machine and app secrets and for dynamic secrets (short-lived credentials, certificates). They complement each other.

Summary

HashiCorp Vault is a central secrets service: store, access-control, audit, and rotation in one place. You run it as a server, unseal it, configure auth and policies, and then applications and users request only the secrets they’re allowed to have. The next parts of this series cover deploying Vault with Ansible, using it to supply your Ansible Vault password, and using a small CLI (vaultsh) for interactive Vault use.