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.


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

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

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