注意:以下翻译的准确性尚未经过验证。这是使用 AIP ↗ 从原始英文文本进行的机器翻译。

关于移除权限标记的指南

平台资源的访问要求由权限标记控制。权限标记以一种全有或全无的方式限制访问:为了访问资源,用户必须是应用于该资源的所有权限标记的成员。此外,权限标记在文件层次结构和直接依赖关系中都是继承的。如果您具有正确的权限,您可以直接从资源和沿着直接依赖关系中移除权限标记。

权限标记经常被使用,因为它们在整个平台中是易于理解的,并沿着直接依赖关系传播,保护敏感数据。在某些情况下,权限标记可能会在管道的早期阶段应用,并需要在管道的后期阶段移除。本页面提供了有关如何根据您的管道结构移除权限标记的更多信息。

场景

以下是三个与在管道早期应用权限标记并在管道后期移除它相关的场景。

场景1:通过移除权限标记替换断开

此场景适用于当管道:

  • 已经应用了权限标记,
  • 通过断开移除权限标记,并且
  • 项目级别的传播视图要求权限未开启。

因此,您正在从使用断开(一个已弃用的功能)迁移到移除继承的权限标记。

scenario1

在上面的示例中的旧状态中,已经使用断开来防止权限标记传播。假设断开仅用于移除权限标记,我们强烈建议您用权限标记移除替换断开,如上例中的新状态。当移除权限标记时,考虑包含权限标记移除变换的仓库的审批模式配置是有用的。

如果启用了传播视图要求,请阅读下面的场景2。

场景2:应用权限标记,然后移除权限标记以禁用"传播视图要求"

此场景涉及在管道中对数据集应用权限标记以禁用项目级别的传播视图要求设置。

propagate_view_requirement_off

如上所示,新项目默认禁用传播视图要求选项。对于这些新项目,视图要求将不会对下游派生数据集强制执行。具体来说,这意味着访问数据下游版本的用户在单独的项目中不需要访问在此配置被禁用的项目中的上游数据。

提醒

权限标记总是会传播。如果新项目中的数据有权限标记,则该权限标记仍将传播到所有下游数据集,无论"传播视图要求"设置如何。

propagate_view_requirement_on

如果您有如上图所示启用了传播视图要求选项的项目,那么这些项目中的数据集的视图要求已经传播。这意味着访问数据下游版本的用户在单独的项目中还需要访问启用此配置的上游项目。

我们强烈建议禁用视图要求传播,而使用权限标记

在禁用视图要求传播并将权限标记引入管道之前,值得考虑启用传播视图要求的初衷:

  1. 也许没有令人信服的理由启用"传播视图要求"。在这种情况下,您可能可以简单地禁用此设置,然后确保仅授予用户对其明确需要访问的数据集的访问权限。用户将不再需要访问先前传播视图要求的上游数据集。
  2. 项目中有一些敏感数据集。在这种情况下,最好将敏感数据集与非敏感数据集隔离开来,并按照下述步骤进行。以下步骤展示了如何用权限标记替换视图要求传播,这是针对这些场景的适当安全原语。
  3. 如果以下步骤不满足您的需求,请联系您的Palantir代表。

在下面的示例中,我们的目标是在数据源项目上禁用"传播视图要求"。在遵循上述步骤后,我们了解到项目上启用"传播视图要求"的原因是为了保护raw_dataset_1数据集,因为它包含敏感数据。

scenario2

在旧状态中,查看数据集A的内容至少需要在数据源项目和下游项目上具有“只读”访问权限。随后,已经使用断开移除数据集B上的视图要求传播。

在新状态中,查看数据集A的内容需要至少在下游项目上具有“只读”访问权限以及对权限标记的访问。注意,禁用"传播视图要求"后,要求访问数据集C & D仅需要在下游项目上具有“只读”访问权限。

此更改允许通过使用安全权限标记禁用"传播视图要求"。在下面的建议解决方案中,我们将在raw_dataset_1上应用权限标记,该标记随后立即传播到所有下游数据集中,凡是有任何未断开的raw_dataset_1事务作为输入的地方。假设断开已经到位,且断开仅被权限标记移除所替代。如果在您的情况下不属实,请参见场景3,我们将在其中详细讨论在数据集上应用权限标记的影响。

建议按照以下步骤引入此更改,以便在禁用数据源项目中的"传播视图要求"后添加权限标记时,用户不会失去对数据集B的访问权限:

  1. 创建一个新的权限标记,并给予相关用户对该标记的访问权限。
  2. raw_dataset_1上应用权限标记。
  3. 现在已经应用了权限标记,您可以安全地在数据源项目中禁用"传播视图要求"。
  4. 在变换中用权限标记移除替换断开,并确保断开和权限标记移除同时进行。
  5. 确保管道中的所有数据集已搭建。
  6. 从不再需要访问数据源项目的用户中移除他们。

场景3:在数据集级别应用一个新的权限标记,随后移除权限标记

这一潜在复杂的场景涉及在现有管道的早期引入一个新的权限标记,而不在管道后期意外锁定用户。

scenario3

关键的是要注意,数据集A上引入的权限标记将立即传播到该数据集下游的所有资源,沿着事务沿袭线。用户将需要该权限标记才能访问从标记数据集派生的任何内容。

