Skip to main content

Configuration

For most of the system-types, the DAS knows the format of the decisions, for example, whether the decision represents an allow or a deny. But the DAS has no knowledge of what a decision log entry means for some system-types. However, you can configure the DAS so that it understands enough of the decision log format to display and search it properly.

To configure the decision log, go to styra-das-id.styra.com and navigate to SYSTEM >> Settings >> Decisions.

You can configure the following three top-level nodes.

  • allowed: Shows only allowed decisions. Most policy decisions can be categorized as allowed or denied. To configure allowed you must provide the following components:

    • path: A simple Rego reference to a field in the decision. For example: path.to.allowed.field or path["to"]["allowed"].field.
    • expect: (optional) If the path has this string value, the decision is allowed. Default value is the boolean true.
    • negated: (optional) If true, the decision is allowed if path does not equal expect.
  • reason: The human-readable reason to make a decision, which is often included in a policy decision so that the system can return an error message to the user. To configure the reason for a decision, you must provide the following field:

    • path: (optional) A simple Rego reference to a field in the decision. For example: path.to.reason or path["to"].reason.
  • columns: When displayed in log form, each decision is shown in a log format, where you control which columns appear. For each column, you must provide the following information:

    • path: A simple Rego reference to a field in the decision. For example: path.to.value or path["to"].value.
    • key: An alphanumeric name you can use to filter the decision log entries.
    • type: (inferred if omitted) The type of this field (to support filtering). Possible values are string (same as leaving type empty), boolean, date, integer, float.

The UI gives you the ability to control only some of the above details. The /systems API gives you complete control over the configuration.

The following shows an example of the information that you will provide to the /systems API:

{

"allowed": {
"path": "path.to.allowed",
"expect": "nope", // Optional.
"negated": true // Optional.
},

"columns": [
{
"key": "email", // Required for queries.
"path": "path.to.value", // Required.
"type": "string" // Inferred if omitted.
},
...
],

"reason": { // Optional.
"path": "path.to.reason",
}
}

You can use any path that is exposed in the decision log and easily find the paths by inspecting the decision log entries. For more information on decision logs, see the OPA decision logs page.

important
  1. For a Custom System, per package Decision Mapping is done at the system level.

  2. The decision logs are searchable for three days and always retained in storage.

Use Copy JSON Path

In the Styra DAS UI, the Copy JSON path action is useful for configuring decision log mappings. This action copies the path of any attribute in a decision log to your clipboard which avoids the need to backtrack the full path.

  1. Go to styra-das-id.styra.com.
  2. In the left navigation panel, click on a System (Kubernetes/Envoy/Custom), or under WORKSPACE, click TENANT.
  3. Click on the Decisions tab to view the live decision log.
  4. Expand a decision and right-click an attribute.
  5. Click on the Copy JSON path to copy the path of the decision or message attribute in a decision.
  6. Click on the Settings tab >> Decision Mappings pane and paste the path into the corresponding Path to decision or Path to message field.
tip

You can also use the Copy JSON path action to copy path references from data source files, or the custom library JSON files, and paste them into Rego rules when writing policies.