Input, data & document model

Feeding facts to policy.

Advanced12 min · lesson 6 of 12

OPA evaluates over two documents. input is the thing being judged, provided per query (a request, a resource, a Terraform plan). data is external context loaded into OPA — allowlists, role mappings, exception lists — that policies reference as data.<path>. Separating the two matters: the policy logic stays stable while the facts (which registries are allowed, who is exempt) live in data you can update without touching rules.

INPUT vs DATA: THE DOCUMENT MODEL

input (per query, separate)

a request

the thing being judged

a resource

a Terraform plan

data (one virtual tree)

loaded facts

allowlists, role maps, exemptions

rule outputs

e.g. data.main.deny

system info

all under data.<path>

input is judged per query and stays separate; everything else lives under one virtual tree rooted at data.

data.json + policy

// data.json — facts, loaded into OPA
{ "allowed_registries": ["registry.internal", "gcr.io/acme"] }
---
package main
deny contains msg if {
  image := input.spec.containers[_].image
  reg := split(image, "/")[0]
  not reg == data.allowed_registries[_]      # reference external data
  msg := sprintf("registry %v not allowed", [reg])
}

The unified document model

OPA presents everything — your loaded data, your rules’ outputs, and system info — under one virtual document rooted at data, while the query input is separate. Your policies are themselves under data (data.main.deny). This uniform tree is why opa eval queries look like data.example.allow, and why loading external facts is just “put JSON under a data path.” Keeping mutable facts in data and logic in rules is the clean separation to aim for.

Data is trusted input — control who can change it

Because policies make decisions using data (allowlists, exemptions), whoever can modify that data can effectively change the policy outcome without touching a rule — adding themselves to an exception list, say. Treat policy data with the same review and access control as the rules: version it, review changes, and do not let it be writable by the systems the policy is meant to govern.

Deny/allow patternsConftest for config & IaC