Pulling policy out of the code
Scattering authorization checks through application code makes rules hard to audit and change. A policy engine externalizes the decision. The application becomes a policy enforcement point that asks the engine, the policy decision point, whether an action is allowed.
How OPA works
The Open Policy Agent, OPA, is a general purpose engine. Policies are written in a declarative language called Rego. At decision time the application sends a JSON input describing the subject, action, and resource. OPA evaluates the loaded policies against that input and returns an allow or deny decision, often with reasons.
Keeping the decision logic in Rego, separate from services, means:
- Policies can be reviewed, versioned, and tested independently.
- Many services share one consistent policy language.
Decision data and performance
Policies often need extra context data, like group memberships, supplied alongside the input or preloaded into the engine. To stay fast, OPA is commonly deployed as a sidecar next to each service, so authorization queries are a local call rather than a network round trip to a central server.
Key idea
A policy engine like OPA externalizes authorization into a decision point that evaluates declarative Rego policies, keeping access rules auditable, shared, and decoupled from service code.