跳转至

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.

Role Description
Create restricted view resource Needed on the folder/Project.
Create restricted view for dataset Needed on the dataset upstream of the restricted view.
Edit resource granular policy Edit the granular policy on resources.
Read resource granular policy Read the granular policy on resources.
Edit restricted view resource Needed to make edits on the restricted view (policy, assume Markings).
View restricted view resource View the properties of a restricted view (policy, assume Markings).
View restricted view transaction See historical transaction metadata (policy, assume Markings).

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 data source permissions on the dataset to see any objects of this type.

Restricted view policy management

Restricted view policies use granular policies to determine which rows a user can access. Learn more about designing granular policies, user attributes, policy comparisons, and policy limitations.

Restricted view limitations

Restricted views are similar to datasets but have some key differences. The contents combine two dynamic factors: the policy definition and the user's attributes and group memberships at a specific point in time. The policy definition history is maintained in the transaction history. However, it is impossible 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. This expectation is incompatible with restricted views, which provide 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 possible that each user may see different rows and aggregates in restricted views; 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 to protect the schema and columns from alteration in a way that could lead to the exposure of restricted data.

The following table summarizes the current limitations of restricted views:

Operation Is this supported by restricted views? Explanation
Reading Yes Restricted views can be read via objects or in Contour.
On-the-fly calculations Yes With restricted views, calculations can be performed from accessible rows via objects (such as in Quiver or Functions) or on datasets (with tools like Contour).
Writeback Yes Objects based on restricted views can have defined writebacks.
Exporting Yes Data from restricted views can be exported via Quiver, Contour, and other applications.
Batch-processing No Batch processing is not supported with restricted views, given that different users see different subsets of data.
Saving outputs as a Foundry dataset No Saving outputs based on transformations performed to restricted views is not supported; since Spark does not natively support row-level permissions, there is no way to enforce that subsequent transactions maintain the guarantees of restrictions.
Syncing to Postgres No Syncing a restricted view to Postgres is not supported because row-level permissions that depend on user attributes would not be maintained.

中文翻译

管理受限视图

使用受限视图支持对象类型

为了在对象浏览器(Object Explorer)中提供对特定对象类型中具体对象的访问权限，请在本体论管理器(Ontology Manager)中将受限视图设置为支持数据集。要成功配置并保存由受限视图支持的对象类型，您必须对受限视图的输入数据集拥有查看(View)权限。

受限视图文件权限

要创建和编辑受限视图，您必须满足在角色(Roles)界面的细粒度权限管理(Granular Permissions Administration)工作流中授予的以下条件。要访问角色界面，请导航至设置(Settings)，然后在侧边栏的平台设置(Platform Settings)部分中选择角色(Roles)。访问角色界面需要特殊的平台权限；如果您需要此级别的访问权限，请联系您的Palantir代表。

角色 描述
创建受限视图资源 需要在文件夹/项目上拥有此权限。
为数据集创建受限视图 需要在受限视图上游的数据集上拥有此权限。
编辑资源细粒度策略 编辑资源上的细粒度策略。
读取资源细粒度策略 读取资源上的细粒度策略。
编辑受限视图资源 需要对受限视图进行编辑（策略、假定标记）。
查看受限视图资源 查看受限视图的属性（策略、假定标记）。
查看受限视图事务 查看历史事务元数据（策略、假定标记）。

要构建受限视图，您必须对输入数据集拥有查看访问权限，并对输出受限视图拥有编辑权限。

要在Contour分析中使用受限视图，您需要读取受限视图(Read restricted view)权限。

要配置并保存由受限视图支持的对象类型，您必须满足以下条件：

  • 对受限视图的输入数据集拥有查看访问权限。
  • 对受限视图拥有编辑访问权限（用于查看/设置/更改策略）。
  • 是本体论管理员组的成员（用于访问本体论管理器）。

要在对象浏览器(Object Explorer)中使用基于数据集对象的细粒度策略，您必须对数据集拥有查看本体论数据源(View ontology data source)权限，才能查看此类型的任何对象。

受限视图策略管理

受限视图策略使用细粒度策略(granular policies)来确定用户可以访问哪些行。了解更多关于设计细粒度策略、用户属性(user attributes)、策略比较(policy comparisons)和策略限制(policy limitations)的信息。

受限视图限制

受限视图与数据集类似，但存在一些关键差异。其内容结合了两个动态因素：策略定义以及用户在特定时间点的属性和组成员身份。策略定义历史记录会保留在事务历史中。然而，事务历史不可能维护所有用户属性和组成员身份的完整历史记录。

受限视图旨在简化单个用户对管道的分析消费，不能用作数据转换的输入。在Foundry中构建的管道应具有可重现性，并且与运行管道的具体用户无关。这一期望与受限视图不兼容，因为受限视图提供依赖于用户属性的行级权限。

  • 尝试在包含受限视图的管道上进行协作的用户可能无法访问策略声明，也可能不具备相同的用户属性和组成员身份。因此，每个用户在受限视图中可能看到不同的行和聚合结果；用户不应假设基于细粒度权限数据的工作流与基于Foundry中常规数据集资源的工作流行为相同。

  • 对于下游转换，无法确保后续的下游转换会保留策略列。相比之下，受限视图是只读的，以保护模式和列不被更改，从而避免可能导致受限数据暴露的情况。

下表总结了受限视图的当前限制：

操作 受限视图是否支持？ 说明
读取 是 受限视图可以通过对象或在Contour中读取。
即时计算 是 使用受限视图，可以通过对象（如在Quiver或Functions中）或数据集（使用Contour等工具）从可访问的行执行计算。
回写 是 基于受限视图的对象可以定义回写操作。
导出 是 受限视图中的数据可以通过Quiver、Contour和其他应用程序导出。
批处理 否 受限视图不支持批处理，因为不同用户会看到不同的数据子集。
将输出保存为Foundry数据集 否 不支持保存基于对受限视图进行转换的输出；由于Spark本身不支持行级权限，因此无法确保后续事务维持限制的保证。
同步到Postgres 否 不支持将受限视图同步到Postgres，因为依赖于用户属性的行级权限将无法维持。