When developing infrastructure and using infrastructure as code (IaC), you have several choices to make before finalizing a push to production. Policy as code frameworks allow teams to collaborate and move with more agility thanks to the added confidence that comes from testing your infrastructure before you build and modify it. Moving beyond conventional code reviews or even ticket-based approval processes makes adopting an automation system like Terraform seamless while still avoiding common pitfalls.

In this blog, I introduce how to build a continuous integration and delivery (CI/CD) pipeline that incorporates Hashicorp Sentinel as a total-process tool for gaining visibility into your infrastructure, while preventing mistakes within your Terraform stacks. Before diving into policy as code, let’s evaluate the top three reasons that engineering leaders start testing their codebases and how Sentinel addresses them:

  • Preventing regression: Preventing the addition of new bugs and breaking changes when evolving an already working system is key.

  • Preventing fear: Agile teams need to be able to deploy releases incrementally, sometimes even on a minute-by-minute basis.

  • Preventing bad design decisions: Testing makes writing quality code and bringing good habits easier.

Sentinel’s policy as code

For preventing regression, Sentinel makes it easy to ensure that you aren’t destroying already-working systems accidentally. To prevent fear, policy as code can ensure that new Terraform users aren’t incorporating risky additions, such as provisioner blocks, within your codebase. Addressing the prevention of poor design, having a policy as code framework in the loop ensures that tagging and show-back are included with all new and existing resources.

To provide a simple walkthrough for getting started with testing your Terraform code, we work through how to set up a version controlled Terraform project. Then, we point a policy at your stack that works to prevent the accidental destruction of resources. This step can be especially relevant if multiple site reliability engineers (SREs) are collaborating on a stack that has a seemingly harmless merge conflict. This conflict can potentially delete a virtual cloud network (VCN) or storage bucket if the necessary guardrails aren’t in place.

For the finished product, Sentinel adds visibility between the plan and applies phases of development with the option to change the enforce level that you’re using to govern your footprint.

A graphic depicting the pipeline for the deployment.

These enforcement levels range from providing warning messages (advisory enforcement), a blockade with the option for admin override (soft-mandatory enforcement), to a straightfoward preventative measure that forces developers to go back to the code and correct the issue (hard-mandatory enforcement).

The following example shows a policy working to prevent the accidental deletion of a VCN. For this soft-mandatory policy, we see that we can override the error. In this case, the admin can decide whether the policy observation is occurring because the VCN is being deleted intentionally or accidentally.

A screenshot of the workspace showing the Triggered via UI page.

Conclusion

In summary, Sentinel is an easy-to-use policy as code framework that adds more compliance- and security-related checks to business-critical cloud resources. The language behind Sentinel, HCL, is straightforward and mailable making the adoption of policy as code easy given the large community of examples policies out there. Moreover, many of these polices are cloud agnostic so developers can use Sentinel scripts immediately and point them at any of their Terraform workspaces. To get started, fork this repo and try deploying a Terraform stack in your tenancy with tests in place.

If this process sounds great and you’re early in your IaC journey, I encourage you to run through the Learn Terraform on Oracle Cloud Infrastructure tutorial to start managing your infrastructure with Terraform.