What it does here
Open Policy Agent is the policy decision point. For every action a user attempts in the Golonex Portal, the Portal asks OPA one question — is this allowed? — and OPA answers from policy written as code, returning both a decision and a reason.
Separating the decision from the application is the point. The rules live in one reviewable file instead of being scattered through application logic, and they can be tested on their own.
How it is deployed
Container opa, running as a server on the internal network with decision logging to the console so every answer becomes an event. The policy file is mounted read-only — see Installation §4.5.
The policy, in plain terms
| Action | Requires |
|---|---|
home.view | nothing — any signed-in user |
hris.view / hris.edit | hr-staff |
invoice.create | finance-ap-clerk |
payment.approve | finance-ap-approver; above 50,000 also access-approvers |
admin.view | it-admins |
| any finance action | denied outright if the user holds both AP roles — segregation of duties |
Two ideas are on display here at once: RBAC (does the user hold the right group?) and ABAC (is the amount over the threshold?). The exam separates these; the policy shows them working together.
Where you see it working
In the Portal
Every denial you meet in the Golonex Portal is an OPA answer. The page prints the reason OPA returned — missing entitlement, amount above 50,000 requires manager approval, or SoD violation. Read the reason: it is the policy explaining itself.
In the SIEM
Each decision is logged, and the Portal forwards its authorization events to Wazuh. A denied action is an auditable record, not just a message on screen.
Try this
- Approve a payment of exactly 50,000, then one of 50,001, as the same user. The first is allowed and the second is not — the clearest demonstration of attribute-based access control you will get.
- Work through Part C of Practice: predict fifteen decisions, then check yourself against the validated answers.