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

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.

Kubernetes label “vault” would match-up the nodeSelector

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 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.

Choose KV
Provide a Path to the newly created KV Secret Engine. Make sure to choose version 2.
Now that `mypath1` is created, we are ready to add secrets
Created a secret named `path` and I am using JSON values on it.

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
REST API to access my secret. Note, I am using `VAULT_KEY` from my “initial root token”

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

I have added a “userpass” as a new authentication method

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
Generate a client token for a naive “userpass” based auth

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

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.

Create an entity that enables a client token to allow access to secret

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.

Listener and reader