As we started discussing about secret service, with to more with that. We want to discuss about one of growing secret service, which can be used with most of cloud services and DevOps tools. In this guide, will explain about How to Setup HashiCorp Vault on Linux.
Note: In this blog, we’re using the filesystem backend to store encrypted secrets on the local filesystem at /vault-data. This is suitable for local or single-server deployments that do not need to be replicated. This is not suitable for HA Setup.
Introduction
Vault is an open-source tool that provides a secure, reliable way to store and distribute secrets like API keys, access tokens, and passwords. Software like Vault can be critically important when deploying applications that require the use of secrets or sensitive data.
To download latest vault package, Go to Hashicorp vault downloads page and download the latest package.
# wget https://releases.hashicorp.com/vault/1.4.2/vault_1.4.2_linux_amd64.zip
Unzip the package
# unzip vault_1.0.1_linux_amd64.zip
Move the vault executable to /usr/bin
# mv vault /usr/bin/
Once you moved, verify vault command by checking its version.
# vault -v
Finally, set a Linux capability flag on the binary. This adds extra security by letting the binary perform memory locking without unnecessarily elevating its privileges.
# setcap cap_ipc_lock=+ep /usr/bin/vault
Create vault data folder.
# mkdir /vault-data
Creating the Vault startup file
Systemd is Ubuntu’s init system which, among other things, manages the system’s services. In order to set Vault up as a system service, we are going to create separate user account to manage the service and will create separate mount to store Vault information.
First, let’s create a vault system user.
# useradd -r -d /vault-data-s /bin/nologin vault
Here, we use /vault-data as the user’s home directory. This will be used as the Vault data directory. We also set the shell to /bin/nologin to restrict the user as a non-interactive system account.
Set the ownership of /vault-data to the vault user and the vault group exclusively.
# install -o vault -g vault -m 750 -d /vault-data
Now let’s set up Vault’s configuration file, /etc/vault.hcl. You’ll use this to control various options in Vault, such as where encrypted secrets are stored.
Create vault.hcl using nano or your favorite text editor.
# vim /etc/vault.hcl
Paste the following into the file, and make sure to substitute in your own domain name:
ui = true
storage "file" {
path = "/vault-data"
}
listener "tcp" {
address = "0.0.0.0:8200"
tls_disable = 1
}
This configuration file instructs Vault to store encrypted secrets in /vault-data on-disk. Now you can save the file and make sure you change the file permission to vault user which we created in previous step.
# chown vault:vault /etc/vault.hcl
# chmod 640 /etc/vault.hcl
Now, let’s create service script to manage the service by system. For that create /etc/systemd/system/vault.service as following
# vim /etc/systemd/system/vault.service
[Unit]
Description=HashiCorp Vault to manage secrets
Documentation=https://vaultproject.io/docs/
After=network.target
ConditionFileNotEmpty=/etc/vault.hcl
[Service]
User=vault
Group=vault
ExecStart=/usr/bin/vault server -config=/etc/vault.hcl
ExecReload=/usr/local/bin/kill --signal HUP $MAINPID
CapabilityBoundingSet=CAP_SYSLOG CAP_IPC_LOCK
AmbientCapabilities=CAP_IPC_LOCK
SecureBits=keep-caps
NoNewPrivileges=yes
KillSignal=SIGINT
[Install]
WantedBy=multi-user.target
The complete list of service unit options is extensive, but the most important configuration options to note in the above definition include:
- ConditionFileNotEmpty ensures that the /etc/vault.hcl configuration file exists.
- User and Group, which control the user permissions that the Vault daemon will run with.
- ExecStart, which points to the executable that we installed previously and defines what to start to run the service.
- ExecReload, which is called when Vault reloads its configuration file, e.g., when running systemctl reload vault.
- [Install], which lets us run this service persistently at startup, so we don’t need to start it manually after reboots.
Now, we can start the service using following command
# systemctl deamon-reload
## [Required for first time or if any change in service file]
# systemctl start vault.service
To Check the service status,
# systemctl status vault.service
Initialize Vault
There are two pieces of information that Vault will expose at initialization time that will not be available at any other point, so make sure you noted some secure place,
Initial root token: This is equivalent to root permissions to your Vault deployment, which allows the management of all Vault policies, mounts, and so on.
Unseal keys: These are used to unseal Vault when the daemon starts, which permits the Vault daemon to decrypt the backend secret store.
More specifically, Vault’s unsealing process decrypts the backend using a key formed by key shares. That is, when initializing Vault, you may choose how many unseal keys to create and how many are necessary at unseal time to successfully unseal Vault.
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 before it can start servicing requests.
Vault does not store the generated master key. Without at least 3 keys to reconstruct the master key, Vault will remain permanently sealed!
In other words, whenever Vault is started, at least two unseal keys will be required in order to make the service become available and ready to use. While sealed, the files that store the actual secret values will remain encrypted and inaccessible.
Initialize vault to get the keys.
# vault operator init
Unseal Key 1: 4xjTuHT0QkRlNB0SpnU0yDAKBnV8LZ0VN6p4AVnCjrO1
Unseal Key 2: eUJE/s0pVGVchUadEULjCW79/5KvHTWsx8IJUA9qSIQO
Unseal Key 3: l+1u3IAf4onSXf0Sw2yHKCYLNaZuNFhGU7DWYpUi4IAq
Unseal Key 4: DhZGuQ/h40lbDot2pjIYWIlyIZK3fAaCjcw5Igu5RwHj
Unseal Key 5: fSnifdFn+c6Lt2lGWJ6J+OkIdA3aeQKnr92b7maVmsV4
Initial Root Token: s.npH4sTI4nYYlddUMmmy9o6rS
By default, vault will be sealed. It should be unsealed with minimum of three unseal keys as shown below.
To check the status,
# vault status
Unseal Key (will be hidden):
Key Value
— —–
Seal Type shamir
Initialized true
Sealed true
Total Shares 5
Threshold 3
Unseal Progress 2/3
Unseal Nonce 7d7d76b8-fa2f-20f4-9162-4614d44246aa
Version 1.4.2
HA Enabled false
Now, run the unseal command with 3 different key we created in previous, to unseal
# vault operator unseal 4xjTuHT0QkRlNB0SpnU0yDAKBnV8LZ0VN6p4AVnCjrO1
# vault operator unseal eUJE/s0pVGVchUadEULjCW79/5KvHTWsx8IJUA9qSIQO
# vault operator unseal l+1u3IAf4onSXf0Sw2yHKCYLNaZuNFhGU7DWYpUi4IAq
Once you ran 3 times successfully, you can see the status sealed will be set to false.
# vault status
Key Value
— —–
Seal Type shamir
Initialized true
Sealed false
Total Shares 5
Threshold 3
Version 1.4.2
Cluster Name vault-cluster-d5421235
Cluster ID fce4a682-1fe7-0558-fe20-340421ced668
HA Enabled false
Note: Every time you restart vault or if it gets restarted during server restarts, you need to perform the unseal operation using the same unseal key.
You can also access the vault UI on port 8200 of your vault server.
You can replace with your IP, login with token root key which we created with init.
You can check secrets, access policies and access method, in coming articles will see how we can create secret, policies etc.
