How to Install HashiCorp Vault for Secrets Management on RHEL 7

HashiCorp Vault is an open-source tool for securely storing and tightly controlling access to tokens, passwords, certificates, API keys, and other secrets throughout the software lifecycle. Unlike storing secrets in configuration files or environment variables, Vault provides a central, audited, and access-controlled secrets store with dynamic secret generation, automatic lease renewal, and built-in encryption. On RHEL 7, Vault runs as a long-lived systemd service backed by a configurable storage backend. This tutorial covers installing Vault from the official HashiCorp repository, configuring the server, initializing and unsealing the vault, enabling a key-value secrets engine, and configuring the AppRole authentication method for application access.

Prerequisites

RHEL 7 system with root or sudo access
Internet access to reach the HashiCorp package repository
Minimum 1 GB RAM; 2 GB recommended for production
A static IP address or resolvable hostname for the Vault server
Basic knowledge of JSON, TLS/SSL concepts, and systemd
The vault CLI installed (covered below) and added to your PATH

Step 1: Add the HashiCorp Yum Repository and Install Vault

HashiCorp provides official signed RPM packages via their own yum repository. This is the recommended installation method as it handles GPG verification and provides clean upgrade paths:

# Install yum-utils for yum-config-manager
yum install -y yum-utils

# Add the HashiCorp Linux repository
yum-config-manager --add-repo https://rpm.releases.hashicorp.com/RHEL/hashicorp.repo

# Verify the repo was added
yum repolist | grep hashicorp

# Install Vault
yum install -y vault

# Verify the installation
vault version

The installer places the binary at /usr/bin/vault, configuration files under /etc/vault.d/, and a systemd service unit at /lib/systemd/system/vault.service. A dedicated vault system user and group are also created.

Step 2: Configure the Vault Server

The main configuration file is /etc/vault.d/vault.hcl. Vault supports multiple storage backends; this guide uses the built-in Integrated Storage (Raft) backend, which requires no additional software. For a production setup you would use Consul, but Raft is fully supported and recommended for single-node or small cluster deployments.

vi /etc/vault.d/vault.hcl

Replace the default contents with:

# /etc/vault.d/vault.hcl

# Storage backend using Integrated Raft storage
storage "raft" {
  path    = "/opt/vault/data"
  node_id = "node1"
}

# TCP listener — use TLS in production
listener "tcp" {
  address     = "0.0.0.0:8200"
  tls_disable = "true"
}

# API address must be reachable by clients
api_addr     = "http://192.168.1.100:8200"
cluster_addr = "https://192.168.1.100:8201"

# Enable the Vault UI
ui = true

# Disable mlock for development (remove in production)
disable_mlock = true

Create the data directory and set appropriate permissions:

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

Production note: Always use TLS in production. Generate or obtain a TLS certificate and configure tls_cert_file and tls_key_file in the listener block, and set tls_disable = "false".

Step 3: Start the Vault Service

systemctl daemon-reload
systemctl start vault
systemctl enable vault
systemctl status vault

Set the VAULT_ADDR environment variable so the vault CLI knows where to connect:

export VAULT_ADDR='http://127.0.0.1:8200'

# Add it to root's bash profile for persistence
echo 'export VAULT_ADDR=http://127.0.0.1:8200' >> /root/.bash_profile
source /root/.bash_profile

# Check that vault is reachable but uninitialized
vault status

The output will show Initialized: false and Sealed: true. This is expected before initialization.

Step 4: Initialize the Vault

Vault initialization generates the encryption keys and root token. By default, it creates 5 unseal key shares and requires 3 (the threshold) to unseal. These keys must be stored securely — losing them means losing access to all secrets stored in Vault.

vault operator init

The output will look like this:

Unseal Key 1: wM3n6aMJuXkjrF9Wf3JDuS5oIy+7D7Rj+tK5/K3b8As=
Unseal Key 2: xP4o7bNKvYlmSg0Xg4KEv6pJkz+8E8Sk+uL6/L4c9Bt=
Unseal Key 3: yQ5p8cOLwZmnTh1Yh5LFw7qKlA+9F9Tl+vM7/M5d0Cu=
Unseal Key 4: zR6q9dPMxAnouI2Zi6MGx8rLmB+0G0Um+wN8/N6e1Dv=
Unseal Key 5: AS7r0eQNyBopvJ3Aj7NHy9sMonC+1H1Vn+xO9/O7f2Ew=

