In the previous article we configured Vault with Consul on our cluster, now it’s time to go ahead and use it to provision secrets to our pods/applications. If you don’t remember about it or don’t have your Vault already configured you can go to Getting started with HashiCorp Vault on Kubernetes.
In this article we will actually create an example using mutual TLS and provision some secrets to our app, You can find the files used here in this repo.
As we see here we need to enable kv version 1 on
/secret for this to work, then we just create a secret and store it as a kubernetes secret for myapp, note that the CA was created in the previous article and we rely on these certificates so we can keep building on that.
In Kubernetes, a service account provides an identity for processes that run in a Pod so that the processes can contact the API server.
Then we need to set a read-only policy for our secrets, we don’t want or app to be able to write or rewrite secrets.
Set the environment variables to point to the running Minikube environment and enable the kubernetes authentication method and then validate it from a temporal Pod.
If you check the volume mounts and the secrets we load the certificates we created initially and use them to fetch the secret from vault
This is where the magic happens so we’re able to fetch secrets (thanks to that role and the token that then will be stored there)
And last but not least we create a file based in the template provided which our nginx container will render on the screen later, this is done using Consul Template.
The last step would be to test all that, so after having deployed the files to kubernetes we should see something like this
This post was heavily inspired by this doc page, the main difference is that we have mutual TLS on, the only thing left would be to auto unseal our Vault, but we will left that for a future article or as an exercise for the reader.
If you spot any error or have any suggestion, please send me a message so it gets fixed.