I thought i was done with this series, but there are a few loose ends that I think we can clear up pretty quickly. The most important of which is Audit Logging, because what is the point of a secure secrets tool if you don’t track who does what (or most importantly, fails to do what) with it. Lets jump in!

Enabling audit logs

Enabling audit logging requires you to tell the vault server that it should use one of the audit “device types” that it offers with the required parameters. The system will then send audit events to all defined devices, and will consider the audit entry a success when at least one confirms the write.

Abstract

Now that we have a Vault, with a TLS Issuing CA, and some idea of how to get certs out of it, lets look at how we can use this in a “real” world scenario to put a valid TLS profile onto a Network Appliance (fancy word for a switch I guess).

Why did I say appliance, and not Router or Switch? Weeeeeell, think about it. You manage a lot of network stuff over HTTPS protocols these days, even when its not actually a web interface you are using to do it. We can also manage load balancers, Wireless Controllers, NAS devices etc etc etc. Lets not get bogged down in terminology and accept that network kit comes in all shapes and sizes these days. Trusted TLS is the goal here.

abstract

Following on from the Hashicorp Vault “how-to” series. Lets dial things up a notch, and setup a PKI in vault that can issue “real” certificates for your devices.

This has a couple of real tangible benefits.

1. No more verify=false and/or urllib hacks to connect to TLS secured endpoints
2. No need to fight openssl to wrangle self signed (or for the really brave, a manual CA)
3. Full automation support to enable estate wide renewal in minutes, not half a lifetime.

Much of this content was abstracted from the Original Hashi docs, which are brilliant, and can be found here.

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.