Deploy HashiCorp Vault on Ubuntu with Docker — the industry-standard secrets management platform for storing API keys, database credentials, TLS certificates, and generating dynamic secrets with fine-grained access control.
Grab the automated bash script from GitHub to follow along with the video.
wget https://raw.githubusercontent.com/mhmdali94/Docker/main/security/vault/vault-ubuntu.sh
chmod +x vault-ubuntu.sh
sudo bash vault-ubuntu.shThe script installs Docker and starts Vault in development mode on port 8200. In dev mode, Vault is pre-unsealed and uses an in-memory backend — ideal for learning and testing. The root token is printed in the logs.
wget https://raw.githubusercontent.com/mhmdali94/Docker/main/security/vault/vault-ubuntu.sh
chmod +x vault-ubuntu.sh
sudo bash vault-ubuntu.shOpen your browser and navigate to the Vault UI. Log in with the root token from the container logs:
http://<your-server-ip>:8200
# Get root token:
docker logs vault 2>&1 | grep "Root Token"In the Vault UI, go to Secrets → Enable new engine → KV (version 2). Choose a path (e.g. "secret"). Then click "Create secret", enter a path like "myapp/database", and add key-value pairs for your credentials. Via CLI:
export VAULT_ADDR='http://127.0.0.1:8200'
export VAULT_TOKEN='your-root-token'
vault kv put secret/myapp/database password="securepass" user="appuser"Create a policy that grants read-only access to a specific secret path. Then generate an application token bound to that policy — this token can only read the specific secrets defined in the policy, nothing else. Applications use this token to retrieve secrets at runtime without hardcoding credentials.
# Create a policy file
cat > myapp-policy.hcl << 'EOF'
path "secret/data/myapp/*" {
capabilities = ["read"]
}
EOF
vault policy write myapp myapp-policy.hcl
vault token create -policy=myapp| Port | Purpose |
|---|---|
| 8200 | Vault API & Web UI |
HashiCorp Vault is the industry-standard open-source tool for secrets management. It provides a secure, unified way to store and access sensitive data: database credentials, API keys, TLS certificates, SSH keys, and any other secret. Vault addresses the 'secret sprawl' problem — credentials scattered in config files, environment variables, source code, and spreadsheets. Instead, all secrets live in Vault with strict access policies, audit logs for every read, automatic secret rotation, and dynamic credentials (Vault generates short-lived database passwords on demand, eliminating long-lived static credentials entirely).
Vault solves the hardest problem in infrastructure security: where do you safely store the credentials your services need? Hardcoded passwords in config files, .env files checked into Git, or secrets emailed between team members are all security disasters waiting to happen. Vault provides a single encrypted secrets store with fine-grained access control (only service X can read secret Y), complete audit logs (who accessed what, when), and automatic rotation so breached credentials expire before they can be exploited.
Open port 8200 for Vault's API and web UI. In production, put Vault behind a TLS-terminating reverse proxy (Caddy or Nginx) on port 443. Port 8201 is used for Vault cluster communication in HA deployments and should be restricted to internal networks only.
For simpler use cases, Vaultwarden manages passwords for human users via the Bitwarden UI. Infisical is a newer developer-focused secrets manager with a nicer UI. Doppler and 1Password Secrets Automation are commercial alternatives. AWS Secrets Manager and GCP Secret Manager are cloud-native options. Vault remains the most powerful and flexible open-source secrets management platform for infrastructure-scale use.
Avoid Vault for password management for human users — use Vaultwarden (Bitwarden) instead. Don't use Vault if your team has no experience with secrets management concepts — misconfigured policies can lock you out of your own secrets. For small teams with one or two services, a well-secured .env file or a platform's built-in secrets feature (GitHub Actions Secrets, GitLab CI Variables) is simpler and sufficient.
PrismaTechWork provides end-to-end infrastructure services — from initial deployment and security hardening to ongoing monitoring, automated backups, and dedicated support. Whether you need a single-server setup or a multi-site network, our team ensures your infrastructure is built right, secured properly, and maintained reliably.
Dev mode starts Vault pre-initialized and pre-unsealed with an in-memory storage backend — all data is lost when the container stops. It's only for testing and development. Production mode uses a persistent storage backend (Raft, Consul, or PostgreSQL), requires initialization and unsealing on every start, and supports HA clustering. Never use dev mode for real workloads.
Dynamic secrets are credentials generated on-demand by Vault with a time-to-live (TTL). For example, instead of a permanent MySQL password, Vault creates a unique username/password that expires in 1 hour. The application gets a fresh credential every time it needs one. If a credential is leaked, it expires automatically. Static credentials, by contrast, must be manually rotated and can be valid for years if forgotten.
When Vault starts, it's sealed — the master encryption key is split into shards using Shamir's Secret Sharing. You need a minimum number of key shares (e.g., 3 of 5) to reconstruct the master key and unseal Vault. This prevents any single person from having full access. For automated unsealing, Vault supports cloud KMS services (AWS KMS, GCP Cloud KMS) that hold one key shard.
Yes. The Vault Agent Injector and the Vault Secrets Operator can inject secrets from Vault into Kubernetes pods at runtime. The Vault Kubernetes auth method lets pods authenticate using their service account JWT. This is the standard way to avoid hardcoding secrets in Kubernetes manifests or ConfigMaps.
For dynamic secrets (database credentials), Vault handles rotation automatically via the lease TTL mechanism — applications get new credentials before old ones expire. For static secrets in KV, use Vault Agent to watch for secret changes and reload the application. Vault's response wrapping feature can be used for one-time-use secret distribution during application startup.
The Transit engine provides encryption-as-a-service: your application sends data to Vault to be encrypted and receives back ciphertext — Vault never stores the data. The encryption key lives only in Vault. This lets you encrypt sensitive database fields, files, or PII without managing encryption keys in your application code. It also supports key rotation without re-encrypting all data.
Yes. Vault's PKI secrets engine can act as a Certificate Authority (CA) or an intermediate CA. Enable it with vault secrets enable pki, configure a CA certificate and key, and define roles that specify allowed domains. Services can then request short-lived TLS certificates (valid for hours or days) instead of long-lived certificates. This limits the blast radius of certificate compromise.
For Raft integrated storage: vault operator raft snapshot save backup.snap creates an encrypted snapshot. Restore with vault operator raft snapshot restore backup.snap. Store snapshots encrypted in external storage (S3, SFTP). Never store the unseal keys alongside the snapshot. Test restoration quarterly — discovering a broken backup during an incident is catastrophic.