Policies

DQ0 uses a powerful permission and policy system based on the Open Policy Agent policy system: https://www.openpolicyagent.org/docs/latest/

Policies are defined in Rego syntax. Please refer to the Rego documenation at openpolicyagent.org for details about syntax and rules.

Every action that the DQ0 platform can perform is covered by one or more rego policies. Most policies depend on the base roles of "admin", "owner" and "user". But this, as everything else in DQ0's policy system, can be freely changed by DQ0 adminstrators.

Base and User defined Policies

DQ0 comes with base policies that guarantee a robust and secure use of the platform with privacy-preserving analytics. Generally, data owners are allowed to see and edit data properties, inspect user actions (auditing) and approve user requests. Data scientist users are allowed to start jobs and inspect approved results. Approvals of results can be automated by policies or may require manual approval processes by data owner users.

Users of the DQ0 platform can define their own policies and overrule conditions in the base policies. The DQ0 permissioning system is therefore very flexible and completely customizable.

Rego policies are used for all actions in the platform. Input to each policy is a list of JSON formatted database objects that are affected by the action and the desired action. Optionally, additional inputs and queries can be defined.

The output of a policy evaulation is defined by

• allow a boolean value indicating whether the action is allowed by the policy rules.
• deny a boolean value indicating whether the action is denied by the policy rules.

Since an action is only allowed when allow is true and deny is false users can easily add additional allow rules or deny rules to either extend allow or deny list for the given action.

How to write OPA Queries

OPA Policy decisions will be implemented in dq0-platform, mostly in the “internal” package where the actions are handled.

OPA works by receiving a Query (a JSON document describing a desired policy request) and validating it against a set of (hierarchical) policies (written in OPA’s rego language) and external data (again as JSON documents).

A DQ0 example:

• Query: “I like to get information about Dataset D” (DataInfo action request)
• Policy: set of rules with respect to user roles, dataset relations and attributes
• Data: User and Data objects (and maybe more) retrieved from the dq0-platform database.

Example code:

package datasets.get

# required rego rules
import data.datasets.general.general_allow
import data.global.global.global_deny
import data.global.global.lists_intersect
import data.global.global.user_has_role

# list of deny tags
tag_deny_list := [
    "no-details",
]

# some input.dataset.meta child (=schema) has the privacy level
input_dataset_meta_has_privacy_level(privacy_level) {
    input.dataset.meta[_].privacy_level == privacy_level
}

# GET ALLOW
default get_allow = false

# allow general
get_allow {
    general_allow
}

# allow input.user to get datasets, if she has the "owner" role
get_allow {
    user_has_role(input.user, "owner")
}

# allow input.user to get datasets, if she has the "user" role
get_allow {
    user_has_role(input.user, "user")
}

# GET DENY
default get_deny = false

# deny global
get_deny {
    global_deny("get", "active")
}

# deny missing dataset tags
get_deny {
    not input.dataset.tags
}

# deny denied datasets
get_deny {
    lists_intersect(input.dataset.tags, tag_deny_list)
}

# ALLOW
default allow = false

allow {
    get_allow
    not get_deny
}

Via input.data your rego policies have access to all used objects in the evaluated action. If a dataset in involved for example, this includes the complete metadata information of the dataset. It is therefore possible to use metadata information directly in a policy. For example:

allow_meta {
    input.data.meta.schema.privacy_level == 0
}

With data metadata like this (snippet):

name: Adult Census Income
description: 'This data was extracted from the 1994 Census bureau database by...'
schema:
  connection: census_processed.csv
  privacy_budget: 1
  privacy_budget_interval_days: 0
  privacy_level: 2

Policy Editor

You can use the DQ0 Studi0 web application to edit the policies. Note that all policies added to the platform must have a order number that defines the priority of the policy. Policies with higher numbers are loaded and evaluated later than those with lower numbers. All policies with order numbers less than 100 are considered platform default and are not editable (but of course you can overwrite these policies with higher numbered ones).