Initial Root Token: hvs.CAESICV6Kj2...

Vault initialized with 5 key shares and a key threshold of 3.
Please securely distribute the key shares printed above.
When the Vault is re-sealed, restarted, or stopped, you must supply
at least 3 of these keys to unseal it again.
Vault does not store the generated root key. Without at least 3 keys
to reconstruct the root key, Vault will remain permanently sealed!

Critical: Save all 5 unseal keys and the root token in a secure, offline location. Distribute key shares to different trusted individuals in production environments.

Step 5: Unseal the Vault

After every restart, Vault starts in a sealed state and cannot decrypt its storage. You must provide at least 3 of the 5 unseal keys (the threshold you configured) to unseal it. Run the unseal command three times, providing a different key each time:

# Unseal with key 1
vault operator unseal wM3n6aMJuXkjrF9Wf3JDuS5oIy+7D7Rj+tK5/K3b8As=

# Unseal with key 2
vault operator unseal xP4o7bNKvYlmSg0Xg4KEv6pJkz+8E8Sk+uL6/L4c9Bt=

# Unseal with key 3
vault operator unseal yQ5p8cOLwZmnTh1Yh5LFw7qKlA+9F9Tl+vM7/M5d0Cu=

After the third key, Vault will show Sealed: false. Log in with the root token:

vault login hvs.CAESICV6Kj2...

Step 6: Enable the KV Secrets Engine and Store Secrets

Vault organizes secrets into secrets engines mounted at paths. The Key-Value (KV) secrets engine is the most basic and allows you to store arbitrary key-value pairs:

# Enable the KV v2 secrets engine at the path 'secret/'
vault secrets enable -path=secret kv-v2

# List enabled secrets engines
vault secrets list

# Store a secret
vault kv put secret/myapp/database 
    username="dbadmin" 
    password="S3cur3P@ssw0rd!" 
    host="db.example.com" 
    port="5432"

# Retrieve the secret
vault kv get secret/myapp/database

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

# List all secrets at a path
vault kv list secret/myapp/

KV v2 supports versioning. You can retrieve previous versions of a secret:

# Update a secret (creates version 2)
vault kv put secret/myapp/database password="NewP@ssw0rd!"

# Get version 1 of the secret
vault kv get -version=1 secret/myapp/database

# Delete a specific version
vault kv delete -versions=1 secret/myapp/database

Step 7: Configure AppRole Authentication

Applications should never use the root token to access Vault. The AppRole auth method issues tokens to applications based on a Role ID and Secret ID pair, enabling machine-to-machine authentication with scoped policies.

# Enable the AppRole auth method
vault auth enable approle

# Create a policy that grants the application read access to its secrets
cat > /tmp/myapp-policy.hcl << 'EOF'
path "secret/data/myapp/*" {
  capabilities = ["read", "list"]
}
EOF

vault policy write myapp-policy /tmp/myapp-policy.hcl

# Create an AppRole tied to the policy
vault write auth/approle/role/myapp 
    token_policies="myapp-policy" 
    token_ttl="1h" 
    token_max_ttl="4h" 
    secret_id_ttl="24h" 
    secret_id_num_uses=10

# Read the Role ID (not secret, can be stored in config files)
vault read auth/approle/role/myapp/role-id

# Generate a Secret ID (treat as a password, store securely)
vault write -f auth/approle/role/myapp/secret-id

To authenticate as an application using the AppRole:

# Login with Role ID and Secret ID to get a token
vault write auth/approle/login 
    role_id="" 
    secret_id=""

# Use the returned token to fetch secrets
export VAULT_TOKEN=""
vault kv get secret/myapp/database

HashiCorp Vault provides a comprehensive, auditable secrets management platform that eliminates hardcoded credentials across your RHEL 7 infrastructure. By centralizing secrets in Vault, you gain fine-grained access control, automatic secret rotation capabilities, complete audit logging of every secret access, and the foundation for a zero-trust secrets architecture. As a next step, explore Vault’s dynamic secrets engines which can generate short-lived, automatically revoked database credentials and cloud provider API keys on demand.

Links

Newsletter

Contact