Governance Is Becoming A Platform Problem
For most of the last decade, governance in cloud organizations was a checkpoint model: before you deploy to production, a human reviews your configuration for compliance. Security teams built review queues. Platform teams built deployment gates. Teams waited days for approvals. The model worked when deployments were infrequent. It stopped working when continuous delivery became table stakes. The…
- Manual governance checkpoints are architecturally incompatible with continuous delivery, scaling reviewers doesn't solve the problem, moving governance upstream does.
- OPA with Gatekeeper enforces Kubernetes policy at admission time, making non-compliant deployments impossible by construction rather than detectable in retrospect.
- Conftest shifts policy gates into CI pipelines, giving developers immediate feedback on IaC compliance before changes are reviewed or applied.
- Governance-as-infrastructure requires security teams to become policy authors, not just policy enforcers, the code and the compliance knowledge have to live in the same team.
- Continuous compliance evidence is a byproduct of platform-integrated governance, turning audit preparation from a quarterly manual project into a query against system logs.
Manual Governance Review Is A Bottleneck By Design
The checkpoint model of governance was designed for a deployment cadence that no longer exists. When organizations deployed quarterly, a human review gate before production made sense. The reviewer could examine the change, cross-reference it against compliance requirements, and make a judgment call. The latency was acceptable because the deployment itself was rare. At continuous delivery cadences, dozens to hundreds of deployments per day, that model is architecturally unsustainable. The revie
OPA And Gatekeeper Move Policy Into The Kubernetes Admission Layer
Open Policy Agent (OPA) with Gatekeeper is the most mature implementation of governance-as-infrastructure for Kubernetes environments. The mechanism is a Kubernetes admission webhook: before any resource is created or modified in the cluster, the request passes through Gatekeeper, which evaluates it against a set of OPA policies expressed in Rego. If the resource violates policy, a container running as root, a deployment without resource limits, an image from an unapproved registry, the admissio
Conftest Brings Policy Gates Into Infrastructure-As-Code Pipelines
OPA in the Kubernetes admission layer covers runtime governance. But by the time a misconfigured Kubernetes resource reaches the admission webhook, a developer has already written the configuration, committed it, and waited for a CI run. The shift-left version of this is Conftest: an OPA-based tool that evaluates policy against configuration files, Terraform, Kubernetes manifests, Dockerfile, Helm charts, in CI pipelines before anything is applied. A Conftest policy in a Terraform pipeline can
Frequently asked questions
- How do we roll out OPA policies without breaking production workloads?
- Use dry-run mode first. Gatekeeper supports an audit mode where policies are evaluated and violations are recorded without blocking admission. Run new policies in audit mode for a minimum of two weeks, review the violation reports, and work with affected teams to remediate before switching to enforcement mode. Never deploy a new enforcement-mode p…
- How do we handle legitimate exceptions to governance policies?
- Build an exception workflow into the platform, not around it. OPA and Gatekeeper support exemption mechanisms, specific namespaces, specific resource annotations, or specific teams can be granted exemptions through policy configuration. The exception should be version-controlled in the policy repository, reviewed through a pull request with docume…
- What's the right starting point for a team moving from manual governance to policy-as-code?
- Start with one high-value policy that has zero ambiguity: no public S3 buckets, no containers running as root, no secrets in environment variables. Pick something where a violation is unambiguously wrong and the fix is straightforward. Get that running in your CI pipeline with Conftest and build confidence in the model before expanding to more com…
- How does this model interact with existing ticketed change management processes?
- Gradually replace them. The argument for ticketed change management is that it provides a paper trail and a human judgment point. Policy-as-code provides a better paper trail, every policy evaluation is logged with full context, and moves human judgment upstream to where it matters: writing and reviewing the policy itself, not rubber-stamping indi…