This is a continuation from my previous three posts (Part Zero and Part One and Part Two) about the need to have automated way of storing and pull LUKS keys for my servers.
For this section we are going to look at getting vault configured ready for use. This means we are going to look at initialising Vault, getting the operator keys and unsealing etc.
You can either do this on the vault server itself or on a local machine. If you are using a local machine then you need to download the vault binary (if you havnt already done so) and put it in a place thats in your path. You will also need to add the VAULT_ADDR to your .bashrc and source it.
1
2
echo "export VAULT_ADDR=http://192.168.0.194:8200" >> ~/.bashrc
source .bashrc
Getting started with Vault
The very first thing we need to do is initialise Vault. This will give us our 5 operator keys along with our root token.
Run the following:
1
vault operator init
That will output a bunch of text that looks similar to this:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
Unseal Key 1: qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
Unseal Key 2: wwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww
Unseal Key 3: eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
Unseal Key 4: rrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr
Unseal Key 5: ttttttttttttttttttttttttttttttttttttttttt
Initial Root Token: y.yyyyyyyyyyyyyyyyyy
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 key to
reconstruct the master key, Vault will remain permanently sealed!
It is possible to generate new unseal keys, provided you have a quorum of
existing unseal keys shares. See "vault operator rekey" for more information.
So, firstly, you need to make a copy of that data. This will be the ONLY time you see this.
Print it out and store it somewhere secure or something. (just dont store it in vault itself!!!)
Also, read the entire output. You will see the 5 keys there, when we come to unseal the vault we will need 3 of those to be able to unseal. It doesnt matter what order or which keys just that we need 3 of them.
The root token allows us to interact with vault while we have no users setup on there. In an ideal world once we have added an Admin policy and added users to it, we would destroy any evidence of that root key.
Unsealing the vault
Now that we have those keys,we can unseal the vault. If you do a vault status you will see its sealed:
1
2
3
4
5
6
7
8
9
10
11
12
[root@vault1 ~]# vault status
Key Value
--- -----
Seal Type shamir
Initialized true
Sealed true
Total Shares 5
Threshold 3
Unseal Progress 0/3
Unseal Nonce n/a
Version 1.2.3
HA Enabled true
Also note the unseal progress, as we go through the following process that count will be bumped after each successful unseal attempt until we hit the magic number of 3.
run the following:
1
vault operator unseal qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
Obviously replacing the qqq with one of your keys, then run vault status again, you will see it shows 1/3:
1
2
3
4
5
6
7
8
9
10
11
12
[root@vault1 ~]# vault operator unseal qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
Key Value
--- -----
Seal Type shamir
Initialized true
Sealed true
Total Shares 5
Threshold 3
Unseal Progress 1/3
Unseal Nonce d826467f-a82a-cb8d-bc9a-d972afc83edf
Version 1.2.3
HA Enabled true
Do it again with 2 more keys. This will then unseal the vault.
Now lets create a username and password so we can login:
1
vault write auth/userpass/users/jon policies=default password=super-secret-password-hunter2
You essentially have vault ready to use now. You still need to work on policies to allow that user to do anything, along with creating backends to store your secrets in.
Create a KV Store
I actually used the UI for this. Login via port 8200 on one of the vault servers and login using that root token we copied from the initialisation output.
Go through the options of enabling a new engine, selecting KV and give it a name then save it. You can also add secret in there so we can test.
Now lets create a policy to test it all.
This can get complicated, especially when you are just learning. I had trouble getting the paths correct in the policy at first. But i believe after some trial and error you will get it working.
Policy
On the Policies page i created a new policy named kv-secrets with the following content:
1
2
3
path "kv/data/secrets/*" {
capabilities = ["create", "read", "update", "delete", "list"]
}
So anyone with this policy on their acount will have those capabilities on the path /kv/secrets (secrets is the name of the kv backend i used).
Now you just need to attach this policy to the user. You will essentially be recreating the user, but just adding in an additional policy:
1
vault write auth/userpass/users/jon policies=default,kv-secrets password=super-secret-password-hunter2
Your user should now be able to access the secret stored there:
1
2
3
4
5
6
7
8
9
10
11
12
13
[jon@jons-laptop ~]$ vault kv get kv/secrets/test
====== Metadata ======
Key Value
--- -----
created_time 2019-11-05T21:45:45.903943859Z
deletion_time n/a
destroyed false
version 1
====== Data ======
Key Value
--- -----
password testing
I wanted this to be the last post in this series, but i think i have gone on long enough for one post. It is worth experimenting around with storing stuff and retrieving it and also playing with the policies, just to become more familiar with it all.
The next post will go through setting up vaultlockerwhich is the script used to do the automagic encryption etc.