Enforcing security using Checkov, Sentinel, and more in compliance-focused IaC workflows

Infrastructure as Code (IaC) makes infrastructure management easier and more efficient, but with flexibility comes the threat of misconfiguration. Simple mistakes such as specifying an incorrect hardware tier or forgetting to enable available security protections can too easily impact performance, compliance, and costs. DevOps teams often struggle to avoid these problems because top tools like Terraform weren’t designed with compliance in mind.

‍

Adopting Policy-as-Code (PaC) tools such as Checkov and Sentinel lets you solve this challenge. These frameworks enable you to centralize IaC governance through policies that are defined and stored as code. You can version your policies using Git repositories, then evaluate your IaC files against them each time you apply changes. Blocking deployments that fail policy checks protects you from the costly errors and security breaches that easily occur in traditional IaC.

‍

This blog post will explore the key features of Checkov and Sentinel. We'll show how to write simple policies using each tool and mention some other options for different use cases. We'll also discuss strategies for tightly integrating Policy-as-Code checks into your IaC workflows.

‍

Why you need Policy-as-Code for IaC

‍

Policy-as-Code for IaC uses code-defined policies to govern the what, who, and when of IaC changes. Tools such as Checkov and Sentinel let you write expressive policies that you can test your IaC config files against. Depending on the tool, you can then reject changes if they contain unauthorized content, have missing approvals, or are being made by unauthorized users.

‍

IaC errors such as publishing an incorrect port or specifying incorrect object storage bucket security settings can cause serious incidents. Policy-as-Code improves IaC safety by preventing these misconfigurations from reaching your live infrastructure. For example, you could write policies that check IaC files only use acceptable port numbers, or which block the creation of publicly accessible S3 buckets.

‍

By centralizing security and compliance rule enforcement, Policy-as-Code makes it easier to maintain IaC governance requirements at scale. Running a PaC tool within your deployment pipeline lets you reliably block suspect infrastructure changes, reducing the chance you'll encounter problems in production. Checkov, Sentinel, and other solutions provide frameworks that replace manual IaC code reviews with continual automated checks.

‍

Key tools for IaC compliance and Policy-as-Code

‍

There's many different Policy-as-Code tools to choose from depending on your use case and preferred IaC technologies. Let's look at two of the most popular options and then briefly explore some alternatives.

‍

Checkov

‍

Checkov is a versatile Policy-as-Code solution that works with Terraform, Kubernetes, AWS CloudFormation, serverless platforms, and more. It scans your IaC config files and provides a clear report in your terminal. You can also integrate the tool with CI/CD services to run scans automatically before you apply IaC changes.

‍

‍

Checkov comes with an extensive suite of built-in policies that are enabled by default. The tool becomes even more powerful when you add custom policies to enforce your internal operational requirements. You can write policies as either Python code or declarative YAML files.

Here's an example Checkov YAML policy for use with Terraform and AWS. The policy specifies that all AWS resources must reside in the us-east-1 region. This could help prevent compliance breaches caused by data accidentally transiting geographical boundaries.

‍

metadata:

  id: "CKV2_CUSTOM_1"

  name: "AWS EC2 instances must be us-east-1"

  category: "GENERAL_SECURITY"

definition:

  cond_type: "attribute"

  resource_types:

    - "provider.aws"

  attribute: "region"

  operator: "equals"

  value: "us-east-1"

‍

To try this out, first copy the YAML file and save it to checks/aws_region.yaml in your working directory. Next, copy the following Terraform config to main.tf:

‍

terraform {

  required_providers {

    aws = {

      source = "hashicorp/aws"

    }

  }

}

‍

provider "aws" {

  profile = "default"

  region = "eu-west-1"

}

‍

You can now use Checkov to test the Terraform config against the policy:

‍

$ checkov -f ./main.tf --external-checks-dir ./checks

‍

Checkov reports an error because the region specified in the Terraform file doesn't match us-east-1:

‍

Checkov is a popular choice for implementing IaC Policy-as-Code because it's fast, easy to learn, and adaptable to many different environments. You can use the same YAML syntax shown above to implement similar checks for your Kubernetes manifests, for example. Checkov can load custom policies from Git repository URLs, enabling you to follow a full GitOps strategy to manage your IaC governance requirements.

‍

Sentinel

‍

Sentinel is Hashicorp's Policy-as-Code solution. It's tightly integrated into Hashicorp's enterprise products including its hosted HCP Terraform (previously Terraform Cloud) IaC management platform.

‍

Sentinel enables precise policy decisions based on specific properties of your IaC files. It's a great choice when you're already using Hashicorp's services because the tool's embedded in HCP Terraform, Nomad, Consul, and Vault. You can test your policies locally with the Sentinel CLI, then upload them to HCP Terraform so they're checked automatically before each terraform apply.

‍

