Rego Authoring
Instead of using snippets, if you want to write your own rules then click to the Code view in the policy editor to write custom Rego. The following is an example policy
package with one enforce
rule and one monitor
rule. The first allows alice
to write customized rules; the second prohibits bob
from writing customized rules.
package policy
enforce[decision] {
decision := {
"allowed": true,
"message": "snippet that allows all requests"
}
input.subject == “alice”
}
monitor[decision] {
decision := {
"allowed": false,
"message": "snippet that is not enforced, only monitored"
}
input.subject == “bob”
}
Each set enforce
and monitor
must contain decision objects, each of which is a JSON object. The following fields are permitted in decision objects: allowed
, denied
, entz
, and message
.
allowed
anddenied
fields are mutually exclusive, so only one may be set at a time, and one of these fields is required to be present in the decision object.entz
is optional and does not affect theallowed
outcome. The entz field must be a Rego set and theentz
sets from allenforce
rules are unioned together and returned in the final outcome. Theentz
set is intended to be used when clients need more information than a single allowed boolean value. For example, it can be used to return a set of Entitlements that the client should be granted.message
is optional and does not affect theallowed
outcome either. Themessage
field is for informational purposes only. It contains an explanation of why a request was allowed or denied for troubleshooting purposes.
The overall policy decision returned to the caller is a combination of the results produced by the DAS system and the collection of DAS stacks that apply to that system. For more information on how those decisions get combined, see Use Systems and Stacks page.