How to Install HashiCorp Vault for Secrets Management on RHEL 9

November 23, 2025
Linux
Comment off

HashiCorp Vault is an open-source secrets management platform that provides secure storage, access control, and auditing for sensitive data such as API keys, passwords, certificates, and encryption keys. Instead of hardcoding secrets in application configs or environment variables, applications request them from Vault at runtime using short-lived tokens or AppRole credentials. This tutorial covers installing Vault on RHEL 9 from the official HashiCorp repository, configuring a file storage backend, initializing and unsealing the cluster, and storing and retrieving secrets using the KV v2 engine. By the end you will have a functional Vault server ready for application integration.

Prerequisites

RHEL 9 server with sudo access
Internet access to reach the HashiCorp repository
At least 512 MB free RAM and 1 GB disk space for the file storage backend
A hostname or IP address for the Vault API listener

Step 1 — Add the HashiCorp Repository and Install Vault

HashiCorp publishes official RPM packages via their Yum repository. Add the repo and install Vault:

dnf install -y dnf-plugins-core
dnf config-manager --add-repo https://rpm.releases.hashicorp.com/RHEL/hashicorp.repo
dnf install -y vault

# Verify the installation
vault version

Step 2 — Configure vault.hcl

The default configuration file is at /etc/vault.d/vault.hcl. Configure a file storage backend and a TCP listener. For production, use a TLS certificate; for this tutorial we enable TLS disabled mode only for initial testing:

cat > /etc/vault.d/vault.hcl << 'EOF'
storage "file" {
  path = "/opt/vault/data"
}

listener "tcp" {
  address     = "0.0.0.0:8200"
  tls_disable = "true"
}

api_addr = "http://127.0.0.1:8200"
cluster_addr = "https://127.0.0.1:8201"
ui = true
EOF

Create the data directory and set ownership:

mkdir -p /opt/vault/data
chown -R vault:vault /opt/vault/data
chmod 700 /opt/vault/data

Step 3 — Enable and Start the Vault Service

Enable and start the Vault systemd service, then export the Vault address for CLI use:

systemctl enable --now vault
systemctl status vault

# Export the address for CLI commands
export VAULT_ADDR='http://127.0.0.1:8200'

# Add to your shell profile for persistence
echo 'export VAULT_ADDR="http://127.0.0.1:8200"' >> ~/.bashrc

Step 4 — Initialize Vault and Unseal

A new Vault installation must be initialized to generate unseal keys and a root token. Vault uses Shamir’s Secret Sharing — by default it generates 5 key shares requiring 3 to unseal. Store these keys securely and never keep them all in the same place:

# Initialize Vault (generates 5 key shares, threshold 3)
vault operator init

# Example output (save ALL of this securely):
# Unseal Key 1: abc123...
# Unseal Key 2: def456...
# Unseal Key 3: ghi789...
# Unseal Key 4: jkl012...
# Unseal Key 5: mno345...
# Initial Root Token: hvs.XXXXXXXXXXXX

# Unseal with 3 different key shares (run 3 times with different keys)
vault operator unseal   # paste Unseal Key 1
vault operator unseal   # paste Unseal Key 2
vault operator unseal   # paste Unseal Key 3

# Confirm Vault is unsealed
vault status

Step 5 — Log In and Enable the KV Secrets Engine

# Log in with the root token
vault login   # paste the Initial Root Token when prompted

# Enable KV v2 secrets engine at path "secret"
vault secrets enable -path=secret kv-v2

# Verify it is enabled
vault secrets list

Step 6 — Store, Read, and Manage Secrets

Write a secret (for example, database credentials), read it back, and see how AppRole authentication allows applications to access secrets without using the root token:

# Store a secret at secret/myapp/database
vault kv put secret/myapp/database 
  username="dbuser" 
  password="s3cr3tP@ssw0rd"

# Read the secret back
vault kv get secret/myapp/database

# Read only a specific field
vault kv get -field=password secret/myapp/database

# Enable AppRole authentication for application access
vault auth enable approle

# Create a policy that allows the app to read only its secrets
cat > /tmp/myapp-policy.hcl << 'EOF'
path "secret/data/myapp/*" {
  capabilities = ["read"]
}
EOF
vault policy write myapp-policy /tmp/myapp-policy.hcl

# Create an AppRole for the application
vault write auth/approle/role/myapp 
  token_policies="myapp-policy" 
  token_ttl=1h 
  token_max_ttl=4h

# Retrieve RoleID and SecretID for the application
vault read auth/approle/role/myapp/role-id
vault write -f auth/approle/role/myapp/secret-id

Applications use the RoleID and SecretID to authenticate and obtain a time-limited token scoped only to their allowed paths.

Conclusion

You have installed HashiCorp Vault on RHEL 9, configured a file storage backend, initialized and unsealed the server, and stored and retrieved secrets using the KV v2 engine. AppRole authentication gives applications a secure, non-human credential path to access only the secrets they need. For production deployments, replace the file backend with Consul or Raft integrated storage, enable TLS on the listener, and automate unseal with a cloud KMS (AWS KMS, Azure Key Vault, or GCP Cloud KMS).

Next steps: How to Configure Mandatory Access Control with SELinux Policies on RHEL 9, How to Rotate Secrets Automatically with HashiCorp Vault on RHEL 9, and How to Set Up Vault High Availability with Raft Storage on RHEL 9.

Links

Newsletter

Contact