The decision API & bundles

OPA as a service; distributing policy.

Beyond the CLI, OPA runs as a server exposing a REST decision API: your service POSTs input to /v1/data/<policy path> and gets the decision back as JSON. This is how applications offload authorization — the app asks “can this user do this?” and enforces the answer, with all the logic in OPA. Running OPA as a sidecar next to the service keeps latency low and the policy engine local.

$ opa run --server policy.rego
$ curl -s localhost:8181/v1/data/authz/allow \
    -d '{"input": {"user": {"roles": ["editor"]}, "action": "write", "resource": "docs/x"}}'
{ "result": true }

Bundles: distributing policy

Bundles are how you deliver and update policy to running OPAs at scale: a bundle is a tarball of policies and data that OPA periodically pulls from a server (an HTTP endpoint, an S3 bucket, an OCI registry). Change the bundle centrally and every OPA picks it up — so a fleet of sidecars stays in sync without redeploying the apps. Bundles support signing, so an OPA can verify a bundle before loading it.

services:
  acme: { url: https://policies.acme.internal }
bundles:
  authz:
    resource: bundles/authz.tar.gz
    polling: { min_delay_seconds: 30, max_delay_seconds: 60 }
    signing: { keyid: acme-policy-key }   # verify the bundle signature before loading