I am looking forward to the general availability of Terraform Policy in HCP Terraform. It’s not that I dislike Sentinel, but coding Sentinel policies does make your head hurt a little bit. I get the same feeling when I write policies in Rego (OPA).
By the way, speaking of Terraform Policy: in an earlier blog post (see below) I outlined an example policy. That policy does not work after tfpolicy version 0.0.3. The policy does cross-provider decisions, which is currently not supported - but hopefully will be later on.
There is a big fundamental issue that Terraform Policy is not addressing. This is not addressed by Sentinel or OPA either. The same thing can be said for OPA policies on Spacelift Deploy.
The issue I am talking about is when policies are applied. Most of these policies require a Terraform/OpenTofu plan output to base their decisions on. Terraform Policy has some policies that are applied even before you run terraform init, but they still execute in the context of a Terraform run.
What I would like to see are policies that gate the entire API surface, so that no matter which way you call an API the policy is applied. This is exactly what goes on with Azure Policy. You configure a policy and it will be applied for Bicep deployments, Terraform deployments, UI ClickOps operations, CLI commands, or just plain API calls with cURL, or any other way you can think of. Azure Policy is extremely powerful!
One issue that I have on HCP Terraform is that I want to allow teams to have high privileges within their own project while at the same time restrict them from doing certain operations. For instance, they should not be able to remove tags from a project or create workspaces willy nilly. This combination of requirements mean I can’t actually give teams admin access to their project (at least not directly), because being an admin on a project means you can do the above things and more. The workaround is to assign the team lower permissions, but give them access to a team token that has admin permissions and then combine this with policies that restrict what this team token can do. It is far from ideal.
This is an issue because the ideal world where nobody uses a graphical interface and instead use infrastructure as code to apply all their changes is a utopia that we will likely never reach (famous last words). Users will click their way around a UI, and they will do things your policies try to prevent them from doing. So naturally the policies shouldn’t only apply in the ideal case of a terraform plan and terraform apply.
I know Spacelift has some policies which apply in other contexts. For instance, login policies is used for policy-as-code authorization to the Spacelift Deploy platform.
We need more policies that are applied outside of the Terraform workflow. Look at how Azure Policy works and take inspiration from that, except for the JSON syntax - that we can do without.
