This is a post I’ve wanted to write for a while, but was one of those side projects I’ve picked up and put down a few times due to other priorities getting in the way. This idea came about because I wrote a PowerShell script to perform some housekeeping actions in Azure and I wanted it to run unattended on a scheduled basis.
Continue Reading...I have already touched on the importance of Terraform state in a previous post, but I wanted to expand on this from a security perspective.
Let’s get this out the way now, Terraform stores secrets in its state file in plain text! There I said it.
So how do I protect against secrets being revealed that could allow an attacker to compromise my systems? Well, I use a defence in depth strategy in a number of ways.
Continue Reading...In a previous post I explained why I don’t advocate the use of child modules, but I wanted to quickly explain how I keep Terraform admin overhead to a minimum when creating standard resources whilst also working with the constant rate of change that cloud brings.
Continue Reading...Terraform uses the construct of a module, which is defined by HashiCorp as “a set of Terraform configuration files in a single directory”.
The root module consists of resources defined in the main working directory (which I like to refer to as the ’execution folder’). However, you can also call other modules to include their configuration. These are known as child modules which can be shared and reused by multiple root module configurations. Sounds good, doesn’t it?
This is something I’ve only recently discovered but thought it was worth sharing here.
I have a few configurations where I need to pass JSON to Terraform to process. The most used resource where I do this is azurerm_virtual_machine_extension. The example HashiCorp documentation still shows the use of Heredoc strings which is probably why I hadn’t picked up on it until now.
I recently discovered a HashiCorp article where they tell you that by using the jsonencode and yamlencode functions “Terraform can be responsible for guaranteeing valid JSON or YAML syntax”. This sounded good to me as JSON syntax is not very forgiving, and it is designed to be read and processed by machines (not humans). If you put a comma or a bracket in the wrong place, you will soon be in a whole world of pain. The same is true for YAML and indentations.
Continue Reading...