Sentinel policies are written in HCL (Hashicorp Configuration Language) just like Terraform files. This helps improve familiarity for teams that already use Terraform, but are just getting started with PaC. Here's an example policy that requires EC2 instance changes in Terraform plans to use only the t3.large and t3.xlarge hardware types:

‍

import "tfplan/v2" as tfplan

‍

allowed_instance_types = ["t3.large", "t3.xlarge"]

‍

aws_instances = filter tfplan.resource_changes as _, r {

  r.type is "aws_instance"

}

‍

aws_instances_valid_type = rule {

  all aws_instances as _, r {

    r.change.after.instance_type in allowed_instance_types

  }

}

‍

main = rule {

  aws_instances_valid_type

}

‍

For this policy to work, Sentinel also needs a config file similar to the following. It enables Sentinel's Terraform modules, specifies the path to your JSON plan file, and registers the policy as a required check.

‍

sentinel {

  features = {

    terraform = true

  }

}

‍

import "plugin" "tfplan/v2" {

  config = {

    plan_path = "./tfplan.json"

  }

}

‍

policy "validate_aws_instance_type" {

  source = "./policies/validate_aws_instance_type.sentinel"

  enforcement_level = "hard-mandatory"

}

‍

Sentinel has a built-in test framework that lets you validate that new policies behave correctly before you start using them in your pipelines. External status checks mean you can also reject IaC changes based on the results from other APIs. Sentinel doesn't support IaC tools beyond the HCP ecosystem, however, making it unsuitable when you want to standardize on one system for all your Policy-as-Code requirements.

‍

Other IaC Policy-as-Code tool options

‍

Checkov and Sentinel are both great tools for key IaC Policy-as-Code use cases, but that doesn't mean they're necessarily right for you. Here's some of the most popular alternative PaC engines from across the ecosystem:

‍

• Open Policy Agent (OPA): OPA is a general-purpose policy engine with a simple expressive syntax. It's well-supported by popular IaC management platforms.
• Conftest: Conftest is built upon OPA. It includes additional features that make it easier to run policies against structured data formats.
• Pulumi CrossGuard: CrossGuard is Pulumi's Policy-as-Code engine, but it also works with cloud resources managed by other tools. You can write policies using regular programming languages including JavaScript and Python.
• KICS: KICS is a policy-driven security testing tool that works with Terraform, Kubernetes, AWS CloudFormation, Knative, and more.

‍

When choosing a Policy-as-Code engine, first check it supports all the IaC tools and cloud providers you use. You should then evaluate how easy it is to write new policies and test your IaC files against them.

‍

How to implement Policy-as-Code checks in your IaC workflows (Checkov, Sentinel, and More)

‍

Whichever Policy-as-Code tool you use, it must be tightly integrated with your IaC workflows. Automate your PaC checks via a CI/CD pipeline to ensure they're run for every IaC change you apply. Blocking pipelines when your PaC tool reports a policy violation gives immediate feedback to developers. It also stops misconfigurations reaching your infrastructure.

‍

Tools like Checkov are designed to work well with popular CI/CD solutions such as GitHub Actions and Jenkins. However, modern infrastructure management solutions including Spacelift, Env0, and Terraform Cloud offer a simpler and more reliable way to automate IaC at scale. They address the challenges of using traditional CI/CD for infrastructure pipelines by centralizing provisioning, state management, and day two operations in one platform. Moreover, they come with built-in PaC capabilities so you can implement your governance requirements.

‍

For example, Spacelift includes a robust Policy-as-Code system that's based upon OPA. Spacelift runs your policies automatically as you commit IaC changes, ensuring continual compliance without making you manually configure complex pipelines. You can also connect external PaC engines such as Checkov and KICS.

‍

‍

‍

Env0 offers similar Policy-as-Code capabilities too. Switching to one of these platforms instead of traditional CI/CD lets you efficiently govern your operations as you scale your IaC workflows. They're designed for infrastructure compliance needs from the outset, making it less likely that breaches will occur.

‍

Summary

‍

Policy-as-Code is an IaC governance strategy that enables continual enforcement of security and compliance rules. PaC engines such as Checkov and Sentinel let DevOps teams centrally manage code-defined policies that prevent IaC misconfigurations and inconsistencies.

‍

PaC is most successful when it's deeply embedded in your IaC workflows. It's crucial to ensure all infrastructure changes pass applicable PaC checks before they're deployed to live environments. You can either run a PaC tool within a custom CI/CD pipeline, or use the built-in governance capabilities of IaC management platforms like Spacelift and Terraform Cloud. These solutions allow you to easily configure PaC right alongside your other infrastructure processes.

‍

Getting started with Policy-as-Code can seem daunting, but it puts you on the path to safer and more scalable infrastructure management. If you're unsure where to begin, then try talking to our IaC and cloud transformation specialists at Semantive. We're experts in planning large-scale cloud environments to support your operational needs.

‍