HashiCorp Vault

Overview

HashiCorp Vault is a service that stores secrets, issues short-lived credentials and offers encryption as a service. A secret is anything that proves identity or unlocks access: a database password, an API token, a certificate, an encryption key. Vault keeps these in one audited place, hands them out only to authenticated and authorized callers and can make many of them expire quickly.

Data teams use Vault so that pipelines, notebooks and model services never carry long-lived passwords. A training job asks Vault for a database login that lasts an hour. A de-identification job asks Vault to encrypt a column without ever holding the key. This page explains how Vault works, shows examples and describes its role around tabular foundation models. Related pages: Thales, Spark UDF de-identification, PostgreSQL, Amazon RDS, Kubernetes and Terraform.

What it is

Vault is a server with an API. Clients (people, applications, pipelines) talk to it over HTTPS. Behind the API sits an encrypted storage backend. Vault itself is "sealed" when it starts: the data is encrypted and nobody can read it until the service is unsealed with the right key shares.

The core capabilities

• Secrets storage. A key-value store with versioning, so you can keep and roll back values.
• Dynamic secrets. Vault creates credentials on demand for databases, cloud accounts and other systems, and revokes them when the lease ends.
• Encryption as a service. A "transit" engine encrypts and decrypts data you send it, without storing that data.
• PKI. Vault can act as an internal certificate authority and issue short-lived certificates.
• Identity and authentication. Many login methods: tokens, cloud identities, Kubernetes service accounts, certificates, LDAP and more.
• Policy. Fine-grained rules say which identity can read, write or list which path.
• Audit. Every request and response (with sensitive values hashed) is written to audit devices.

The problem it solves

Without a secrets service, passwords get copied into config files, environment variables, chat messages and notebooks. They live for years and are shared by many people. When someone leaves, nobody knows what to change. Vault replaces this with identity-based, time-limited access and a log of every use.

Editions and forms

Vault has an open source core and commercial editions with extra features such as replication, namespaces and integration with hardware security modules. It can run self-hosted or be consumed as a managed service. Feature sets differ by edition, so check the documentation for your version.

Where it came from

Vault was created by a company that also made infrastructure tools such as Terraform, Consul and Nomad. It was first released in the mid-2010s as an answer to a common problem in cloud systems: how do many short-lived machines and containers get secrets safely?

Key ideas behind the design

• Secrets should be dynamic. The best password is one that exists for minutes.
• Identity beats network location. Trust a workload because of who it proves it is, not because of its IP address.
• Everything is a path. Secrets engines and auth methods are mounted at paths, and policies are written against paths.
• Seal and unseal. The master key is split using Shamir's secret sharing, so no single person can unlock the service.
• Audit everything. Logs are not optional.

Mathematical roots

Shamir's secret sharing, from the late 1970s, splits a secret into shares so that any threshold number can rebuild it, while fewer reveal nothing. Vault's unseal process uses this. Auto-unseal later allowed another trusted key service to handle the unseal step, which reduced manual work.

Evolution

Over time Vault added Kubernetes integration, cloud auth methods, a transit engine, namespaces for multi-tenant use, and agents that fetch and renew secrets on behalf of applications. The pattern of sidecar or agent injection became popular on container platforms.

How it works

Think of a hotel front desk. You arrive and show your ID (authentication). The desk checks the booking (policy). You get a key card for your room that works only for your stay (a lease). Each card use is logged. When you check out, the card stops working. Vault is that desk for software.

Step 1: Start sealed, then unseal

At start, Vault knows where its encrypted data is but cannot decrypt it. An operator provides enough key shares, or an auto-unseal mechanism provides the key, to decrypt the master key and open the service.

Step 2: Authenticate

A client proves its identity using an auth method. A person might use single sign-on. A pod on Kubernetes might present its service account token. A virtual machine might present a cloud identity document. Vault verifies it and issues a token with attached policies.

Step 3: Policies decide what the token can do

