Difficulty: intermediate
Estimated Time: 30 minutes

Application deployments in a Kubernetes cluster can leverage Vault to manage their secrets. There are situations where you may have an existing Vault service that is external to the cluster.

In this tutorial, you will run Vault locally, start a Kubernetes cluster with Minikube, deploy an application that retrieves secrets from this Vault, and configure an injector only deployment to inject secrets into the pods from this Vault.

You deployed Vault external to a Kubernetes cluster and deployed pods that leveraged it as a secrets store. First, through a hard-coded network address. Second, aliased behind a Kubernetes service and endpoint. And finally, through the Vault Helm's chart and the injector service with annotations applied to a deployment. Learn more about the Vault Helm chart by reading the documentation, exploring the project source code, exploring how pods can retrieve secrets through the Vault Injector service via annotations, or secrets mounted on ephemeral volumes.

Integrate a Kubernetes Cluster with an External Vault

Step 1 of 6

Start Vault

Vault running external of a Kubernetes cluster can be addressed by any of its pods as long as the Vault server is network addressable. Running Vault locally alongside of Minikube is possible if the Vault server is bound to the same network as the cluster.

Verify the vault CLI is installed.

vault version

Wait until the vault version command returns a value.

In another terminal, start a Vault dev server with root as the root token that listens for requests at 0.0.0.0:8200.

vault server -dev -dev-root-token-id root -dev-listen-address 0.0.0.0:8200

Setting the -dev-listen-address to 0.0.0.0:8200 overrides the default address of a Vault dev server (127.0.0.1:8200) and enables Vault to be addressable by the Kubernetes cluster and its pods because it binds to a shared network.

Export an environment variable for the vault CLI to address the Vault server.

export VAULT_ADDR=http://0.0.0.0:8200

The web application that you deploy, expects Vault to store a username and password stored at the path secret/devwebapp/config. To create this secret requires that a key-value secret engine is enabled and a username and password is put at the specified path. By default the Vault dev server starts with a key-value secrets engine enabled at the path prefixed with secret.

Create a secret at path secret/devwebapp/config with a username and password.

vault kv put secret/devwebapp/config username='giraffe' password='salsa'

Verify that the secret is defined at the path secret/data/devwebapp/config.

vault read -format json secret/data/devwebapp/config | jq ".data.data"

The Vault server, with secret, is ready to be addressed by a Kubernetes cluster and the pods deployed in it.