Securing Vault logins with client certificates

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.

[Read more]

Securing your Vault instance with TLS

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.

[Read more]

Vault Transit Encryption

This post has a weird genesis. If I think back to the first time I heard of Transit Encryption I originally thought it was something else, and when I finally understood what the docs were telling me, I thought it was the dumbest idea ever.

Turns out I was way wrong. Over the next half an hour I hope to explain why.


The point of transit encryption is to provide a mechanism for requesting vault encrypt some content for you as a service, so that you can send that encrypted blob over untrustworthy, or observable channels. The recipient can then go back to vault, and request that content be decrypted for use.

[Read more]