When Hashicorp introduced Terraform Cloud, I was already accustomed to Oracle’s Resource Manager offering and even though I was a not a big fan of this managed service approach, I still gave it a chance.
There were some things that I really liked, that I believe, will help you decide if you want to adopt Terraform Cloud in your organisation or not.
Sentinel Policies
One of the most interesting things that Terraform Cloud has are Sentinel Policies. With these policies you can control what users can create, how they can create it and even what modules they are using. They always run after a plan, but before an apply. If you like this behaviour, but you are not using Terraform Cloud, you can check Open Policy Agent.
There are three types of enforcement levels:
- hard-mandatory → If a policy fails, you can’t run the code at all
- soft-mandatory → If a policy fails, you can run the code if your user has enough rights
- advisory → If a policy fails, you will only be notified, but the code runs as expected
You are going to write these policies using Sentinel language, but don’t worry, it’s not that hard to understand how it works. You can refer this github repository for some examples and how to put it in place.
Just split the policies in sentinel files that make sense and don’t worry about the enforcement level just yet. All of these files should be hosted in a git repository as you will need to pass those out
Example of sentinel policies
The enforcement levels are going to be set inside of the sentinel.hcl file.
Example of policy restrictions
Integrating the policy repository to Terraform Cloud is pretty straight forward, you can simply follow this.
Run Tasks
Another interesting thing that Terraform Cloud offers are Run Tasks. Basically, these are just third party tools that can be integrated with Terraform, that will be running before the apply.
There are a couple of third party tools that can be integrated as Run Tasks right now, but judging by the fact that this feature exited beta two months ago, I am a pretty sure the list will expand fast. A couple of these are:
- Snyk → This scans for code vulnerabilities
- Bridgecrew → helps with addressing security and compliance errors
- Firefly → prevents service disruptions and improves cloud governance
If you want to learn more about run tasks, you can look into this.
Access Control
In Terraform Cloud, I appreciate the fact that you can easily achieve access control based on permissions set on the user / team level.
There are 4 default levels of permissions:
- read → view different components
- plan → read + queue plans on workspaces
- write → plan + apply code, change variables, lock / unlock workspaces
- admin → full power
You can even have custom level permissions: you may want a user to be able to change variables, but not to be able to apply the code. For more information, you can check this.
There are also workspace level permissions available. Let’s suppose Team A doesn’t have write permissions inside of the organisation, but you want them to be able to manage a workspace called Workspace A. This can be simply achieved by giving them admin workspace permissions on the workspace level.
I saved the best (in my humble opinion) for last. There is also a Terraform Cloud provider available, so you can easily manage all Terraform Cloud Resources from Terraform itself.
You can build the Terraform Cloud environment for your team, by building modules and calling those up in pipelines and using remote state. This is pretty convenient as you don’t have to be 24/7 in the console.
Apart from this, whenever you do a change to the repo specified in the Workspace, Terraform Cloud will catch that and it is also able to auto-apply that code if you want (and of course, if it passes all sentinel policies and run tasks).
For more details, you can check the Terraform TFE provider documentation.
Conclusion
I’ve spoken about the things that I like, but let’s cover some of the things I don’t. Similar to OCI Resource Manager, it is pretty hard to manage complex variables in the Terraform Cloud Console, and for someone who is an advocate of those and for_each loops, this can be very annoying.
In addition to this, I don’t feel the need of using Terraform Cloud at all in a small team, where only two to five people are running Terraform code.
There are three types of API tokens in Terraform Cloud:
- User Token → has the same level of permissions as the user
- Team Token → has the same level of permissions as the team
- Org Token → can create teams, but can’t apply code in workspaces
If you want to automate the creation of teams, for example, and in your automations you want to avoid using user tokens, tough luck, there is no way to create teams and keep the state in a terraform cloud workspace without using both the Team and the Org token.
This is happening because a team cannot manage team creation even if it has all the permissions enabled.
There are many other interesting features that Terraform Cloud offers like Variable Sets, Integrations with Services Now and Agent Pools, but I would encourage you to check those out.
To sum it up, I believe Terraform Cloud can really help when you have many developers that are running Terraform in your organisation, but for me, I feel it is just not worth the overhead for a small team.
If you want to check out an alternative to Terraform Cloud that doesn’t belong to a Cloud Provider, you should totally look into Spacelift.
More information related to it here.
