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:
allowedanddeniedfields 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.entzis optional and does not affect theallowedoutcome. Theentzfield must be a Rego set and theentzsets from allenforcerules are unioned together and returned in the final outcome. Theentzset 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.messageis optional and does not affect theallowedoutcome. Themessagefield is for informational purposes only. It contains an explanation of why a request was allowed or denied for troubleshooting purposes.