How to Setup and Configure Hashicorp Vault Server – Detailed Beginners Guide

This Hashicorp vault beginners tutorial will walk you through the steps on how to setup and configure a Hashicorp vault server with detailed instructions.


Vault is a tool from HashiCorp for securely storing and accessing secrets. Secret is nothing but all credentials like API Keys, passwords and certificates. Vault provides a unified interface to any secret while providing tight access control and recording a detailed audit log. Most of the organizations would keep their secrets in GitHub which can be seen by anyone who has access to the repo. Vault is designed in such a way that we can keep our database credentials, API keys for external services, credentials into vault and access directly from the application using APIs using various authentication mechanisms. HashiCorp Vault has more advantages than other similar services like HSMs, AWS KM, and keywhiz.

Most Common Use Cases of Vault

Following are the common use cases for Vault

  1. A bare minimum vault can be used as a general secret storage, It is a great tool to store environment variables, DB credentials and API keys.
  2. Vault is a good fit for storing credentials that employees share to access web services. The audit log mechanism lets you know what secrets an employee accessed and when an employee leaves, it is easier to roll keys and understand which keys have and haven’t been rolled.
  3. The “dynamic secrets” feature of Vault is ideal for scripts: It can generate an access key for the duration of a script runtime which is like temporary access token.
  4. In addition to being able to store secrets, Vault can be used to encrypt/decrypt data that is stored elsewhere. The primary use of this is to allow applications to encrypt their data being in the primary data store.

Key Vault Features

Secure Secret Storage: Arbitrary key/value secrets can be stored in Vault. It encrypts the secret and stores in a persistent backend storage. Vault supports multiple storage backends such as a local disk, consul or cloud storage like AWS S3 or GCS bucket.

Dynamic Secrets: Vault can generate secrets on-demand for some systems, such as AWS or SQL databases. For example, when an application needs to access an S3 bucket, it asks Vault for credentials, and Vault will generate an AWS keypair with valid permissions on demand. After creating these dynamic secrets, Vault will also automatically revoke them after the lease is up.

READ  List of DevOps Blogs and Resources for Learning

Data Encryption: Vault is capable of encrypting and decrypting data without storing it. This allows security teams to define encryption parameters and developers to store encrypted data in a location such as SQL without having to design their own encryption methods.

Leasing and Renewal: Secrets in vaults are associated with the lease, end of the lease vault will revoke the secrets, We can renew lease using renew APIs.

Revocation: Vault has built-in support for secret revocation.

Setup and configure Vault Server on Linux

Follow the steps given below for setting up the vault server.

Step 1:  Download the latest version of vault binary zip file from vault release page and unzip it.

Step 2: Copy vault binary into /usr/bin. This will allow us to execute vault binary systemwide.

Step 3:  Create a vault config directory under /etc,  a vault data directory and logs directory.

Step 4: Create a config.json file and add the vault configuration.

Add the below configuration to the file. Vault supports both JSON and HCL formats. Here we are using JSON format.

Note: replace with your vault host public/private IP.

max_lease_ttl – Specifies the maximum possible lease duration for tokens and secrets. This is specified using a label suffix like “30s” or “1h”.

default_lease_ttl – Specifies the default lease duration for tokens and secrets. This is specified using a label suffix like “30s” or “1h”. This value cannot be larger than max_lease_ttl.

Note: This config file is created specifically to use filesystem backend, You can even use consul cluster backend, S3 or GCS (Google cloud storage) backend like shown below,

Vault Consul Backend Config

Vault Google Storage (GCS) Backend Config

Step 5: Create a vault service file.

Copy the following contents to the service file.

Step 6: Start the vault service.

Check the service status.

Enable vault service at boot up to make sure it starts automatically for reboots,

Step 7: Login as root and Export VAULT_ADDR environment variable, don’t forget to add this to ~/.bashrc file. Change the IP to you vault server public/private IP.

Step 8: Check the status using vault status

You will get an error server is not yet initialized as shown below. You could see vault is sealed by default. This is because of the default behavior of vault.

Let’s initiate the vault server and store the initial tokens in a file.

Note: execute the following command by logging in as the root user.

Noe vault is initiated but sealed. You can view the status using the following command.

Open the init file to get the unseal and root tokens. These tokens can be used to unseal the vault web UI during the first login.

An example, the output containing the root token is shown below.

Once a Vault is unsealed, it remains unsealed until one of two things happens:

  1. It is re-sealed via the API (see below).
  2. If vault service gets restarted or during a server restart.

Step 9: Unseal vault using unseal command. There are 5 unseal tokens. You need to execute the unseal command with a minimum of three unseal token to unseal vault.

Here you can see your standalone vault is up and running successfully, you can start by enabling authentication method and secret engine which you like,

Step 10: Now you can also view vault console using the following URL,

Finally, you can log in with root credentials which we created while initializing vault, in our case d4dd0b96-4767-57a3-9081-aca03e530c8f. Managing will be easy through UI

Once you login you will see the following page,

vault UI setup

Vault Roles and Policies

Once the setup is done, you can use vault by enabling AppRoles or some other auth methods with proper policies associated with it. Covering full roles and policies is out of the scope of this article.

You can create AppRole and Policies through CLI as well as vault console.

Note: This same can be done from Vault console also

bound_cidr_list: If bound_cidr_list is set on the role, then the list of CIDR blocks listed here should be a subset of the CIDR blocks listed on the role.

bind_secret_id: Require secret_id to be presented when logging in using this AppRole.

Configure secrets from the console as shown in below image, by default vault uses KV secret engine, we can even use AWS, RabbitMQ, Google cloud or any databases as a secret engine.

hashicorp vault - creating secrets

Vault server which we have created is a standalone instance with HA Enabled configuration, If we disable HA Enabled option from config.json this will act as a cluster without HA.

To enable HA we can have multiple machines where we configure api_addr parameter as the host IP, at a time only one of the node will act as the active node and rest of them are standby nodes.

ONLINE COURSE: Managing Secrets with Hashicorp Vault

Everything you need to get started with Hashicorp Vaulthashicorp vault online course

  • Learn concepts and architecture of vault
  • Get started secret management
  • Vault HA and TLS management
  • Learn to manage secrets using CLI
  • Learn to build PKI solution

Free DevOps Resources

Get DevOps news, tutorials and resources in your inbox. A perfect way If you want to get started with devops. Like you, we dont like spam.