Skip to content

Creating Policies in the UI

Who can create policies?

Catalog admins and users with the ability to grant (WITH GRANT OPTION) on at least one data object can grant permissions to roles. Users will only be able to grant policies to roles they have access to grant to, as defined by having ALL or MANAGE_PERMISSIONS on those ROLE objects.

Creating Policies in the UI

Policies can be created via the Roles page by selecting a role, or on the Data page under the 'Permissions' tabs. Click the 'Create new permission' button to add a permission to a role:

Create a permission

This will launch a dialog that prompts you to provide information about your new permission:

Create permission dialog

  • Which role should this permission apply to? This is the role you will be granting access to. On the Roles page, this section will be pre-populated as shown above.
  • What level of access should this role have? Select the degree of access to data this role should have. The access level you select may affect what other options are available. To learn more about access levels, see Privileges.
  • Which data objects should this role have access to? Use the 'Scope' dropdown to select the type of data object you want to grant access to (catalog, database, dataset, URI, or namespace attribute). Certain scopes may not be available depending on your access to data, and the access level you have selected. Once you have specified a scope, select the specific data object you want to grant access to. This dropdown will be limited to objects that you have ‘grant’ ability on.

If you wish to create an ABAC policy, select the access level ‘SELECT’, and add access conditions to your permission. Learn more about access conditions in the 'Adding Access Conditions' section below.

As you fill out these fields, the policy summary will update to show you a preview of your permission in both natural language and SQL. Use the toggle in the top right corner of the summary to switch between views:

Policy summary toggle

Once you’ve filled out all required fields and confirmed that your permission looks correct in the policy summary, click ‘Add permission’ to grant this new access to the role.

Adding Access Conditions

Access conditions allow you to filter or transform the data you are granting to in order to provide more secure access. To add an access condition, press the ‘Add an access condition’ button at the bottom of the dialog:

Add access condition button

There are three types of access conditions: 1. Restrict access based on tags 2. Transform data 3. Restrict access with row filtering

Access condition selection

Restricting Access Based on Tags

Select the 'Restrict access based on tags' condition if you want to limit access to data based on how that data is tagged. If you select this option, you can either choose a 'tagged' condition, or a 'not tagged’ condition.

Choose a ‘tagged’ condition if you want to only allow your selected role access to data objects with specific tags. In the example below, the selected role only has access to objects in the sales database that are tagged 'location: usa'.

Tagged condition

Choose a ‘not tagged’ condition if you want to prevent the role from accessing data objects with specific tags. In the example below, the selected role has access to all objects in the sales database except those tagged 'pii: phone_number'.

Not tagged condition

See Managing Tags for more information about creating and assigning tags to data.

Transforming Data

Select the 'Transform data' condition if you want to obscure certain tagged data or change how it appears to your selected role, e.g. with masking or tokenizing.

The ‘Tags’ dropdown lets you select which tagged data you want to transform, and the ‘Transform type’ dropdown lets you select what kind of transformation you want to apply to this data. In the example below, the selected role will have access to all data objects in the sales database, but objects tagged 'pii: email_address' will have their data masked.

Transform condition

There are several basic transform types available, but if you want to transform data with a different type or with a more complicated expression, select the ‘Custom SQL’ transform type to use a custom SQL expression.

Custom SQL condition

Please note that transforming data is not the same as restricting access to data. If you add a ‘Transform data’ condition to your permission, your selected role will still be granted access to the transformed data, but will see an obscured version of the data if they access it.

Below is an example of what a role would see if columns tagged 'pii: credit_card' were masked with a ‘Transform Data’ condition:

Transformed data preview

Restricting with Row Filtering

Select the 'Restrict access using WHERE clause' condition if you want to limit access to data based on the content of the data itself. In the example below, the selected role only has access to data in the sales database where columns named ‘state_s’ have a value of ‘CA’.

Where clause filter condition

Below is what this role would see when previewing a dataset in the sales database compared to what an admin might see:

Where clause preview

To learn more about implementing column and user attribute based access conditions with row filtering you can learn more here

Adding Multiple Access Conditions

You can add multiple different access conditions to a given permission, but there are some limitations on what conditions may be added in succession.

  • You may not repeat tags within condition types. Each tag can only be used once per condition type. For example, if you apply a mask transformation to data tagged ‘pii: email_address’, you may not then apply a tokenize transformation to data tagged ‘pii: email_address’. This is to avoid logical conflicts within conditions.

  • You may not repeat 'restrict' condition types. You may add a maximum of two ‘Restrict access based on tags’ conditions per permission - one ‘tagged’ and one ‘not tagged’. Similarly, you may only add one 'Restrict access using WHERE clause' condition. This is to avoid redundant and potentially confusing permissions.

Due to these limitations, certain permissions added via Workspace or created prior to the Okera 2.1 release will not be available for editing. To learn more about editing and managing policies, go to Editing Permissions.

Permission Conflicts

Attempting to create a new permission may sometimes generate a conflict warning, as shown here:

Conflict error

Learn more about permission conflicts here.