Compliance as Code

The Problem with Spreadsheets

If your company processes credit cards, it is legally required to conform to the PCI-DSS compliance standard. If your company operates in healthcare, it must comply with HIPAA regulations.

Historically, the Security and Compliance departments managed these regulations using colossal Excel spreadsheets containing hundreds of highly ambiguous rules:

• "Rule 41: All databases must be encrypted at rest."
• "Rule 88: No internet-facing servers may have port 22 (SSH) open globally."

Before the Operations team could deploy a server, the Compliance team had to manually review the deployment ticket and explicitly check off lines on their spreadsheet. This auditing process could delay deployments by three to four weeks.

In an automated CI/CD environment deploying code 50 times a day, manual auditing is impossible.

Enter Compliance as Code

Compliance as Code (Policy as Code) bridges the gap between the lawyers/auditors and the DevOps engineers.

Instead of writing a policy in an Excel spreadsheet, you write the policy using a programming language. You then inject that mathematical policy directly into the CI/CD pipeline or the Kubernetes cluster.

If a developer attempts to deploy a Terraform script creating an unencrypted database, the system intercepts the code, executes the policy script against it, and immediately throws a blocked error: "Deployment rejected: Violates PCI-DSS Encryption Policy."

Open Policy Agent (OPA)

Open Policy Agent (OPA) is an open-source, general-purpose policy engine maintained by the CNCF. It has become the absolute standard for Policy as Code.

OPA uses a declarative programming language called Rego.

With Rego, you don't write how to block the deployment. You simply write the logic that defines what a violation looks like.

Analyzing a Rego Policy

Imagine a developer writes this Kubernetes Deployment YAML, attempting to run a container as the dangerous root user:

# A developer's dangerous YAML
apiVersion: apps/v1
kind: Deployment
spec:
  template:
    spec:
      containers:
      - name: my-app
        image: nginx
        securityContext:
          runAsRoot: true    # VERY DANGEROUS!

To stop this from ever being deployed to the cluster, the Security team writes the following Rego policy inside OPA:

# An OPA Rego Policy
package kubernetes.admission
 
# Define what constitutes a violation
deny[msg] {
  # 1. Grab the container from the inputted YAML document
  container := input.request.object.spec.template.spec.containers[_]
  
  # 2. Check if the runAsRoot field is explicitly true
  container.securityContext.runAsRoot == true
  
  # 3. If the above is true, trigger the denial and output this message
  msg := sprintf("Container '%v' is attempting to run as root. This violates corporate security policy.", [container.name])
}

When the developer runs kubectl apply, the API server secretly forwards the developer's YAML to OPA. OPA evaluates the YAML against the Rego code, triggers the deny block, and rejects the deployment.

The developer receives the clear error message instantly in their terminal, allowing them to fix it in 30 seconds rather than waiting three weeks for a security audit.

HashiCorp Sentinel

While OPA is the king of Kubernetes policy, Sentinel is the premier framework for the Terraform ecosystem.

Sentinel is a proprietary policy-as-code framework integrated tightly into Terraform Cloud and Enterprise. It allows administrators to mathematically restrict the infrastructure that developers are permitted to provision.

Use Cases for Sentinel

1. Security Enforcement: "Deny any AWS Security Group that contains the CIDR block 0.0.0.0/0 (the global internet) on port 22."
2. Cost Control: "Deny any developer attempting to deploy an EC2 instance larger than a t3.medium unless they have the Manager role."
3. Cloud Regional Restricting: "Deny any deployment entirely if the AWS region is not us-east-1 (to satisfy GDPR data sovereignty laws)."

Hard Mandatory vs Soft Advisory

Sentinel introduces a brilliant feature called "Enforcement Levels."

• Hard Mandatory: The deployment fails instantly and completely.
• Soft Mandatory: The deployment pauses and generates an alert. An administrator must manually click an "Override" button to allow it to proceed.
• Advisory: The deployment is fully allowed, but prints a stark warning to the console output notifying the developer that they are violating a soft policy (like missing a non-critical tagging label on their server).