Well, this has been a bit of a rabbit hole. I published Part 1 here and thought I would quickly smash out the rest of the posts around it. Alas I got carried away and managed to get an MVP that is a bit rough round the edges but seems to function well. So without further ado here is part 2 - where I plan to detail using the persistent top level flags in conjunction with viper and how I approached the scanning of Terraform files.

Flags Precedence​

I wanted to be able to be very flexible with flags in my application and have multiple ways to define them to fit the various use cases. The flow should be:

Design decisions are a double edged sword. In one instance they give clear guidance as to why something is like it is. On the other they serve as a shield as to why something has been implemented in an a less than ideal manner :) Invariably as engineers we bump up against both sides of this coin. One particular example of this was recently operating with terraform. The design decision was "identity is the perimeter". Fair enough but this led to UPNs of users being used in terraform code and as the inevitable churn occurred then pipelines would break. The problem already has a solution and that is to front calls to groups and populate groups with users. Alas this was an abstraction too far for the powers that be but the upshot of this is it gives us an excuse to play around with Go and over engineer a solution to the problem :)

So my first blog post here was mainly there as the first idea I had had for a blog. Logically I probably should have started with this one which details the journey I have been on to onboard my shiny new domain, ADO env and azure account in to Terraform. My aim here is to not let it all descend in to a GUI nightmare and to codify all the things because, well, IaC and automation are bloody brilliant.

Tricky Parts​

Much as I love Azure I have a slight frustration with it in terms of being heavily GUI driven. Overall it seems much more forgiving than AWS but it does sometimes get in the way a bit. The prime example of this is with Subscriptions. When you onboard a shiny new trial you automagically have a subscription spat out for you. This is nice but it has a horrible name - which needs 10 minutes to sync changing - and it also does not have an alias which is a key bit of metadata for terraform to handle managing this subscription.

The big brain box that is Jamie McCrindle wrote an excellent blog on how to handle secret rotation within Azure using terraform. This served as the cornerstone for our service principal rotation mechanism recently and everything was fine and dandy right up until it wasn't.