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.

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.

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.

During the Go Essential Training course on LinkedIn, the instructor sets up a problem for you to solve. The solution is in the next slide of the course, and mine was ever so slightly different anyways, so I doubt that this needs to come with a spoiler alert, but anyways… An even-ended number is one that starts and ends with the same digit. That is to say 1, 11, 121, and 10103921 are all even ended numbers as they all start and end with the same digit.

Now that I have I have set up a sort of a learning plan to plug some gaps in my knowledge that I always wanted to plug, but didn’t have the time to do properly. Mindful that I have an opportunity for learning without external influences on my time, but also that my Daughter only has Kindergarten until lunchtime every day, I really only get the morning before the family time kicks in.

So I bought my ACI bundles so long ago that they’re still running 1.0(3f). Right now mainline is 1.2(1k), so i’m a bit behind. Using the official Cisco doc I did the first staged upgrade from 1.0 to 1.1 using the Web GUI. I wanted to see what happened in a visual sense. Basically you setup a connection between the APIC and a host that has staged the firmware files, then you setup a policy defining what versions the fabric should be on, and when that should be made active.

ACI brings with it many different constructs for operating networks, some of which have analogous equivalence with classical networking, some of which are literally bat-poop crazy. As per usual, you can find lots of resources on how to structure ACI fabrics elsewhere, i’m not going to waste time on what you can do and focus on what I am going to do (roughly). The below Image was unceremoniously stolen from Cisco themselves, in the critical read ACI Fundamentals

Starting yesterday I began to deploy our Nexus 9000 ACI solution into our Datacentre. Scary yet fun times are ahead. Over the course of the project I will do my best to chronicle anonymised info that talks about what we did and how we did it. Some of that may be of use to another ACI hopeful, whereas some will be pretty specific to my environment. One thing I won’t be doing is reinventing the blogging wheel, and I will chose to refer to others that helped me, rather than rehash the same subjects over and over again.

So by now you can use SoapUI and Python to read info out, and can utilise SoapUI Test Cases to validate, and deliver changes to the CallManager system. Again, please do ensure you have reviewed parts 1-3 before entering into this post. Its entirely contextualised within the series. Up until now what we have been doing is quite focused on a single object being added or sense checked. In this, the final post in this mini series we will be looking at an end to end python script that can be used to add a new end user to the system, with pre and post validation.