Skip to main content

Decision Masking

Decision masking allows you to remove information from each decision before it gets logged by OPA in Styra DAS. This is useful for removing sensitive information, such as an Authorization header, from the decision's input or result before it is added to the decision log. The system.log and stacks.<stack-id>.system.log packages define OPA's decision masking rules at the system-level and stack-level, respectively.

All Styra DAS System and Stack types support OPA decision masking. Additionally, the Kubernetes and Envoy System and Stack types automatically include a default decision masking policy upon creation which can be customized to your use case:

note

For more information on decision masking, see Masking Sensitive Data.

OPA supports a system.log package with drop rules to filter out decisions users may not want to send to the Styra DAS decision log.

note

For more information on how to drop decision logs, see Drop Decision Logs.

Create a Decision Masking Policy​

For System and Stack types other than Kubernetes and Envoy, you can manually create a decision masking policy through the Styra DAS UI or a Git integration by placing a rego policy file under /systems/log/ in the System or Stack.

To create the decision masking policy in the Styra DAS UI, follow the steps below:

  1. In your Styra DAS Workspace, use the left-side file tree and select your System or Stack.

  2. Click the ( ⫶ ) options icon on your System or Stack and select Add Policy.

  3. Add a policy with the following details:

    • Path: system.log
    • Module name: mask.rego

  4. Click Add

input or result decision masking rules can be added which are specific to your System or Stack to this policy.

Decision Masking Example​

As an example, if your decision input object includes an access_token field which should be removed from the decision log, you would add the following rule to your decision masking policy:

mask["/input/access_token"]

This will remove the field and value entirely from the input object and the removed path will be recorded in the erased array on the decision.

Alternatively, you can leave the access_token field in the input object and instead modify the field's value to remove the sensitive information:

mask[{"op": "upsert", "path": "/input/access_token", "value": x}] {
    x := "**REDACTED**"
}

With the upsert masking operation, the input object will contain "access_token": "**REDACTED**" and the masked path will be recorded in the masked array on the decision.