Best Practices as Code with Terraform Sentinel

Toward the mention of "Coding Best Practices," what comes to your mind? As for me, I immediately consider coding best practices, such as writing neater, cleaner, and more efficient code. Though we all have definitions, we can all agree that best practices are essential to our code, deployments, and infrastructures whenever possible.

Our focus today is to inspect the infrastructure management tool Terraform, and how its Sentinel Policies feature can help us apply best practices to our infrastructure deployments via Terraform.

To start, let's refresh ourselves on Terraform. Terraform is an open-source Infrastructure-as-Code (IaC) tool crafted by HashiCorp. It enables you to define and compose infrastructure resources as code and then deploy anywhere you desire, whether Cloud or On-premises.

One of the best aspects of Terraform is that it is Cloud-agnostic. In addition to Cloud, you can use Terraform to deploy resources to any platform if a provider is available. A provider in Terraform is a wrapper written on top of platform-specific APIs that Terraform can use to connect to the platform. Thousands of providers are available on the official Terraform registry. 

What are the Three Core Stages of Terraform?

• Write – Write your code in HCL (HashiCorp Configuration Language) to define what resources you want to create.
• Plan – Terraform creates a plan based on your written code, showing you what infrastructure resources it will create, update or destroy.
• Apply – Once you have approved the plan and the changes, you can give Terraform the go to deploy the resources on your specified platform.
  
  

What are the Benefits of Terraform?

1. Multi-Cloud Deployment – Terraform enables you to deploy resources on multiple platforms, which leads to increased fault tolerance and quick recovery.
   
2. Resource Management – Terraform manages updates to the resources and tracks them throughout their lifecycle, in addition to deploying them. It also allows you to monitor the resources.
   
3. Parallel Environments – Terraform enables you to deploy the same code across different environments, which is helpful, especially when testing new code. A temporary environment can be easily spun up, tested, and destroyed when no longer needed.
   
4. Custom Providers – Terraform has official providers for most platforms, such as AWS, Azure, Google, etc. Still, as a user, you can also write your custom providers to be used with Terraform.
   
5. Policy Compliance & Management – Use Terraform to set up policies that can control how resources are deployed from Terraform. This is the Terraform Sentinel Policies feature.
   
   

Terraform Sentinel Policies

Let's examine what Sentinel is about. Sentinel is a language and framework designed by HashiCorp, allowing us to write logic-based and straightforward policies/rules as code. Like Terraform implementing Infrastructure-as-Code, Sentinel implements Policy-as-Code. A policy can be any standard or rule that governs the deployment of Terraform resources defined in Terraform configuration files.

Sentinel policies are available in both the Terraform Cloud and the Terraform Enterprise solutions offered by HashiCorp. We will refer to Sentinel policies concerning Terraform Cloud as the same holds true for Terraform Enterprise. These policies are added at the top level (called an organisation) as single or separate policies or can be combined into a set. The policies in a policy set can be accessed by storing them in a version-controlled system (VCS) and connecting the VCS repository with Terraform Cloud.

Sentinel policies can be available to all or specific workspaces on Terraform Cloud. The policy check runs after a Terraform plan (a Terraform plan detects new changes to deploy) but before a Terraform apply (an apply implements the changes detected in the plan step), ensuring that resources will only be created if the policy passes.

This approach is better than documenting rules and regulations in a file because the policy check is an automated part of your deployment process. You don't have to worry about going back to check every rule in a file whenever a new resource is created.

To understand how Sentinel works, let's take an example. Suppose we add a rule that any AWS S3 bucket created from Terraform must have versioning enabled. We can write this policy in Sentinel language. The policy will access the Terraform plan generated, the state at that time, and the resource configuration defined in Terraform code files. The policy will then deduce if a bucket is being created or not; if yes, it will check whether versioning is enabled on the bucket. If versioning is enabled, the policy check will pass, and we will move on to Terraform apply. If the policy fails, we have several options for how to proceed. We can set the policy as a warning, override it, or let it fail the entire run.

Sentinel Policies Features

• Policy-as-Code –  Define policies in the area of security, compliance or operational best practices as code.
  
• Sentinel Language – Sentinel language was designed for non-programmers, making it easy to learn and understand. Syntax-wise, it resembles scripting languages such as Python or Ruby.
  
• VCS Integration – Sentinel policies can be coded and committed to version control, and we can connect the version-controlled repository directly with Terraform Cloud to access the policy sets.
  
• Enforcement Level – Sentinel policy checks do not have to be all or nothing.

For example, you can classify three different levels of enforcement.

1. Hard-Mandatory – If a policy check fails, the whole run will fail, and the apply stage will not run.
2. Soft-Mandatory – If a policy check fails, the run will not proceed unless someone with sufficient access approves the run to move forward.
3. Advisory – If a policy check fails, it will show up as a warning, and the run can still proceed.
   
   

Sentinel Policies Benefits

• Availability– Other than Terraform Cloud and Terraform Enterprise, Sentinel policies can be used with every significant HashiCorp product, such as Consul, Vault, Nomad, etc.
• Automation– No need to manually check every resource to ensure it follows best practices. Sentinel does the job for you.

Final Thoughts

Having delved into the intricacies of Sentinel, stay tuned for our next blog, where we'll explore its role in enhancing security, compliance, and operational best practices in our cloud deployments. 

If you're looking to delve deeper into Terraform or implement it into your company, DEMICON's cloud specialists are available to provide assistance. Discover how we can support you by clicking here.