Terraforming “Missing” Resources at Provider Level

It's very common that while terraforming some products you realize that there are some additional or core functionalities that are not yet available in the latest provider, at this particular case, AWS provider.

There are two ways to go, the first one: manually (not really my way), the second one: automate it but without breaking our terraform best practices… and this is the challenge here, our IaC standard is based on three main points:

1. Encrypting credentials and secrets at rest and in transit.
2. Using IAM roles instead of local users.
3. Using terraform workspaces, so we have just a unique template to maintain.

So basically we have created a simple orchestrator that fulfill all those requirements -> Terrax

But this is not about how we work or just to explain the benefits of our standard.. this is about the workaround we found to deploy resources that in fact are not defined at the provider level, so here we go… bear in mind 1st and 2nd points from out standard.

The best explanation is a real example, just a few context, we are terraforming AWS backup at all our accounts with a backup standard for all our products and indeed some backup exceptions which is a great manner of managing your backups at AWS, but.. there was a missing functionality at provider level, there is no available resource for SNS alarms!! a basic functionality that notify when a backup failed.

Well... this is annoying but not what about null provider? would help? yep for sure.

Here, we use aws-vault to manage the sessions, we have a master session that allow us to login to our security account which we use to assume cross-account roles, therefore meanwhile you are able to maintain a the session from the main thread you will be allowed to assume cross-accounts at shell level, great, but not enough… what if i need into a module with a conditional count, OK… that´s a problem, and what about if that module has to be call “n” times per account based on the products deployed at every account, so please see below our workaround.

First, you have to define a template into the module that will be executed at module call, we use null provider to define a dummy resource just to run a shell script.

Great, now let see how we will manage the aws-vault nesting based on temporary profiles defined at runtime at sub-shell levels :)

Remember, we use just one master profile at aws-vault, so to avoid messing it we use temporary profiles that are dynamically created at shell script execution which indeed means that we use a different aws config file for each of this sub-shell executions but maintaining main thread session.

This is great in very different ways, one unique shell script runned “n” times (due to count based on applications per accounts) with as many different cross account roles as accounts you have and all with just one key pair (access and secret key) stored locally and fully encrypted.

Of course this is a temporary workaround in the meanwhile Hashicorp add the proper resource definition :)

Hopefully this helps someone.