First Look into… HashiCorp Sentinel and Policy-as-Code (Part 1)

I recently came across a video from Kyle Ruddy (formerly at VMware, now at HashiCorp, Microsoft MVP and automation rockstar) where he was walking through a HashiCorp product I hadn’t yet played with: Sentinel.

Naturally, I got curious and started to look into it. I find Anything-as-a-Code interesting and I liked the overall potential of Policy-As-A-Code.

Why Policy-As-A-Code?

Well, if you look back through my previous Terraform posts, I would have talked about how describing infrastructure as code provides benefits such as:

• Consistency
• Tracking and versioning
• Templating
• Re-usability

The same apply if you want to describe your policy as code. But what does a policy even mean?

A policy is “a course or principle of action adopted or proposed by an organization or individual”.

Let’s consider this in more practical terms in the context of policies with infrastructure-as-code (Terraform).

The policy could focus on various aspects, such as:

• Operations
• Business
• Security
• Cost
• Resilience and Availability
• Standards

More practically – a policy, in the context of Terraform, could be defined to:

• Ensure that a disk of an EC2 instance is encrypted at rest.
• Ensure that an application is deployed across multiple availability zones.
• Check that a service is deployed in the correct region.
• Ensure that the cost of an application is under control – for example, ensure an EC2 instance is a low-cost t2.micro instead of a mega VM such as an c5.4xl.
• Ensure that a user doesn’t deploy 500 VMs in one go.
• Provide additional Role-Based Access Control (and we’ll see how we can use it for something like VMC).
• Forbid changes to be done during business hours.
• Ensure all resources are tagged for billing purposes.
• Validate the values & variables used by the operator meet a standard or naming convention.

If a policy is defined as code, it can be templated and used and re-used across environments, customers or entire industries. You could build a code representing a security policy or compliance – let’s take for example PCI – and then apply it across any customers who would have cardholder data.

Sentinel

Sentinel is a policy framework embedded with the HashiCorp products (Nomad, Vault, Consul and Terraform) to apply these security, compliance and business policies. Again, I will focus on Terraform as I’m most familiar with it.

Caution: Sentinel is only available for Terraform Cloud (premium accounts) or Terraform Enterprise. This means it’s not as widely used as some of their other products and therefore there are few blog posts or examples available (which is one of the reasons I’m writing this one).

In simple terms, Sentinel works with Terraform to ensure Terraform deploys resources according to a business, security or operational policy (such as the ones I described in the previous examples).

Sentinel supports different level of enforcements:

• hard enforcement (the Terraform config or expected results of a Terraform deployment does not meet the expected policy and therefore Terraform will be blocked)
• soft enforcement (the Terraform config or expected results of a Terraform deployment does not meet the expected policy – Sentinel will tell the user about it but the user can acknowledge the alert and override the policy decision).
• advisory (the Terraform config or expected results of a Terraform deployment does not meet the expected policy but Sentinel will let the user progress through the Terraform apply)

When does Sentinel enforce it? Well, it’s between “terraform plan” and “terraform apply” – essentially between when Terraform works out what changes need to be implemented and when Terraform goes ahead and deploys these changes. So Sentinel is built-in within the implementation process.

Sentinel in Action

Let’s walk through the demo with a concrete example.

What if you’re using VMware Cloud on AWS and deploying SDDCs as code using Terraform for VMC ? You might want to specify in which regions you deploy the SDDC (I’ve had customers deploying SDDCs in the wrong region – it happens to the best of us), perhaps because you want the VMware environment to be close to the users or because you want to make sure data stays within a specific country for compliance region.

As mentioned earlier in the blog post, Sentinel is only available with the Enterprise / Cloud products of HashiCorp. As I have access to a Business Terraform Cloud org for the webinars I recently presented, I got the opportunity to test this.

First, you need to link your organization to your GitHub/GitLab account where you would store your policies (the next blog post will walk through the policy syntax)..

Imagine that the user now wants to deploy an SDDC via Terraform but selects Frankfurt as the region in which to deploy it. Imagine also that the company can only deploy SDDCs in London (due to compliance reasons).

The policy I have described earlier will fail. It’s a “soft fail” so the user can still override it.

Let’s not override the decision – instead let’s discard the run and go to the variables. Then, when we change the region to London (EU_WEST_2)…

..once we run Terraform plan again, all policy checks pass successfully.

The full demo can be found here (with audio):

How does Sentinel actually work?

How does it work under the hood? How do you actually write the policies? That’s what you will find out in Part 2.

Thanks for reading.