Manage Restricted Views

Use Restricted Views to back object types

To provide access to specific objects of a given object type in Object Explorer, set a Restricted View as the backing dataset in the Ontology Manager. To successfully configure and save an object type backed by a Restricted View, you must have View access to the input dataset of the Restricted View.

Restricted View file permissions

To create and edit Restricted Views, you must meet the following criteria granted within the Granular Permissions Administration workflow in the Roles interface. To access the Roles interface, navigate to Settings and select Roles in the Platform Settings section of the sidebar. Access to the Roles interface requires special platform permissions; contact your Palantir representative if you require this level of access.

To build a Restricted View, you must have view access on the input dataset and edit permissions on the output Restricted View.

To use a Restricted View in a Contour analysis, you need the Read restricted view permission.

To configure and save an object type backed by a Restricted View, you must have:

• View access to the input dataset of the Restricted View.
• Edit access to the Restricted View (to view/set/change policies).
• Be a member of the Ontology admin group (for access to the Ontology Manager).

To use granular policies on dataset-backed objects in Object Explorer, you must have View ontology datasource permissions on the dataset to see any objects of this type.

Restricted View policy management

Policy comparisons

Restricted View policies support the following comparison types:

• Less Than: Both the left and right side of the comparison must be single-valued (not a collection) and of the same type.
• Less Than or Equal: Both the left and right side of the comparison must be single-valued (not a collection) and of the same type.
• Equal: Both the left and right side of the comparison must be single-valued (not a collection) and of the same type.
• Greater Than or Equal: Both the left and right side of the comparison must be single-valued (not a collection) and of the same type.
• Greater Than: Both the left and right side of the comparison must be single-valued (not a collection) and of the same type.
• Intersects: At least one side must be a collection, and both must be of the same type (or collection of that type).

Policies are defined as templates into which user attributes, group memberships, and data values can be filled:

When the consuming application of a granularly-permissioned resource requests data (such as in Contour), the policy template is converted into a query that only returns rows specific to the user’s attributes and permissions.

Policy limitations

A single policy can have up to ten comparisons. Restricted View policies weigh each comparison in the policy depending on whether the policy is comparing a collection or a constant against a field:

• A comparison of a constant against a field is given a weight of 1.
• A comparison of a collection against a field is given a weight of 1,000.
• The sum of the weights across all the comparisons in a policy must be under 10,000.

For example, in a basic policy:

• Rule (1) has a weight of 1 since it is matching a constant (the user’s ID) against a field.
• Rule (2) has a weight of 1,000 since it is matching a collection (all the groups the user is a member of) against the specific Platform Administrators group.
• The sum of the weights in this policy is 1,001 (well under the limit of 10,000).

The current policy construction limit is designed to put a minimal amount of constraints on a particular policy design; it provides little protection against a policy that could overwhelm weight limits.

If you receive weight limit errors when constructing policies, contact your Palantir representative for assistance.

Policy management

Changes to policies are recorded as new transactions on the Restricted View, but some users may require additional controls around policy change management.

When you manage Restricted View policies consider two goals:

• Transparency: Anyone responsible for managing data access should know the policies and how the policies interact with data in the platform.
• Robust change management: Policy management should be an orderly, organized process. Always review and manage changes before applying them.

Managing integrity of data pipelines

Restricted View policies introduce a set of assumptions about the data that backs them. Therefore, Restricted View policies will only correctly control access to data as long as these assumptions are true. Consider whether the use case requires building out machinery to ensure that those assumptions hold and data stays secured if those assumptions are broken.

One way to solve this problem is by introducing a step in the pipeline directly upstream of the Restricted View that checks the assumptions made about the data. These checks might include:

• Invariants: Write a list of invariants that will force the downstream build of the Restricted View dataset to fail if it is not true. For example, assume that whenever an event_occurred_in_state has the value NY, another column in the dataset called state_name should have value New York. Have the Transform check that this is true before surfacing this data to users.
• Statistics: Define a set of statistics and the range they should always be within. For example, a Restricted View may be used to enforce access controls mirroring an Organization hierarchy; each user can only see data about individuals below them in the hierarchy. Have the Transform assert that if more than 20% of the hierarchy changes from one day’s build to the next, something is wrong. At this point, users responsible for policy management should check to ensure everything is correct before surfacing this data to users.

Restricted View limitations

Restricted Views are similar to datasets but have some key differences. The contents of a Restricted View combine two dynamic factors: (1) the policy definition and (2) the attributes and group memberships of the particular user accessing the Restricted View at a specific point in time. While the policy definition history is maintained in a Restricted View’s transaction history, it is not possible for the transaction history to maintain a complete history of all user attributes and group memberships.

Restricted Views are designed to simplify the analytical consumption of pipelines by individual users and cannot be used as inputs to data transformations. Pipelines built in Foundry should be reproducible and agnostic to the specific user running them, which is incompatible with the nature of Restricted Views in providing row-level permissions that depend on user attributes.

• Users attempting to collaborate on a pipeline with Restricted Views may not have access to the policy statements and may not have the same set of user attributes and group memberships. Because of this, it is quite possible that each user may see different rows and aggregates in Restricted Views; thus, users should not assume that workflows based on granularly permissioned data will behave the same as workflows based on regular dataset resources in Foundry.
• With downstream transformations, there is no enforcement to ensure that subsequent downstream transformations preserve the policy column. By contrast, Restricted Views are read-only in order to protect the schema and columns from alteration in a way that could lead to the exposure of restricted data.

The following list summarizes the current limitations of Restricted Views: