So I did want to write about something that I discovered recently when investigating a question. The idea being Key rotation, and how TerraForm state is impacted.
So the question being this, if you have a key vault and you ask any security expert. The number one rule is that Key rotation is absolutely essential. This is important because it helps manage the blast radius of an attack, and keep the access keys changing in a way that makes it harder to compromise.
Now, those same experts will also tell you this should be done via automation, so that no human eye has ever seen that key. Which is easy enough to accomplish. If you look at the documentation released by Microsoft, here. It discusses how to rotate keys with azure automation.
Personally, I like this approach because it makes the key rotation process a part of normal system operation, and not something you as a DevOps engineer or developer have to keep track of. It also if you’re in the government space makes it easy to report for compliance audits.
But I’ve been seeing this growing movement online of people who say to have TerraForm generate your keys, and do rotation of those keys using randomization in your TerraForm scripts. The idea being that you can automate random values in your TerraForm script to generate the keys, and I do like that, but overall I’m not a fan of this.
The reason being is it makes key rotation a deployment activity, and if your environment gets large enough that you start doing “scoped” deployments, it removes any rhyme or reason from your key generation. It’s solely based on when you run the scripts.
Now that does pose a problem with state at the end of the day. Because let’s take the following code:
provider "azurerm" { subscription\_id = "...subscription id..." features { key\_vault { purge\_soft\_delete\_on\_destroy = true } }}data "azurerm\_client\_config" "current" {}resource "azurerm\_resource\_group" "superheroes" { name = "superheroes" location = "usgovvirginia"}resource "random\_id" "server" { keepers = { ami\_id = 1 } byte\_length = 8}resource "azurerm\_key\_vault" "superherovault" { name = "superheroidentities" location = azurerm\_resource\_group.superheroes.location resource\_group\_name = azurerm\_resource\_group.superheroes.name enabled\_for\_disk\_encryption = true tenant\_id = data.azurerm\_client\_config.current.tenant\_id soft\_delete\_enabled = true purge\_protection\_enabled = false sku\_name = "standard" access\_policy { tenant\_id = data.azurerm\_client\_config.current.tenant\_id object\_id = data.azurerm\_client\_config.current.object\_id key\_permissions = ["create", "get",] secret\_permissions = ["set", "get", "delete",] } tags = { environment = "Testing" }}resource "azurerm\_key\_vault\_secret" "Batman" { name = "batman" value = "Bruce Wayne" key\_vault\_id = azurerm\_key\_vault.superherovault.id tags = { environment = "Production" }}
Now based on the above, all good right? When I execute my TerraForm script, I will have a secret named “batman” with a value of “Bruce Wayne.”
But the only problem here will be if I go to the Azure Portal and change that value, say I change the value of “batman” to “dick grayson”, and then I rerun my TerraForm apply.
It will want to reset that key back to “batman”. And we’ve broken our key rotation at this point….now what?
My thoughts on this is its easy enough to wrap the “terraform apply” in a bash script and before you execute it run a “terraform refresh” and re-pull the values from the cloud to populate your TerraForm script.
If you don’t like that option, there is another solution, use the lifecycletag within a resource to tell it to ignore updates. And prevent updates to the keyvault if the keys have changed as part of the rotation.
Top comments (0)