Policy as code — rules kept outside the app

Many apps hide access rules in if (user.role == "admin") lines. The security team cannot change them without a new release. Your goal: keep rules in one place outside the app, where you can review, test and roll them back.

The problem: rules all over the app

Suppose authorization lives in if statements across many handlers. Three bad things follow. You cannot audit it, because nobody can list all the rules. It is inconsistent, because services drift into different rules for the same question. It is slow to change, because a tighter rule needs a code change and a release. Priya's request to "stop contractors opening restricted files" becomes a two-week ticket.

The fix: decide in one place, enforce at the door

You met these two roles in zero trust. The Policy Enforcement Point (PEP) sits in your app or gateway. It stops the request, asks, and obeys the answer. The Policy Decision Point (PDP) is a separate engine. It holds all the rules and answers "allow" or "deny". Your code asks: "PDP, may Priya delete doc:report?"

OPA and Rego

Open Policy Agent (OPA) is an open-source engine that works as a PDP. Rego is the language you write its policies in. The syntax matters less than the idea: a policy is a file with a version. You review it in a pull request. You test it with unit tests, such as "this request must be denied". If a change goes wrong, you roll it back like any commit. No service release is needed.

Bundles near the service, logs as the trail

Calling a far-away server on every request is slow. So OPA packs the policies into a policy bundle. The bundle goes to a sidecar: a small helper program that runs next to each service. Decisions are then local and take microseconds. The PDP also writes each decision to a decision log: who asked, about what, and the answer. This log is your audit trail. It also feeds identity telemetry and SIEM.