IaC Policy as Code (OPA, Sentinel)

Policy as code enforces guardrails on IaC. The patterns that work and the tools available.

Common rules

Policy as code is the discipline of expressing infrastructure governance rules as machine-checkable code rather than written guidelines. The rules are evaluated automatically at PR time; violations block merge until fixed. The shift turns governance from review-meeting drag into mechanical enforcement.

What common rules look like:

• All EC2 must have specific tags.: The team requires tags for cost allocation, ownership, environment, and data classification. The policy enforces that every EC2 instance, RDS database, and other tagged resource has the required set. Untagged resources cannot merge.
• S3 buckets must have encryption.: Encryption at rest is required by data protection policies. The rule checks every S3 bucket definition for encryption configuration. Buckets without encryption are blocked. The discipline removes a recurring class of misconfiguration.
• Public-facing resources require security review.: Resources with public network access (public S3 buckets, internet-facing load balancers, security group rules opening 0.0.0.0/0) require explicit approval. The rule does not block; it routes the change to security review.
• Forbidden services or instance types.: Some services are not allowed in certain accounts or regions for compliance or cost reasons. Some instance types are not allowed (oversized, expensive). The rules catch the violations at PR time.
• Naming conventions.: Resource names follow team conventions. The policy enforces the convention; deviations require explicit override. The consistency makes operational tooling easier.

The rules are organization-specific. The catalog grows over time; new rules are added when new misconfiguration patterns emerge.

Tools

The tooling for policy as code has matured significantly. The choice depends on what IaC tool the team uses, what platform features they have access to, and how vendor-neutral they want their policy code to be.

• OPA / Conftest: vendor-neutral.: Open Policy Agent (OPA) and its Conftest tool evaluate policies written in Rego against any structured input. Terraform plans, Kubernetes manifests, CloudFormation templates all work. The vendor-neutrality means policies travel with the team across tools.
• Terraform Sentinel: integrated with Terraform Cloud.: HashiCorp's Sentinel is integrated with Terraform Cloud and Enterprise. The integration is tight; the policy code lives alongside Terraform configurations. The trade-off is vendor lock-in.
• AWS Config: post-deploy detection.: AWS Config Rules evaluate deployed resources and flag non-compliant ones. The detection is post-deployment; the resources already exist. Useful as a safety net but not a replacement for pre-deploy checks.
• Checkov: opinionated and quick.: Checkov ships with a large catalog of pre-built rules covering common security and compliance patterns. The team gets value immediately; the rules can be extended with custom Python.
• tfsec, terrascan, kics: similar starts.: Several open-source tools occupy the same space as Checkov with slightly different rule sets and configurations. The choice between them often depends on which integrates best with the team's existing pipeline.

The right tool is the one the team will actually use. Pre-built rules accelerate adoption; custom rules close organization-specific gaps.

CI integration

Policy checks have to run in CI to be effective. A policy that runs after deploy catches drift but does not prevent it; a policy that runs in CI prevents the misconfiguration from reaching production.

• Policy checks in PR CI.: Every PR that changes infrastructure code triggers policy evaluation. The output appears as PR comments or status checks. The developer sees the violation in their PR loop, not in a separate channel.
• Failed policies block merge.: The PR cannot merge until policies pass. The block is enforced by the merge protection rules; bypasses require explicit administrator action. The block is the discipline that produces compliance.
• Override possible for emergencies.: Genuine emergencies sometimes require deploying configurations that violate policy. The override path exists; it is documented; it requires explicit approval. The override is a tracked event, not a silent bypass.
• Override logged.: Every override is logged. The override appears in audit reports; the team knows when policies were bypassed. The logging makes the override discipline visible and auditable.
• Policy code reviewed.: Changes to the policies themselves go through the same review as application code. The policy code is owned, maintained, and tested. Drift in policies is itself a violation worth catching.

IaC policy as code is one of the highest-leverage governance disciplines available to platform teams. Nova AI Ops integrates with policy engines and infrastructure platforms, surfaces violation trends, and produces the audit-ready report that compliance discussions reference.