Taking your HashiCorp Vault to the next level
Using Hashicorp Vault like a pro
Have you ever installed Hashicorp Vault and wondered to yourself:
“Am I actually protecting my organization?”
You’re not alone.
While it’s easy to install Vault, making sure that it is configured correctly for productivity and security can be a challenging task.
I’ve built my fair share of guides and webinars and worked with Vault a-lot recently. This has led me to create my own list of Vault’s best practices.
Auditing
Auditing simply means to log every interaction with Vault, any API request/response, the audit log contains every interaction with Vault, including errors.
Note: If Vault won’t be able to audit an API call, it won’t execute it.
This is great because it means that every interaction with Vault is audited and accessible in a log file.
In order to enable auditing functionality via Vaults CLI on your machine, execute the following command:
$ vault audit enable file file_path=/var/log/vault_audit.logFeel free to put a different path for the log file if you’d like.
Once implemented, vault will now log every interaction made to it and will write it as a JSON object.
For UNIX systems, you can also choose to audit via Syslog simply by running the following command:
$ vault audit enable syslogHere’s an example of an output from the audit file:
As we can see, there’s high visibility of who did what to whom with exact details. Therefore, in case of security compromise, we can identify where the attacker tried to reach and how.
Avoid Root Token
After initalizing Vault, we usually use the root token that has been provided.
The root token can do anything within Vault, and I do mean ANYTHING.
Therefore, it’s worth understanding that root token usage should be avoided and even better, revoked right after the Vault admin finished setting up the basic configurations and users with proper policies.
Revoking root token
In order to revoke a token in Vault, run the following command:
$ vault token revoke <TOKEN>Make sure that you can put the token that you’d like to revoke, the root token for example.
Generate Root Token
If you will ever need the root token again, you can re-generate a new one by following this guide.
Policies (ACL)
Access Control List, also known as Policies in Vault, provide a declarative way to grant or forbid access to certain paths and operations in Vault.
Policies are “Deny By Default”, so if no policy was assigned, no permissions in the system will be allowed.
Policy Format
Policies are written in HCL (Hashicorp configuration language) or in JSON.
Here is an example of a policy:
path "secret/dev/team-1/*" {
capabilities = ["create", "update", "read"]
}
path "secret/dev/global" {
capabilities = ["read"]
}Everything in Vault is path based, so it’s pretty straightforward to understand how to write a policy, put the path and the capabilities you’d like to grant to that path.
In the example above, we provide permissions to create, update and read secrets from secret/dev/team-1, also, we provide permissions to read only from secret/dev/global.
It’s important to understand that by default, whoever will be associated with that policy will NOT have permissions to the other paths (Thus called “Deny By Default”).
Importing a Policy
In order to add a policy to Vault, simply run the following command:
# vault policy write <POLICY_NAME> <HCL_FILE_PATH>$ vault policy write dev-team-1 team-one-policy.hcl
In this example, we created a policy called dev-team-1 and uploaded our HCL file where the policy settings are written team-one-policy.hcl.
Assigning a Policy
In order to assign a policy to a token, simply run the following command:
$ vault token create -policy=dev-team-1In this example, we created a new token and assigned it to our dev-team-1policy.
We can test it out by logging with the created token and try to create/read/update secrets from secret/dev/team-1 with no issues.
If we’ll try to create a secret in secret/dev/global we’ll get permission denied message because we set permissions of read only for secret/dev/global path in our policy above.
You should also assign specific policies for your Auth Methods, this is called Mapping, for example, for GitHub auth method you can run the following command:
$ vault write auth/github/map/teams/dev-backend value=dev-team-1In this example, we set a team called “dev-backend” with our policy from above — dev-team-1 .
In order to map your policy to a different auth method, you should use the path-help.
Disable SSH / Remote desktop
Vault should be the only main process running on a machine, also, users should never access the machine directly. Instead, they should use Vaults API over the network.
It’s recommended to disable SSH to Vaults machine completely, remove any kind of option to remote/log it.
If disabling SSH is not an option for you, you can change the ports and encrypt your SSH key and put it in a safe place, making SSH-ing Vaults machine complicated as much as possible.
Accessing Vault
Accessing Vault should be done via its HTTP API, as a developer, for example, I won’t be able to use Vaults CLI because I won’t have access to the machine itself.
You can use cURL, but for the simplicity of things, I recommend you use Postman to make your life easier when working with Vault.
Vault-UI
As you may already understand, Vault is not super friendly when it comes to interacting with it. Especially in the modern world where we look for the simplicity of things, a web application with a friendly UI.
Recently, Hashicorp announced that they released one of their premium features to the open source; Vault UI.
Since the official Hashicorps Vault UI feature was part of the enterprise edition which cost money, there were open source alternatives like Vault-UI by Djenriquez or Goldfish by Caiyeon.
If you are running Vault with version 0.10 and above, you should have the UI installed by default but not activated.
If you are not running your server in developer mode (vault server -dev) you will need to add ui=true to your server configuration file (HCL/JSON) For example:
ui = true
listener "tcp" {
address = "10.0.1.35:8200"
}
storage "consul" {
# ...
}Access Vault UI by entering /ui in the web browser with the URL where your Vault is located, for example, if you ran Vault locally on your machine open your browser and navigate to http://127.0.0.1:8200/ui
Note that if you didn’t initialize Vault, you will face the initialization screen process.
After authenticating with our Token/Userpass/LDAP/Okta/GitHub credentials we can start exploring Vault UI.
“Secrets Menu” for exploring secrets with the permissions that were assigned to the logged user.
“Access” for managing users, vault identity entities, as well as leases.
“Replication” for configuration of Disaster Recovery and Performance Replication. (Note that this is enterprise feature, which means you will have to pay to Hashicorp In order to use it.)
“Policies Menu” to configure and manage ACL (Access Control List) policies, with the ability to write a new policy from the web or upload an existing HCL/JSON file from your machine.
“Tools Menu” provides a way to leverage response wrapping, as well as access cryptographic functions like random and hash.
“Settings Menu” provides a way to centrally review Secret Engines, Auth Methods, as well as to Seal the Vault.
There are many more features and abilities that Vault provides.
If you have any questions/thoughts regarding this blog or Vault itself, you may comment here or contact me directly on Twitter @Zvika_Nadav.
For those of you who are not familiar with Hashicorp Vault, I strongly recommend you to take the FREE introduction session which is currently running on a weekly basis by me — register by clicking here.
My name is Zvika, and I am a consultant at ProdOps — a global consultancy that delivers software in a Reliable, Secure and Simple way by adopting the DevOps culture.
