Policy Snippets

You can use the pre-built policy snippets multiple times. Snippets are pre-built, parameterized Rego rules. Snippets are available from the Policy Editor through the Add Rule button. You can peruse the available snippets, choose one to instantiate, and configure it all through the Styra DAS UI without having to write any Rego yourself.

All the snippets for Entitlements presume you are using input or request schema and the relevant portion of the opinionated object model for users, groups, or other objects.

Policy Snippet Filters

Each policy snippet in the Styra DAS UI supports filters that allow you to restrict which subjects, actions, and resources this snippet applies to. The Styra DAS UI interacts with the object model to know what the possible subjects, actions, and resources are and provide them in a drop-down list.

For example, you can add a calendar snippet that denies requests on Fridays and then add filters to restrict to the subjects, actions, and resources that you want to deny requests for.

To add or remove filters to a snippet, click the Filter (three-line inverted triangle) located at the bottom of the screen and follow the self-explanatory instructions.

Modify the Rego Generated by a Snippet

Each policy snippet generates Rego which is not immediately visible or obvious. This is helpful because it allows you to modify that Rego appropriately.

The Rego is not visible In the policy editor’s Swimlanes view. To see the Rego, switch to the Code view. Next to each card, you will now see the corresponding Rego for that card. You can modify that Rego, and as long as Styra DAS can identify the parameters and rule library, it will continue showing the card with all of its parameters in the Styra DAS UI. If you change it excessively, Styra DAS will revert to treating it as a custom rule. The disadvantage to a custom rule is that the parameters and rule name will no longer be visible or modifiable from the Styra DAS UI’s cards; you must look at and modify the Rego.

For example, the following Rego is generated by the following snippet. There are five conditions in that rule:

• The include variable lists the actions and resources configured by the filter.
• The input_includes_requirements library call checks if the input matches the filters.
• The parameters variable assigns the parameters for the calendar snippet.
• The match_day_of_week library call checks if the input matches the snippet.
• The decision variable is assigned the JSON object that gets returned (after combining it with other rules and stacks).

enforce[decision] {
    include := {
        "actions": {
            "create",
            "update",
            "delete",
            "execute"
        },
        "resources": set()
    }
    data.global.systemtypes["entitlements:0.1"].library.utils.v1.input_includes_requirements(include)

    parameters := {
        "days": {
            "Friday"
        },
        "timezone": "America/Los_Angeles"
    }
    data.global.systemtypes["entitlements:0.1"].library.policy.calendar.v1.match_day_of_week[message]
        with data.library.parameters as parameters

    decision := {
        "allowed": true,
        "entz": set(),
        "message": message
    }
}

You can also add additional conditions, and the card will update in close to real-time to notify you, if you have modified the rule excessively to force Styra DAS to treat it as a custom rule.