Policy as Code on OCI

Every organization has rules about how its cloud should be used: which regions are allowed, what must be encrypted, what may face the internet, how resources must be tagged. The trouble is that rules written in a document are advisory at best, because nothing stops an engineer from breaking them and nothing notices when they do. Policy as code changes that by expressing the rules in a form a machine can enforce, so the estate stays compliant by default rather than by goodwill. This article explains how to do that on Oracle Cloud Infrastructure.

It belongs to our DevOps and automation on OCI cluster, and it extends the discipline of infrastructure as code patterns on OCI from defining what the estate is into defining what the estate is allowed to be.

Why written policy drifts

A policy that lives only in a document depends entirely on people reading it, remembering it, and choosing to follow it under deadline pressure. That dependency is where governance fails, because the rule that says production data must be encrypted does not encrypt anything, and the rule that says nothing should be open to the internet does not close a single port. The gap between the policy and the reality widens quietly until an audit, or an incident, reveals it.

Policy as code closes that gap by turning the rule into something executable. Instead of a sentence in a standards document, the rule becomes a check that runs automatically and either passes or fails. The rule and its enforcement become the same thing, which removes the drift, because there is no longer a written intention separate from the actual behaviour of the estate. What the policy says and what the platform does are one.

Two places to enforce

Policy can be enforced at two points, and a mature estate uses both. The first is in the pipeline, before resources are created, where a proposed change is checked against the rules and rejected if it violates them. A plan that would open a database to the internet or skip encryption simply fails the pipeline and never reaches the estate. This is the cheapest place to catch a problem, because the bad change is stopped before it exists.

The second is at run time, where the live estate is continuously checked against the rules so that anything which slips through, or is changed outside the pipeline, is detected and flagged. On OCI this run time check draws on services that report the configuration and posture of resources, feeding a continuous comparison against policy. Enforcing in the pipeline keeps bad change out; checking at run time catches whatever gets in anyway, and together they give governance that holds.

What lives in policy as code on OCI

The natural building blocks on Oracle Cloud Infrastructure include IAM policies, which are themselves declarative and version controllable, the compartment structure that segments the estate, and tag defaults and tag based access that enforce how resources are labelled and who may touch them. Beyond the native controls, policy checks written for infrastructure as code tooling can assert rules over Terraform plans before they are applied, rejecting any plan that breaches a standard.

The point is not which single tool you use but that the rules become declarative artifacts kept under version control alongside the infrastructure they govern. Storing policy as code in the same repositories, reviewed through the same process, means governance evolves through pull requests rather than through edits to a forgotten document, and every change to the rules is recorded with who made it and why.

Start with the rules that matter most

Trying to encode every conceivable rule at once is how policy as code initiatives stall. The better path is to start with the small number of rules whose violation would be most damaging: encryption of sensitive data, no unintended public exposure, approved regions only, and required tagging for cost and ownership. Encoding those few high value rules first delivers most of the protection for a fraction of the effort, and it builds the practice that later rules can join.

From that core the set of coded policies grows naturally as new requirements appear, each added as a reviewed change to the policy repository. Because the rules are code, adding one is a normal engineering task rather than a governance project, which is exactly why the approach scales where written standards do not. This incremental path keeps the effort proportional to the value at every step.

Governance that does not slow delivery

The fear with any governance is that it becomes a brake on delivery, a gate that engineers wait behind. Policy as code inverts that, because the checks are automatic and immediate: an engineer learns within the pipeline, in seconds, that a change breaches a rule, and fixes it then and there rather than discovering it weeks later in a review. Fast automated feedback makes compliance part of the normal flow of work rather than an obstacle to it.

Designed well, policy as code lets an organization move faster with more confidence, because the guardrails are always on and the team can change the estate freely knowing the rules will catch anything out of bounds. Building that capability is part of our IAM and security solution and our OCI security and compliance service, and it complements the testing discipline covered in testing infrastructure code for OCI within this wider DevOps and automation series.