A policy is a short text file of paths and capabilities. For example, allow read on secret/data/analytics/* and nothing else. Tokens get policies by role. Least privilege is the goal.

Step 4: Request a secret

The client sends a request to a path. If the policy allows, Vault returns the secret. For static key-value secrets, it returns the stored value. For dynamic secrets, it contacts the target system, creates a new credential and returns it with a lease.

Step 5: Leases and renewal

A lease is a promise that the secret is valid for a set time. The client can renew it, within limits, or let it expire. When the lease ends or is revoked, Vault removes the credential from the target system.

Step 6: Use encryption as a service

With the transit engine, the client sends plaintext to Vault with a key name. Vault encrypts it and returns ciphertext. The key never leaves Vault. This is like handing a letter to a trusted courier who seals it in a safe you cannot open, and gives you back a receipt.

Step 7: Audit

Each request is logged with the identity, path, time and outcome. Values are hashed in logs, so the log can prove what was requested without exposing secrets.

Step 8: Rotate and revoke

Operators can rotate keys, revoke tokens and leases by prefix, and rotate the root of the system. Revoking all leases for a compromised role is one command.

A closer look at dynamic database credentials

1. A job asks for credentials from the database role report-reader.
2. Vault connects to the database with its own admin account.
3. Vault runs a statement that creates a user with a random name and password and grants read-only rights.
4. Vault returns the user and password with a one-hour lease.
5. After an hour, Vault drops the user.

If the credential leaks, it is useless after the lease ends. If the job misbehaves, an operator revokes the lease at once. This works with databases such as PostgreSQL and managed forms such as Amazon RDS.

A closer look at transit encryption

The transit engine supports encrypt, decrypt, rewrap, sign, verify, hash and random byte generation. Keys are versioned. When you rotate a key, new data uses the new version, and old ciphertext can still be decrypted. The rewrap call updates old ciphertext to the latest version without exposing plaintext to the caller. Some key types allow convergent encryption, which gives the same output for the same input and context, enabling lookups and joins on encrypted values.

Auth methods compared

Typical secrets engines

• KV. Static secrets with versions.
• Database. Dynamic credentials for several database types.
• Cloud. Dynamic cloud access keys or tokens.
• Transit. Encryption, signing and hashing as a service.
• PKI. Internal certificate authority.
• SSH. Signed SSH certificates or one-time passwords.
• Transform (commercial). Format-preserving encryption and tokenization in suitable editions.

Designing paths and roles

A clear path layout saves pain later. One common layout:

secret/data/<team>/<app>/<env>/...
database/creds/<app>-<access-level>
transit/keys/<domain>-<column-or-purpose>

Roles then map to teams and environments. A policy for the analytics team in staging touches only secret/data/analytics/*/staging/*. This makes reviews easy: a reviewer can read a path and know what it covers.

Failure scenarios and responses

Migrating from static secrets

1. Inventory where secrets live today: code, config, notebooks, CI variables.
2. Move the highest-risk ones first, such as production database passwords.
3. Switch the application to fetch from Vault via an agent.
4. Rotate the old secret and delete copies.
5. Replace static database accounts with dynamic roles.
6. Add scanning to block new secrets in repositories.

Questions to settle before rollout

• Who owns the Vault service and who is on call for it?
• What is the root of trust for unsealing?
• How are policies reviewed and deployed?
• Where do audit logs go, and who watches them?
• What is the plan if Vault is unreachable at 3 a.m.?

Monitoring Vault itself

Run Vault like any critical service and watch a few signals.

• Request rate and latency. A sudden rise may mean a runaway job or an attack.
• Token and lease counts. Rapid growth often points to a client that never revokes.
• Seal status. An unexpected seal event needs immediate attention.
• Storage health. Disk space and replication lag on the storage backend.
• Authentication failures. Bursts of failed logins suggest guessing.

A short rollout checklist

• [ ] Highly available cluster in at least three zones.
• [ ] Auto-unseal configured with a protected root key.
• [ ] Root token revoked after initial setup.
• [ ] Policies and mounts defined as code.
• [ ] One role per workload, with least privilege.
• [ ] Audit logs shipped to a separate system.
• [ ] Snapshot schedule and a tested restore.
• [ ] Runbook for outage and for suspected compromise.

Key concepts and terms

A worked example

This example shows a data pipeline using Vault for database credentials and column encryption. Hosts and names are fake.

Policy

# analytics-pipeline policy
path "database/creds/report-reader" {
  capabilities = ["read"]
}

path "transit/encrypt/customer-email" {
  capabilities = ["update"]
}

path "transit/decrypt/customer-email" {
  capabilities = []   # this pipeline may encrypt but never decrypt
}

path "secret/data/analytics/*" {
  capabilities = ["read"]
}

The pipeline can obtain a read-only database login and encrypt emails. It cannot decrypt them. A different, tightly controlled role has decrypt rights.

Command line steps

# 1. Point to the server (fake host)
export VAULT_ADDR="https://vault.example.internal:8200"

# 2. Log in using a method suited to the workload
vault login -method=jwt role=analytics-pipeline jwt="$WORKLOAD_TOKEN"

# 3. Get a short-lived database credential
vault read database/creds/report-reader

# 4. Encrypt a value with the transit engine
vault write transit/encrypt/customer-email \
  plaintext=$(echo -n "person@example.com" | base64)

The result of step 4 is a ciphertext string with a version prefix, such as vault:v1:.... Store that string in the table.

Python sketch

import base64
import hvac

client = hvac.Client(url="https://vault.example.internal:8200")
client.auth.jwt.jwt_login(role="analytics-pipeline", jwt=WORKLOAD_TOKEN)

creds = client.secrets.database.generate_credentials(name="report-reader")
db_user = creds["data"]["username"]
db_pass = creds["data"]["password"]
lease_id = creds["lease_id"]

def encrypt_many(values):
    batch = [
        {"plaintext": base64.b64encode(v.encode()).decode()}
        for v in values
    ]
    resp = client.write(
        "transit/encrypt/customer-email",
        batch_input=batch,
    )
    return [item["ciphertext"] for item in resp["data"]["batch_results"]]

The function uses the batch form of the encrypt call. Transit supports batch input, so you can send many values per request. Check your client library version for exact method names.

A numeric view of lease value

Suppose a static database password is shared by 30 people and used for two years. The window of exposure is 730 days across 30 holders. Suppose instead each job gets a credential valid for one hour. Even with 100 jobs per day, each credential exists for 1/24 of a day and is known to one job. The exposure window per credential shrinks by a factor of more than 17,000, and attribution is exact: the audit log names the job.

Rotating a transit key

vault write -f transit/keys/customer-email/rotate
vault write transit/rewrap/customer-email ciphertext="vault:v1:..."

After rotation, new encryptions use version 2. The rewrap call upgrades an old ciphertext to the new version without showing plaintext to the caller.

Strengths and limitations

Strengths

• Dynamic, short-lived credentials reduce the value of any leak.
• Central policy and audit give clear control.
• Encryption as a service keeps keys away from applications.
• Many auth methods fit cloud, container and on-premises setups.
• Open ecosystem. Agents, libraries and infrastructure-as-code support are widely available.
• Multi-tenant features such as namespaces in suitable editions.
• Strong community knowledge. Many teams have run it before.

Limitations

• Operational burden. Vault is critical infrastructure. It needs high availability, backups, upgrades and careful unseal handling.
• Single point of dependency. If Vault is down, applications that need fresh secrets can fail. Caching and sensible lease lengths help.
• Learning curve. Policies, paths and auth setups take time to learn.
• Throughput limits. Per-row transit calls on huge tables are slow. Batching and local data keys are needed.
• Not a database for data. It stores small secrets, not bulk data.
• Root of trust still matters. Auto-unseal and root keys depend on another trusted component, often an HSM or cloud key service.
• Edition differences. Some features are only in commercial editions.

How it compares with alternatives

Vault is often combined with others. For example, an HSM holds the root key, Vault serves applications, and cloud workload identity authenticates the workloads.

Role in tabular foundation models

Vault is not a model tool. It is part of the plumbing that lets model work happen safely on real tables. Tabular foundation models learn from raw tables: rows, columns, mixed types and missing values, often with no column names. They are pre-trained on synthetic or real tables and use in-context learning at inference time. See /model/architecture and /model/research. Here is how Vault relates.

Access to source tables

Training and evaluation jobs read from databases and lakes. Vault gives them short-lived logins to systems such as PostgreSQL, Snowflake or object storage. When a job ends, the credentials expire. This matters most for continual learning, where jobs run repeatedly and a leaked long-lived password would be exposed for months.

Column-level protection

Using the transit engine, a pipeline can encrypt sensitive columns before tables are stored for modelling. Deterministic (convergent) encryption keeps equality, which lets a model use an encrypted category or join key. Random encryption hides the column fully. The choice decides how much signal a model can use.

Pairing with de-identification

For bulk jobs, per-row calls are too slow. A common pattern is to fetch a data key or a keyed-hash secret once, then apply it inside Spark UDF de-identification. Vault holds the root secret, and Spark does the heavy lifting.

Protecting inference services

A model served behind an API needs credentials for logging, feature stores and databases. Vault supplies these at start and renews them. If the service imputes missing values, detects anomalies or classifies rows by sector or meaning, its outputs may be stored. Those outputs can be encrypted before storage using the same service.

Keeping in-context data safe

With in-context learning, the labelled rows that act as examples are sent to the model at prediction time. These rows may be sensitive. Vault does not change how the model reads them, but it controls who can get the credentials to call the service and which keys protect cached or logged copies.

Model artifacts and registries

Weights, config files and registry credentials are secrets too. Experiment trackers such as MLflow need storage credentials. Vault can issue them dynamically so that no notebook holds a permanent key.

Anomaly detection on access logs

Vault audit logs are tabular data: time, identity, path, outcome, client address. A tabular model can look for unusual access patterns, such as a role reading far more secrets than usual. This closes the loop between security and modelling.

A realistic flow

1. A scheduler starts a training job in Kubernetes.
2. The job authenticates to Vault with its service account.
3. Vault returns a database login and a storage credential valid for two hours.
4. The job reads de-identified tables, trains or adapts the model and writes results.
5. Credentials expire. Audit logs record all of it.

This is a pattern, not a claim that any product comes with this exact integration. Results of such models can be compared on /model/benchmarks.

Practical guidance and best practices

Plan for high availability

Run several nodes with integrated storage or another supported backend. Spread them across failure zones. Test failover. Treat Vault as tier-zero infrastructure.

Use auto-unseal with a trusted root

Manual unseal is safe but slow after restarts. Auto-unseal using a cloud key service or an HSM is common. Protect that root key carefully.

Write least-privilege policies

Give each workload its own role and its own policy. Avoid broad wildcards. Review policies in code review, like any other code.

Prefer dynamic secrets

Where the target system supports it, use dynamic secrets instead of static ones. Set lease times as short as the workload can tolerate.

Use workload identity for login

Let a pod or a virtual machine log in using its platform identity. Avoid storing a Vault token in a config file, since that only moves the problem.

Use agents or sidecars

An agent can authenticate, cache and renew secrets, and write them to a memory-backed file. Applications then need no Vault client code.

Batch transit calls

For columns with many values, send batches. For very large tables, consider generating a data key and encrypting locally, or use keyed hashing.

Separate encrypt and decrypt rights

Many pipelines only need to encrypt. Give decrypt to a small, audited set of roles.

Manage Vault as code

Use Terraform or similar to define mounts, policies and roles. This makes changes reviewable and repeatable.

Ship audit logs off the box

Send them to a separate system with its own access control. Alert on failed logins, policy changes and large reads.

Rehearse recovery

Practice restoring from a snapshot and unsealing in a clean environment. Document the break-glass procedure for root tokens and keep that token unused.

Keep versions current

Security fixes matter for a service like this. Track releases and plan upgrades.

Common mistakes

• Using the root token for daily work. Root tokens should be rare and revoked after setup.
• Writing broad policies. A wildcard on secret/* defeats the model.
• Long lease times. A thirty-day lease for a dynamic credential is little better than a static password.
• Storing the Vault token in a file next to the app. That recreates the original problem.
• Ignoring audit logs. Logs that nobody reads provide no protection.
• No tested backup. Snapshots that were never restored are only hope.
• Single node in production. A single node is a single point of failure.
• Per-row transit calls on big tables. This creates latency and load. Batch or use local data keys.
• Mixing environments. Keep development, staging and production separate, with their own policies and keys.
• Forgetting to revoke on departure. Remove access for people and retire roles for decommissioned services.
• Treating Vault as a general database. It is built for small secrets.
• Not planning for outage. Applications should handle temporary unavailability with cached secrets and retries.

Frequently asked questions

What is HashiCorp Vault used for?

Vault is used to store and distribute secrets such as passwords, tokens and certificates, to generate short-lived credentials for databases and cloud accounts, and to encrypt data through an API without exposing keys. It also records every access in an audit log.

What is a dynamic secret?

A dynamic secret is a credential that Vault creates when asked and removes when its lease ends. For example, Vault can create a database user with read-only rights that lasts one hour. If it leaks, it expires soon. Each credential is unique, so the audit log shows exactly which client used it.

What does sealed mean?

A sealed Vault has its data encrypted and cannot serve requests. At start, Vault must be unsealed by providing enough key shares or by using an auto-unseal mechanism backed by another trusted key service. Sealing again, for example in an emergency, makes all secrets inaccessible until unsealed.

What is the transit engine?

The transit engine provides encryption as a service. A client sends data and a key name, and Vault returns ciphertext. The key never leaves Vault. It also supports decrypt, rewrap, sign, verify and hashing. Keys are versioned, so rotation is smooth.

Can Vault encrypt a whole database column?

Yes, but with care. You can encrypt each value through the transit engine and store the ciphertext in the column. For large tables, use batch requests or fetch a data key and encrypt locally, because one network call per row is slow. Remember that random encryption blocks filtering and joins on that column.

Is Vault a replacement for a hardware security module?

No. A hardware security module is a device that holds keys in tamper-resistant hardware. Vault is a software service for secrets and encryption. They are often used together, with the hardware module protecting the root or unseal key. See Thales for the hardware-oriented side.

How does Vault help machine learning pipelines?

It gives training and inference jobs short-lived credentials for databases, storage and registries, so no notebook or script holds a permanent password. It can also encrypt sensitive columns and log every access. This reduces risk when models are trained or updated repeatedly on real tables.

Do tabular foundation models need special handling in Vault?

Not in Vault itself. The models read rows and columns like other data consumers. What matters is that credentials are short-lived, sensitive columns are protected in a way that keeps the signal you need and logs show who accessed what. Choose deterministic or random protection per column based on whether the model needs equality information.

What happens if Vault goes down?

Applications that already hold valid secrets keep working until their leases expire, but new requests fail. For this reason, run Vault in a highly available setup, cache secrets in agents where appropriate and design applications to retry. Test an outage before it happens.

How are secrets kept out of source code?

Applications authenticate to Vault with their platform identity and fetch secrets at run time, or an agent writes them to a memory-backed location. The code contains only the Vault address and role name, not the secret. Scanning tools in the build pipeline can check that no secrets are committed.

Glossary

• Agent: A helper process that logs in to Vault and fetches secrets for an application.
• Audit device: A destination where Vault writes its request log.
• Auth method: A way to prove identity to Vault.
• Auto-unseal: Using another trusted service to unseal Vault automatically.
• Capability: An allowed action on a path, such as read or update.
• Convergent encryption: Encryption that gives the same output for the same input and context.
• Data key: A key used to encrypt data, often wrapped by a higher key.
• Dynamic secret: A credential created on demand with a lease.
• KV engine: Key-value storage for static secrets.
• Lease: The time during which a secret or token is valid.
• Namespace: An isolated area inside one Vault deployment.
• Policy: A rule set describing what a token may do.
• Response wrapping: Delivering a secret through a single-use token.
• Rewrap: Updating ciphertext to a newer key version without exposing plaintext.
• Role: A named configuration tying an identity to policies or credential types.
• Seal: The locked state of Vault.
• Secrets engine: A plug-in that stores or generates secrets.
• Shamir's secret sharing: A scheme that splits a secret into shares.
• Token: A credential issued by Vault.
• Transit: The encryption-as-a-service engine.
• Unseal: Opening a sealed Vault.

Summary

HashiCorp Vault is a secrets and encryption service. It authenticates callers, applies path-based policy, hands out static or dynamic secrets with leases, offers encryption through the transit engine and logs every action. Its strongest idea is that credentials should be short-lived and tied to identity. Around tabular foundation models, Vault supplies safe access to source tables, protects sensitive columns, guards model artifacts and registries, and produces audit data that can itself be analysed. It needs real operational care: high availability, tested recovery, least-privilege policies and batching for bulk encryption. Combined with hardware-backed key management, de-identification jobs and governed storage, it forms a solid base for working with real tables. For the model side, see /model/research, /model/architecture and /model/benchmarks.

Related

It belongs to Data protection in my stack, under Data engineering and lakehouse. Others in the same group: