Vault is an open-source secret management tool created by the Hashicorp community. It is useful for keeping a centralized store of all the secrets your application relies on. It's simple to set up and provides loads of features.
In this article, we'll dive into its setup and demo a simple use case of Hashicorp Vault.
As a prerequisite, you'll need a Docker Environment to start.
Setting up Vault Server Instance
First, create a directory called
vault using the command below,
Now, create a
docker-compose file. We will be using
docker compose to manage the vault server instance.
compose.yml file using the command below,
Now, we'll create the
vault.json file using the command below,
Now start the vault instance using the command below,
docker compose -f compose.yml up -d
Configuring Vault Server Instance
We'll now configure the Vault with our secrets, users and access control policies.
Open the URL
http://localhost:8200. Here, you'll be greeted with a welcome screen that asks you to initialize the Vault.
The UI will guide you through creating root access tokens and creating secrets for unsealing the Vault.
Download the Root Token and Un-Sealing Keys and proceed to the next step.
Configuring Role-Based Access
We'll create two accounts for this demo, one with read-only access and the other with admin access.
Go to the policies tab and click on
Create ACL policy.
You should be able to see two policies:
root present in the dashboard. The root policy is the one responsible for providing full
admin access via the
Create ACL policy and use the example policies provided below to set up the
admin != root
The root user has complete administrative access, whereas the admin user will have access to a subset of features that the root user has.
View Only Example Policy
Use the content above to create the View Only Policy.
Admin Example Policy
Use the content above to create the Admin Policy.
After creating the policies, we will create a user with
admin privileges and another with
Setup Authentication Method
To create users, go to the
Here, the default authentication method
Token Auth is already available. We used this authentication method when we used our root token to log in to the dashboard.
Enable new method, select
Username & Password method and click next.
On the next page, we will see that the string
userpass is pre-filled as our path. This is because it is the default path for storing details of the
Username & Password authentication method. Leave the path as it is and click on Enable Method.
Create User Accounts
If you click on the newly created method, you will be directed to a page where you can create the required user accounts.
Create user and set up the username and password for your account.
We will create two users similarly. One will be the admin user, and the other will be a user with view-only privileges. As we already created the policies required for each, we'll apply the necessary policy during user creation.
To do so, click on the
Tokens dropdown button, and a list of options will be presented to us. Here do the following,
- Click on
Do Not Attach 'default' Policy To Generated Tokens
This will prevent Vault from attaching the default policy to the user account. We will be using our own custom policy for this.
- In the
Generated Token's Policiesform, enter the name of the admin policy we created in the last step.
This will provide admin privileges to the admin user. For the normal user, use the
Now save the configuration and repeat it for the next user you create. Finally, we'll set up the secret engine, which is the one where secrets will be stored and accessed from.
Click on the
You should see an engine present already by the name of
cubbyhole. We will not be using this but instead create a separate
key value (KV) secret engine.
We will now configure the
KV secret engine, the string
kv is already present in the path. This is the default path and can be changed to your liking. You can set the maximum number of versions according to your choice.
If your use case requires a lot of revisions to the secrets and you want to look at changes going all the way to the 1st version, then please specify a larger value in the
Maximum number of versions form.
Once created, click on the newly created secret engine and create a secret. Provide a name for the secret and fill up the secret data form. Alternatively, secret data can be provided via JSON.
Once you save the first version of the secret, new versions can be created by clicking on the
Create new version button.
kvpath, then our ACL policies will not work. Modify the secret path in the policy to reflect the path present in the secret engine you just created.
To test, open the vault dashboard in a new tab and log in first using the
We can only view the created secret and its different versions with the view-only user.
Whereas, on using the admin user, we can see options like
create new version,
In this article, we've learned to set up a secret management solution, create user accounts with admin and non-admin privileges, create secrets, and access the said secrets.
In future articles, we will discuss the injection of secrets during runtime in Docker and Kubernetes environments.
Thank you for reading. Please comment below if you have any queries, I periodically try to update my articles to ensure legibility.