Rego Authoring
Instead of using snippets, if you want to write your own rules select 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
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. Theentz
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. Themessage
field is for informational purposes only. It contains an explanation of why a request was allowed or denied for troubleshooting purposes.