Cloud Compliance & Management with Terraform - Creating a Business-Aware Sentinel Policy

Transcript

Hi, I'm Corrigan Neralich, a solutions engineer at HashiCorp, and I'm here to talk to you a little bit deeper about Sentinel, our policy-as-code tool for enforcing behaviors across your entire Terraform deployment pipeline.

We spoke earlier about some of the use cases, such as ensuring that all modules are sourced from your own private module registry.

This is important because, as you start rolling this out to more business units internally and you are putting this very powerful tool in the hands of more people, you want to make sure that you have automated ways of enforcing best practice, including, as an example, enforcing the usage of only pre-approved modules from your registry.

But let's talk about other scenarios which might be outside of your infrastructure that you want to incorporate into your policy decision making.

As an example, let's say you always want to make sure that individuals are using the latest version of your module. Say you've rolled out a critical security patch, and you want to make sure that individuals aren't using older versions that might not be as secure.

This might be difficult, because how do you source that information? How do you pull in and understand what exactly is the latest version?

Sentinel's new Business-aware Policies

We've rolled out as an additional feature within the Sentinel tool set something we call Business-aware Policies. This represents the ability to call out to any API endpoint and pull in external information from external systems to incorporate into your policy decision making.

In the demo that I'm about to show you, that's very straightforward. It's calling the API for my own Terraform Enterprise organization to check the latest version of the module.

But in many cases, there could be any number of factors that you might want to incorporate into your decision making: pinging an internal endpoint to see how much budget a given team has, or, having written a custom provider for your Terraform deployment, calling out to some internal system that provides information that you might need to incorporate to make a more business-aware decision and establish business-focus guardrails around your deployment.

In previous demos, I've walked through how to discover modules, how to consume and configure them directly from the UI, how to place them into repositories, how to tie them to workspaces, and, briefly, how to create Sentinel policies and apply them to workspaces.

Today, I'll show you an example of a business-aware Sentinel policy.

Setting up a policy

I want to require the latest version, as I mentioned. What I'm doing is providing all of the information that I might need to call out to my registry in this specific policy.

I provide information that's specific to my org, and I also need to provide API credentials, which introduce new security requirements, in order to communicate with my Terraform Enterprise organization or any of the internal systems.

The way that Terraform Enterprise solves for this is very elegant. Hopping back into the policy set section, where I can define sets of policies to apply for given use cases, you'll see the "Require Latest Module Version" policy set.

One additional component within this: Not only am I able to select which workspaces I want this policy set to be applied against and evaluated for at the time the plan is run, but I can also see the addition of Sentinel parameters.

This gives you a way of securely supplying whatever information you might need in order to make those requests to your internal or external systems without having to hard code those in version control. A really nice value-add for adding additional business intelligence into your decision making and doing so securely.

What does this look like? I'm going to use a new configuration file. This is the same underlying module as before, but in this case, I am going to pin it to an older version.

One benefit of using the private module registry is that you're able to see at a glance every single version of that module that's been created. So it's very easy to know what that latest version may be. In my case, I'm going to use that same module, but I'm going to invoke an older version.

Business-aware Policies in action

Looking at my source code, you'll notice that I'm invoking an older version of my full Hashi stack cluster deployment module. If a hypothetical user were to attempt to provision an older version of this modular infrastructure using an older version of this module, you're going to see Business-aware Policies in action. Queuing up a run, I'll walk you through what this looks like.

You'll notice familiar components. You'll see the plan is being generated. As a reminder, the plan represents essentially a dry run: Terraform letting you know what it intends to build based on the resources you've defined in your configuration files or within the specific modules that you've defined and are invoking in your configuration files.

It's going to run through that to let you know if there are any errors, but also let you know before it's applied—or gone and deployed anything—what it intends to do. You can incorporate this into your testing suite or your review process as well.

We'll allow this to continue to evaluate, at which point Sentinel policies are, again, going to be evaluated. Once that happens, you'll see that, again, there is a Sentinel policy failure: This is not using the latest version of my module.

This is also tremendously powerful because, oftentimes, what you start to see is inconsistency across organizations, drift, where you want to make sure that everyone is upgrading to the latest version of the module. You also want to make sure that you're leveraging the power of version pinning so you can always ensure that you don't have untested code in production.

But at the same time, you also want to make sure that everyone is following a regular cadence when it comes to upgrading their code to the most recent version, which always represents the newest version and the greatest degree of security, since it incorporates the newest best practice.

This is an example of Business-aware Policies. This could just as easily have called out to any number of internal/external systems and incorporated additional business logic, which is tremendously powerful, because you're no longer limited to what's contained in your configuration files, but you're incorporating any number of data points that are valuable or important to your organization.