In the last post we put a certificate from an offline certstrap CA on the Vault listener, so clients can check that Vault really is Vault. This one is the other half, and the last post in the Vault series: using certificates the other way round, to prove who you are, with the private key sitting on a YubiKey.

Vault’s cert auth method lets a client present a TLS client certificate instead of a password or a token, and Vault turns that into a short-lived token with a policy attached. The user-facing half of this is done with yubivault, a small tool that logs in to Vault with a client certificate and prints a token. This post is the “why and how it fits together” version of the PKI-SETUP.md guide in that repo.

This post and the next one wrap up the Vault series, and they are where I pay back a debt. Way back in the bootstrap post I looked at the docker setup and said I would want TLS on something “real”, but that it was “a level of faff i’m not up for today”. Well, it is today. We have spent a lot of posts putting things into Vault (primitives, python, ansible, PKI, audit, transit), all of it over plain HTTP, which is a bit embarrassing for a secrets store.

As we come towards the end of this mini series, we talked about how to bootstrap a hashicorp vault for non-prod use, what primitives vault uses for secrets management, and how to talk to vault from python.

Here we will dig into how you can access vault content within an Ansible workflow, ensuring you never more have the pain of managing secrets with ansible-vault, or worse, storing them plain text in a repo somewhere.

It’s remarkably easy to get sucked into hardcoding things that probably should live outside your code.

It is clear to many of us that storing secrets anywhere that isn’t vault (or something like it), is a terrible practice. It is also true that the best laid plans of mice and men aft gan aglais.

In other words, the problem is rarely that we don’t want to do secure coding, its that we lack the time, talent, or awareness to do this right. Don’t dwell on that too much either - its just how the world works.

Some Vault Primitives

Pretty much everywhere you go in vault you will find you need a few building blocks to make anything work.

Env Vars

Regardless of how you choose to talk to vault (CLI/WebAPI/SDK), you will find that the most common way to “encode” the vault settings is in an Environment variable. This is a nod towards its “cloud native” upbringing, where config files are the devil or something.