Hashicorp Vault
A developer’s guide to setting up Vault in kubernetes and using it with kv-store for secrets and userpass access.
In this brief write-up, I shall try to provide a quick way to get Vault up and running from a running GKE cluster.
Installation
Installation of vault can be simplified using helm. There is an official helm chart for this at https://www.vaultproject.io/docs/platform/k8s/helm
Step 1: Add the helm chart. Please note helm 3.0 is recommended.
helm repo add hashicorp https://helm.releases.hashicorp.com
Step 2: Installing the chart.
The default installation might work fine for most people. In my case, I use GKE and I use nodeSelector
to enable using the right node for deploying the vault service.
Also I am using a single node vault for this post.
$ cat config.yamlserver:
nodeSelector: |
node-type: vault$ helm install -f config.yaml vault hashicorp/vault
In the above snippet, I use a nodeSelector called node-type: vault
and I am installing to the default namespace (based on my kubernetes configuration). The matching label is shown below from GKE.
Starting up
If all went well, one would see the following. On a side note, don’t worry if the pod/vault-0
does not show as Running
. Most likely, it wouldn’t and I took this screenshot after I had gotten it up and fully running 😁
In order to have vault up, one needs to connect to connect to the shell of vault-0
pod and initialize it to unseal the Vault
. Please note, I have blacked out the Unseal keys from my screenshot.
The idea is to run vault operator init
to get five of the unseal keys to be safe-kept.
Please note: Three of the five keys are required whenever the Vault is restarted.
To unseal vault operator unseal
is used.
Using Vault
Once three keys are provided, the vault would be accessible using the GUI. Please use the initial root token
mentioned above to login (using token as the method of login).
Once in, we need to create a key value path
. In order to do that, we need to select Enable new engine
. I shall attempt to do a screen-walk-thru to describe with less words.
Once saved, I would have a secret mypath1\path1
created, I can try to access this using REST API.
curl -H "X-Vault-Token: $VAULT_KEY" localhost:8200/v1/mypath1/data/path1 -s | jq
In a real-world scenario one may not use a root token but may have other means of authentication to generate a token.
The Vault GUI can be used to create a user
Note, “token” is an authentication method that is added by default. Once, a username / password is added, one can generate a client_token
for it using REST API.
curl localhost:8200/v1/auth/userpass/login/test_user -d '{"password": "test"}' -s | jq
In order for the above user to be able to access the secret, one needs to create a Policy to enable fine-grained access to a hierarchical resource. For more info, please refer to https://www.vaultproject.io/docs/concepts/policies#policy-syntax
For the above example, I have added a policy below that allows to perform CURDL operations on the secrets in its hierarchy.
path "mypath1/*" {
capabilities = ["create", "read", "update", "delete", "list"]
}
Once, the above policy is created, it’s linked to a user / auth method by adding an entity in the screen like below.
One can use Vault CLI / Vault REST or Vault GUI to perform most of these operations. As indicated I am trying to wear a developer’s hat, where I am attempting to perform CURDL operations on secrets using REST API and others from a GUI.
Comments / Suggestions welcome. Thank you for reading this post and helping me learn about this topic.