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.
Pretty much everywhere you go in vault you will find you need a few building blocks to make anything work.
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.
Recently I have spent a reasonable amount of time in Hashicorp vault. As part of a mini series on how to make better use of it in Network Automation, I started writing this as a “intro” to a post on the subject.
As per usual with me, it ended up being so long that it had to be its own post. So. Here you are.
Some of you might have opinions about Hashicorp and their licence changes. I do not (either professionally nor personally), compete with Hashicorp, and so it is my understanding I can use their products in an opensource sense. If you feel differently, feel free to use openbao.
Over the last two years or so, I have been on adventure with Data Centre Infrastructure renewal. As past posts may allude to, ACI was a big part of what we did, but before anyone gets all dogmatic about it, know that we didn’t go “All in” with that one product, since I personally don’t subscribe to the “DC Fabrics cure all ills” mantra.
CLOS fabrics and the various approaches to overlays within them are great at providing stable platforms with predictable properties for speed, latency and scale. Unsurprisingly, they go on to do a great job in server farms that can make the best use of that flexibility. During recent conversations on DC refresh, our Arista friends have been extremely keen to try and get us to run our Internet BGP border on the fabric as well. The 7280SR2K can handle 2M routes in FIB they say, just lob stuff into a VRF, bit of policy and voila. Yeah.