This module puts a secret in a vault, makes every client prove who it is, then opens only the strictly necessary path. HashiCorp Vault is the implementation: it encrypts what you entrust to it, issues a token after a successful authentication, and answers only if a policy allows it. It is for people who already know the lifecycle of a secret and want to move from principle to practice, in three lessons that follow one another: Vault KV, authentication then policies.
What you will learn
- Decide whether a Vault is justified for your context, or whether a lighter tool is enough
- Place authentication, policies and secrets engines in Vault's access chain
- Understand why the three lessons follow the order store, authenticate, scope
- Spot what running the vault itself costs, and where the optional module details it
- Connect the module to the SOCLE-SEC-STO (in French) requirements on storage, scoped access and their traceability
Why does this module come after the lifecycle?
The previous module set out the eight-step lifecycle of a secret, the choice between a static, dynamic or federated-identity secret and the envelope encryption that protects the vault itself. It said where a secret must live at the storage step. This module builds that place: the vault, the front door (authentication) and the opening rule (the policy).
It comes before dynamic secrets for a mechanical reason. A dynamic secret is made on demand by Vault, but the client that asks for it goes through the same chain as a KV read: it authenticates, receives a token, and a policy decides which path is open. Without that chain, you could neither tell who to issue an ephemeral credential to, nor stop them from asking for one for production. The vault and its scoped access are therefore the common prerequisite for everything that follows.
What thread links the three lessons?
Each lesson answers a question, and the answer of one becomes the input of the next. The first fixes the paths under which the secrets live, the second has a token issued to a human or a machine, the third attaches to that token a policy that names those paths. The tree chosen in KV therefore determines the policies, and the policies attach to the authentication methods: the order is not decorative.
| Lesson | Question asked | What you produce |
|---|---|---|
| Vault KV | Where does the secret live, under which path? | A KV v2 mount, versioned secrets filed by application and by environment |
| Authentication | Who is asking? | A userpass account, an AppRole role, a short-lived token |
| Policies | What can this token do, and on which path? | An HCL policy loaded, attached and tested with an expected denial |
One optional lesson completes this module: Vault Transit, which encrypts data without ever entrusting the key to the application. It follows the same access chain, with a different engine.
When is Vault the right vault?
Vault is a powerful but complex tool, and the first decision is not technical: is there a need that justifies this complexity? It becomes relevant as soon as at least one of the following needs appears. The right column says what Vault brings that the rest of the market brings less well.
| Need | Why Vault excels |
|---|---|
| Dynamic secrets | Database, cloud and SSH credentials generated on demand with a TTL |
| Internal PKI | Built-in certificate authority, short-lived certificates (hours/days) |
| Application-level encryption | Transit: the application never has access to the encryption keys |
| Strong audit | Complete log of who accesses what, when, and for what reason |
| Multi-team | Isolation of secrets per team/environment with ACL policies |
| Rotation / revocation | Instant revocation, automatic rotation of credentials |
| Kubernetes integration | Native auth via ServiceAccount, secret injection |
| Identity federation | Unified authentication with OIDC, LDAP, cloud providers |
Conversely, some situations bring more complexity than value. For a small team, a lighter tool often does more good, because the operational cost of Vault outweighs the benefit. The table gives, for each situation, the simplest alternative to examine first.
| Situation | Simpler alternative |
|---|---|
| A few team secrets | Password manager (Bitwarden, 1Password) |
| Simple CI/CD secrets | GitLab/GitHub secret variables, AWS Secrets Manager |
| Team < 10 people, single environment | SOPS + Git, Infisical, Doppler |
| No dedicated ops budget | Managed solution (HCP Vault, Infisical Cloud) |
| Occasional need for certificates | Let's Encrypt, Certbot |
Between the two, the choice of solution depends on the profile. Vault and its fork OpenBao become the right choice as soon as multi-team use, an internal PKI or application-level encryption appear; the Enterprise edition is justified for namespaces, replication and strict compliance.
| Profile | Recommended solution | Why |
|---|---|---|
| Small team (< 10 devs) | Infisical, Doppler, SOPS | Less operational complexity |
| Startup / mid-size team | Vault CE or OpenBao | Good power/complexity ratio |
| Multi-team internal platform | Vault Enterprise or OpenBao | Namespaces, isolation |
| Kubernetes-first | External Secrets + (Vault or OpenBao) | Native integration |
| Internal PKI / mTLS | Vault CE or OpenBao | Complete PKI engine |
| Application-level encryption | Vault Transit | Keys never leave Vault |
| Strict compliance | Vault Enterprise | MFA, Sentinel, Control Groups |
| Pure open source required | OpenBao | MPL 2.0 licence |
What does it cost to run a vault?
Vault is not a simple safe: it is an infrastructure component whose outage or misconfiguration hits every application that depends on it. The table below is the real cost of Vault, the one that does not show up in a tutorial in dev mode. Each line is a recurring task to equip, not a box ticked once. Look first at initialization, unsealing and storage: they determine the ability to restart the service after an outage.
| Component | What you must manage |
|---|---|
| Initialization | Generate and secure the unseal keys |
| Unsealing | Unseal Vault after every restart (manual or auto-unseal) |
| Storage | Configure and maintain the backend (integrated Raft recommended) |
| High availability | Cluster of 3+ nodes for fault tolerance |
| Backups | Regular snapshots of the Raft storage |
| Key rotation | Periodic rotation of the master encryption key |
| Audit | Configure and monitor the audit devices (file, syslog, socket) |
| Monitoring | Prometheus metrics, alerts on auth failures and expirations |
| Policies | Write and maintain the ACLs for every team/application |
| TLS | Certificates for the Vault API (mandatory in production) |
These tasks are the subject of the last module of the course, which is optional: it targets the operator of the vault rather than whoever reads secrets from it. It covers the installation, the auto-unseal and recovery keys (which spare you the manual intervention after every restart) and running in production. It also holds three pages about choices: the CE and Enterprise editions, the BSL 1.1 licence adopted in August 2023 (internal use allowed, competing managed offering forbidden) and Vault vs OpenBao, the fork maintained by the Linux Foundation under the MPL 2.0 licence.
How does Vault protect a secret?
Vault chains several components that interact to secure your secrets. The diagram below follows the flow of access to a secret, from the client to the decrypted value. Two points deserve attention as you read it. Every request first goes through an auth method, which issues a token, then through a policy, which decides what that token can do; the secret is reached only after these two barriers. And nothing works until the barrier, the encryption layer, is unsealed.
The three lessons of the module occupy the three middle links: KV is a secrets engine, authentication is the auth method, policies are the ACL layer that separates them. The identity system deserves a word because it is often underestimated: Vault maintains entities that consolidate the different authentication methods.
- Entity: represents a single person or application
- Alias: links an entity to an auth method (alice via userpass and alice via OIDC make up the same entity)
- Group: gathers entities to apply common policies to them
This gives a unified view of access even if you mix several methods: userpass
for development, OIDC for employees, Kubernetes for pods. What remains is the
sealed state: Vault starts sealed and refuses every operation, because its
data is encrypted by a master key that is itself encrypted. The default
Shamir mode splits this key into N shares of which M are enough to rebuild
it; auto-unseal entrusts the key to an external service (KMS, Transit) to
avoid manual interventions.
Which secrets engines for which needs?
A secrets engine is a module that you enable on a given mount path and that defines how Vault handles secrets at that location. You enable only the engines you use, and each one is mounted on a distinct path that the policies control separately. Vault distinguishes two families: static secrets, which you deposit and which stay identical until you change them, with all the problems that brings, and dynamic secrets, generated on demand with a limited lifetime, then deleted by Vault when the lease expires.
Look first at the Family column: it says whether the engine stores a
fixed value (Static), makes a disposable one (Dynamic) or transforms
data without storing it (Encryption). The move from static to dynamic is the
real gain of Vault: Database, PKI, SSH and the cloud engines remove the
shared, permanent credential lying around in your configurations.
| Engine | Family | What it does in practice |
|---|---|---|
| KV v2 | Static | Your classic safe: store any secret with versioning (last 10 versions kept) |
| Transit | Encryption | Vault encrypts/decrypts your data without ever giving you the key. Your app sends plaintext, receives ciphertext. |
| Database | Dynamic | Creates a PostgreSQL/MySQL/MongoDB user on demand, deletes it automatically after expiry |
| PKI | Dynamic | Makes TLS certificates signed by your internal CA, with the lifetime you want (1 hour, 30 days...) |
| SSH | Dynamic | Signs SSH keys or generates OTP passwords to access your servers |
| AWS/Azure/GCP | Dynamic | Generates temporary cloud credentials (IAM user, service account...) |
| Cubbyhole | Static | Personal safe tied to your token, nobody else can access it, not even admins |
The second table approaches the problem from the other end: start from your
real need, and it points to the right engine. A reading rule helps you
decide quickly. If the secret is imposed from outside (API key of a
third-party provider), it is static in KV v2, and that is the subject of the
first lesson. As soon as Vault can create and destroy the credential
itself, prefer the matching dynamic engine, which eliminates the shared
password.
| Your need | Recommended engine | Why |
|---|---|---|
| Store third-party API keys | KV v2 | Static secrets imposed by the provider |
| Database access for your apps | Database | No more shared password, automatic rotation |
| Encrypt sensitive data (GDPR) | Transit | Your developers never have access to the keys |
| Internal TLS certificates (mTLS) | PKI | Short-lived certificates, easy revocation |
| SSH access to your servers | SSH | No more SSH keys lying around, audited access |
| Temporary AWS credentials | AWS | No more permanent access keys in configs |
How does a client prove its identity?
Before accessing a secret, a client must prove who it is, and the method depends on its nature. For a human, it is simple: a password or the company SSO. A machine cannot type a password: it proves its identity through its environment. The selection criterion is therefore the nature of whoever authenticates, and the right column describes the verification mechanism.
| Who authenticates | Recommended method | How it works |
|---|---|---|
| Developer locally | Userpass | Classic login/password, simple for tests |
| Employee in a company | OIDC or LDAP | SSO via Keycloak, Okta, Azure AD, or Active Directory |
| CI/CD pipeline | AppRole | role_id in a variable, secret_id generated on every run |
| Kubernetes pod | Kubernetes auth | ServiceAccount token verified by Vault |
| EC2/cloud VM instance | AWS/Azure/GCP auth | The cloud provider's machine identity |
| On-premises server | AppRole or TLS certs | Depending on your infrastructure |
The authentication lesson covers the two methods that depend on no third-party
infrastructure: userpass and AppRole, where the application receives a
role_id (its identity) and a secret_id (a disposable password). The
Kubernetes and cloud methods illustrate a broader concept, workload
identity: instead of distributing a secret, the machine proves who it is
through its environment. The course devotes a whole module to it, starting from
machine identity and the
identity broker.
One question remains that every disposable-secret mechanism raises: how do you
give the application the first secret, without it travelling in the
clear? This is the secret zero problem.
AppRole reduces it with response wrapping, where the secret_id is wrapped
in a single-use token that expires within minutes; the lesson puts it into
practice. Vault tokens also work on their own, but you have to create and
distribute them by hand: with 50 microservices, this becomes unmanageable, and
that is why you let applications authenticate themselves.
How does a policy limit access?
Once authenticated, what can the client do? That is the role of policies, which associate paths with capabilities, that is, allowed actions. The central mechanism is default deny: Vault grants only what is written, everything else is forbidden. In the example below, the team has full rights on the development secrets, read-only access to pre-production, and no access to production, since that path appears nowhere.
# Policy for the development teampath "secret/data/dev/*" { capabilities = ["create", "read", "update", "delete", "list"]}
# Read-only on staging (no changes in pre-prod)path "secret/data/staging/*" { capabilities = ["read", "list"]}
# No access to production: whatever is not explicitly# allowed is deniedThe final * covers everything that follows the prefix; the lesson on policies
details the eight capabilities, the rule that arbitrates between two
overlapping paths, and how to test a policy before handing it to a
pipeline. What to remember here: access is designed by business role and
by path, never by person, and an explicit deny is reserved for exceptions: it
acts only inside the rule that is retained, so a broad deny does not override
an access defined more precisely elsewhere.
Key points
- A vault is only worth something if a complete chain reaches it: authentication, token, policy, engine, encrypted storage
- The three lessons follow one another: KV fixes the paths, authentication issues the token, policies name the paths open to that token
- Vault is powerful but demanding: assess whether you have the resources to run it, or whether a lighter tool is enough
- Static or dynamic: KV v2 for what is imposed on you, a dynamic engine as soon as Vault can create and destroy the credential
- Default deny: a policy grants only what it names, access is designed by business role
- Identity system: consolidates the identities of several auth methods into one entity
- The vault protects itself too: sealing, auto-unseal, audit and backups are detailed in the optional operations module
- Evidence expected by SOCLE: secrets are in a vault, encrypted at rest, access is scoped to the strict minimum and traced (see SOCLE-SEC-STO (in French))
FAQ: frequently asked questions
These short answers cover the decision questions that come up most often before adopting Vault: the choice between the CE and Enterprise editions, the scope of the BSL licence, the positioning of the OpenBao alternative and how dynamic secrets work.
sudo apt install vault
vault version
vault server -dev, everything in memory, not secure). In production, configure a Raft backend and auto-unseal, then initialize with vault operator init. The guide details each step: Install Vault.