Skip to main content

Overview

The decision log records the policy decisions that OPA makes, regardless which kind of real-world system OPA is integrated with. Each decision log entry records the inputs that OPA was given, the decision that OPA made, a pointer to the policy or data used to make that decision, performance metrics for decision-making, and so on. Each decision log entry is stored in JSON so that it can be applied in a variety of circumstances. You can ask why a decision was made the way it was or how an old decision would be made today using the current policy.

View the Decision Log​

To view the decision log in the DAS GUI, in the left navigation panel, under WORKSPACE, click <das-id>.styra.com, and then click Decisions tab to view the live decision log. Styra DAS displays all the decisions made across all systems. To view only the decisions for a single DAS system, click on your system name in the left navigation panel and then click on the Decisions tab. Similarly, you can see the decisions for a DAS Stack.

Types of Decisions​

Every decision log entry is marked as one of the following types:

  • Denied: Decision was to rejected the attempted user action.

  • Allowed: Decision was to accept the attempted user action.

  • Advice: Decision cannot be categorized as either Allowed or Denied. Advice decisions can represent a Mutation.

  • Error: An error like divide-by-zero occurred during policy evaluation.

  • Unknown: Decision cannot be categorized in any other way.

note

Mutating happens before validating. The resource (as the input) first hits mutating, and if applicable a patch is applied by the mutating rule. Now, the patched resource acts as an input to validating. The decision log for validating (Allowed or Denied) displays the mutated or patched object in the logs.

The Unknown marking appears primarily for a Custom system or policy type when the Styra DAS does not understand the use case and what its decisions represent in the real world. But, the Styra DAS can be configured to understand the decision log format for each of those Custom systems and policy types.

For more details on configuring decision logs, see the decision log configuration page.

Find the Decision​

The following tools will help you to find or browse the decision of your interest:

  • Filter: Enter a search term. For example, nginx to restrict the visible entries.

  • Live: Toggle whether to continue updating in (near) real-time.

  • Policy-type: For systems or stacks with multiple policy types (for example, Ingress and Egress), you can choose which ones to view.

  • Outcome: Whether the decision was Denied, Allowed, Advice, Error, or Unknown.

Analyze the Decision​

When you find an interesting decision, you can analyze the decision by doing the following operations.

  • Explore the contents of that decision by clicking the arrow on the left-hand side to reveal the full JSON entry. Below are the details for each field in the decision log, but the most important ones are:

    • path: Name of the policy that OPA evaluated.

    • input: The JSON object that OPA made a decision about.

    • result: The decision itself.

  • Replay the decision by clicking the Replay button. Now, Styra DAS will load the decision's input into the current policy and evaluate the results so that you can see what decision your current policy would make. This also makes it easy to change the input to see how the output would change.

  • Copy the decision by clicking on the Context button. This will copy the JSON entry to your clipboard for use elsewhere.

  • Copy a link to the decision by clicking on the Context button. This gives you a link that makes it easy to share exactly that decision with other people.

Decision Log Entry Fields​

The following shows the list of individual fields for each decision log entry in the order of importance:

  • path: The name of the policy that OPA evaluated (policies in OPA are arranged hierarchically).

  • input: The full input OPA used to make a decision (For example, Kubernetes expects an AdmissionReview request).

  • result: The result of policy evaluation (For example, Kubernetes expects an AdmissionReview response).

  • allowed: A boolean indicating whether the response was allowed or denied.

  • reason: A statement explaining why the decision was made.

  • error: The error object returned to the user if policy evaluation failed.

  • revision: An identifier for the version of the policy (and all of its dependencies) used to make the decision.

  • metrics: The metrics OPA recorded when making the decision. For example, the following shows the list of metrics:

    • timer_rego_module_parse_ns: Time (in nanoseconds) to read the policy into memory.

    • timer_rego_module_compile_ns: Time (in nanoseconds) to prepare the policy for evaluation.

    • timer_rego_query_parse_ns: Time (in nanoseconds) to read the query into memory.

    • timer_rego_query_compile_ns: Time (in nanoseconds) to prepare the query for evaluation.

    • timer_rego_query_eval_ns: Time to evaluate the query.

    • timer_server_handler_ns: Total time from when OPA received the query to the time it responded.

  • labels: The labels that OPA was configured with.

  • requested_by: The IP address and port of the service that requested a policy evaluation.

  • decision_id: A unique identifier generated by OPA.

  • agent_id: A unique identifier of the OPA instance responsible for the decision.

  • timestamp: Timestamp of the decision (OPA-side clock).

  • received: Timestamp when the decision log batch was received by Styra (server-side clock).

  • system_id: A unique identifier of the system.

  • columns: A list of user-defined column values reflecting values extracted from the decision result, input or other fields.

Decision Replay Mode​

The Decision Replay Mode explains what policies are contributed to the selected decision. You can replay the decision by clicking the Replay button.

The Replay mode has the following considerations:

  • The default selected policy is set as the recommended policy.

  • Only policies highlighted in bold directly contributed to this replayed decision.

  • Additionally, this shows systems, stacks, and libraries that indirectly contributed to this replayed decision.

  • Normal file operations (such as deleting systems) are restricted.

The Decision Replay Mode section below the help and profile icons in the left navigation pane indicates replay mode is active. To exit the replay mode, click the close (X) button. To share the replayed decision link with other users,click the Get Link button.

While in the replay mode, you can also work on decisions in normal mode as follows:

  • Open and debug the same policy in normal mode using a different tab to preview or validate after making changes.

  • Understand why a policy does not appear in replay mode, which they expected to contribute to a decision and want to debug.

  • Compare the replay mode policy with another policy in normal mode.

In the above cases, you can exit the replay mode by changing the URL in a new browser tab. You can also return the UI to normal mode (non replay mode) by removing the query parameter mode=decisionReplay in the URL. To enable the replay mode, add the query parameter mode=decisionReplay in the URL. For example, /v1/...?mode=decisionReplay.

Styra DAS also loads the decision's input into the current policy and evaluates the results so that you can see what decision your current policy would make. This also makes it easy to change the input using the Preview button to see how the output would change.

Retention Policy​

The decision log retention defaults are 336 hours (14 days) archiving of received OPA decision batches and then a smaller window of 72 hours (3 days) for the Elasticsearch to hold the latest decisions for search purposes.