为了更好地理解这一点,让我们将上面的示例扩展为如下管道:数据集A → 数据集B下游数据集:

  • 数据集A是一个原始数据集(即将被标记)。
  • 数据集B从数据集A派生,敏感数据已移除(因此可以移除权限标记)。
  • 下游数据集是从数据集B派生的,需要用户访问的数据集。

在此示例中的目标是确保下游数据集永远不会继承来自数据集A的权限标记。

首先需要了解的是,标记数据集A(或包含数据集A的文件夹)实际上标记了数据集A整个历史中的所有事务。结果是,数据集B下游数据集立即继承了该权限标记。

如果我们执行以下步骤:

  • 在数据集A → 数据集B变换中添加权限标记移除,
  • 更新数据集B的代码,并且
  • 重新快照数据集B ...

... 那么数据集B的最新快照事务将不再有权限标记,但数据集B上的所有较旧事务仍将被标记。

注意,尽管标记一个数据集将标记其所有事务,但在变换中移除权限标记只会从新输出事务中移除权限标记。权限标记不会从现有事务中移除。这种行为是不对称的。

这意味着从数据集B上的较旧事务派生的任何下游数据中的数据,例如增量搭建的下游数据集,仍将继承该权限标记。

为了确保每个增量下游数据集都未标记,必须在数据集B上应用取消标记变换后,下游数据集与取消标记变换之间的所有内容必须重新快照。这将确保每个下游数据集仅依赖于数据集B上的最新(未标记)事务,而不是较早的(已标记)事务。简单的重新搭建是不够的。

如果下游数据集的数量过多,无法手动触发重新快照,我们建议采取以下步骤:

scenario3_2
  1. 创建数据集A′并确保其内容与数据集A相同。
  2. 重写数据集B的代码,以将数据集A′用作输入,替代数据集A。同时,确保在变换中添加适当的权限标记移除,然后立即搭建数据集B。不需要对数据集B进行快照搭建。

考虑进行此交换的性能影响,因为这可能会触发数据集BSNAPSHOT搭建。

  1. 标记数据集A′
  2. 将数据集A移入回收站。
  3. 此时不再需要进一步的重新搭建。

如果您在重要管道中进行这些更改或对任何步骤不确定,请联系您的Palantir代表以获得帮助。

最佳实践

  • 不要将仓库设置为“无需重新审批”模式,除非绝对必要。
    • 如果您必须启用此模式,务必最小化该仓库的编辑者集合,并确保您获得此设置所需的批准(如果需要)。
  • 务必拥有明确、定义良好的标准,以确定什么资源需要权限标记。
  • 务必编写权限标记移除变换,以主动选择不需要权限标记的数据
  • 不要编写权限标记移除变换,以筛选出需要权限标记的数据。这是因为新数据可能在上游引入,而您需要防止其意外流过您的权限标记移除变换。
    • 显示“筛选入”方法的示例(推荐):
      Copied!
      1# 基于列 2df.select("salary","title","department") 3 4# 基于行 5states_to_keep =["OH","CA","DE"] 6df.filter(df.state.isin(states_to_keep))
    • 显示“筛选出”方法的示例(推荐):
      Copied!
      1# 基于列 2df.drop("firstname","lastname") 3 4# 基于行 5states_to_drop =["FL","TX","IL"] 6df.filter(~df.state.isin(states_to_drop))
  • 务必在实施敏感数据移除逻辑的变换中执行权限标记移除。
    • 不要在不同的仓库中抽象或隐藏此逻辑。
    • 同样,不要创建一个单独的权限标记移除仓库(具有一系列标识变换)。权限标记移除逻辑应在权限标记移除PR审查期间明确批准。
  • 务必尽可能在上游(当标记数据集被添加为导入时)或尽可能在下游(在创建项目导出之前的最后一步)从数据中移除权限标记,同时在项目内执行权限标记移除。

常见问题

每次代码逻辑发生更改时,我们是否需要对权限标记移除进行批准?

这取决于您的权限标记移除变换所在的仓库设置的是需要重新审批还是不需要重新审批审批模式。了解更多关于审批模式的信息。

权限标记移除工作流程和“一项目一仓库”建议不太兼容。我们应该为权限标记移除工作流程为每个项目设置多少个仓库?

理想情况下,每次权限标记移除变换的逻辑发生变化时,都应进行安全审批。为了在审批过程中的过度摩擦和良好的安全姿态之间取得平衡,我们建议如果可能的话,将所有带有权限标记移除逻辑的变换(如模糊数据、移除列等)移动到一个单独的仓库,并将该单独的仓库设置为“需要重新审批”。

我可以在变换的输出上添加权限标记移除属性(stop_propagatingstop_requiring)吗?

不行,这些是输入属性,不能添加到输出上。如果您的目标是从某个输出中移除权限标记,您需要识别所有携带权限标记的输入,并分别向它们添加stop_propagating语句。有关更多详细信息,请参阅输入变换属性文档。

哪些语言支持权限标记移除?

以下语言支持权限标记移除:

为什么权限标记移除比断开更受欢迎?

解密应该谨慎执行,不应分散在项目和仓库中。平台中的权限标记移除功能提供对权限传播更改的细粒度控制,并确保此类更改经过适当审查。

我们正在将仓库过渡到使用权限标记移除而不是断开。如何为新变换禁用断开?

请联系您的Palantir代表,以禁止在先前未启用断开的数据集上添加断开。