Policy-as-Code Foundations

DevOps Policy Automation Introduction: What is Policy as Code

Policy-as-Code (PaC) is the practice of managing and automating policies by defining them in a high-level, human-readable programming language. Instead of manually configuring security controls, compliance rules, and operational guardrails through a GUI, you write them as code. This code is then stored in a version control system (like Git), tested automatically, and applied as part of your CI/CD pipeline.

Just as Infrastructure-as-Code (IaC) revolutionized how we manage infrastructure, Policy-as-Code is revolutionizing how we manage governance and security. It shifts policy enforcement from a reactive, manual process to a proactive, automated one.

Infrastructure Governance Best Practices: Benefits of Policy as Code

Policy as Code Workflow Tutorial: Complete Development Lifecycle

The PaC lifecycle mirrors a standard software development lifecycle, applying the same best practices to governance.

1. DEFINE: Policies are written in a specific language (e.g., Rego, YAML).
   - Example: A policy to enforce encryption on S3 buckets.

2. VERSION CONTROL: The policy code is committed to a Git repository.
   - A pull request is created to propose a new policy or a change.
   - Team members from security and development review the change.

3. TEST: Automated tests run against the policy to ensure it works as expected.
   - Unit tests check the policy logic.
   - Integration tests check the policy against sample "good" and "bad" infrastructure code.

4. DEPLOY: Once approved and merged, the policy is deployed to the policy engine.
   - This could involve uploading it to OPA, applying a Kyverno CRD, or updating a Sentinel policy set.

5. ENFORCE & MONITOR: The policy engine enforces the rule during CI/CD (pre-deployment) and/or runtime (post-deployment).
   - Violations are logged and sent to monitoring dashboards or alerting systems.
   - Feedback from monitoring informs future policy definitions.

Policy as Code Tools Comparison: OPA vs Kyverno vs Sentinel

The PaC ecosystem has a variety of tools, each with its own strengths. The most common paradigm is built around a policy engine that evaluates rules written in a specific language.

Open Policy Agent (OPA) with Rego

OPA is the de facto open-source standard for unified policy enforcement. It uses a declarative language called Rego. Because OPA is domain-agnostic, you can use it to write policies for Kubernetes, Terraform, microservices, and more.

package play

# By default, access is denied
default allow = false

# Allow access if the user is an admin
allow = true {
    input.user.role == "admin"
}

Kyverno

Kyverno is a policy engine designed specifically for Kubernetes. Its key advantage is that policies are just standard Kubernetes YAML manifests, so there is no new language to learn.

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-labels
spec:
  validationFailureAction: enforce
  rules:
  - name: check-team-label
    match:
      any:
      - resources:
          kinds:
          - Pod
    validate:
      message: "The label 'team' is required."
      pattern:
        metadata:
          labels:
            team: "?*"

HashiCorp Sentinel

Sentinel is HashiCorp's embedded PaC framework for the Terraform ecosystem (Terraform Cloud/Enterprise). It's designed to enforce policies on Terraform plans before they are applied.

import "tfplan/v2" as tfplan

# Rule: Restrict EC2 instance types to t2.micro
main = rule {
  all tfplan.resource_changes as _, rc {
    rc.type == "aws_instance" and
    rc.change.after.instance_type == "t2.micro"
  }
}

💡 Policy as Code Best Practices: Key Implementation Takeaways

Next Steps