注意:以下翻译的准确性尚未经过验证。这是使用 AIP ↗ 从原始英文文本进行的机器翻译。
平台资源的访问要求由权限标记控制。权限标记以一种全有或全无的方式限制访问:为了访问资源,用户必须是应用于该资源的所有权限标记的成员。此外,权限标记在文件层次结构和直接依赖关系中都是继承的。如果您具有正确的权限,您可以直接从资源和沿着直接依赖关系中移除权限标记。
权限标记经常被使用,因为它们在整个平台中是易于理解的,并沿着直接依赖关系传播,保护敏感数据。在某些情况下,权限标记可能会在管道的早期阶段应用,并需要在管道的后期阶段移除。本页面提供了有关如何根据您的管道结构移除权限标记的更多信息。
以下是三个与在管道早期应用权限标记并在管道后期移除它相关的场景。
此场景适用于当管道:
因此,您正在从使用断开(一个已弃用的功能)迁移到移除继承的权限标记。
在上面的示例中的旧状态中,已经使用断开来防止权限标记传播。假设断开仅用于移除权限标记,我们强烈建议您用权限标记移除替换断开,如上例中的新状态。当移除权限标记时,考虑包含权限标记移除变换的仓库的审批模式配置是有用的。
如果启用了传播视图要求,请阅读下面的场景2。
此场景涉及在管道中对数据集应用权限标记以禁用项目级别的传播视图要求设置。
如上所示,新项目默认禁用传播视图要求选项。对于这些新项目,视图要求将不会对下游派生数据集强制执行。具体来说,这意味着访问数据下游版本的用户在单独的项目中不需要访问在此配置被禁用的项目中的上游数据。
权限标记总是会传播。如果新项目中的数据有权限标记,则该权限标记仍将传播到所有下游数据集,无论"传播视图要求"设置如何。
如果您有如上图所示启用了传播视图要求选项的项目,那么这些项目中的数据集的视图要求已经传播。这意味着访问数据下游版本的用户在单独的项目中还需要访问启用此配置的上游项目。
我们强烈建议禁用视图要求传播,而使用权限标记。
在禁用视图要求传播并将权限标记引入管道之前,值得考虑启用传播视图要求的初衷:
在下面的示例中,我们的目标是在数据源项目上禁用"传播视图要求"。在遵循上述步骤后,我们了解到项目上启用"传播视图要求"的原因是为了保护raw_dataset_1
数据集,因为它包含敏感数据。
在旧状态中,查看数据集A的内容至少需要在数据源项目和下游项目上具有“只读”访问权限。随后,已经使用断开移除数据集B上的视图要求传播。
在新状态中,查看数据集A的内容需要至少在下游项目上具有“只读”访问权限以及对权限标记的访问。注意,禁用"传播视图要求"后,要求访问数据集C & D仅需要在下游项目上具有“只读”访问权限。
此更改允许通过使用安全权限标记禁用"传播视图要求"。在下面的建议解决方案中,我们将在raw_dataset_1
上应用权限标记,该标记随后立即传播到所有下游数据集中,凡是有任何未断开的raw_dataset_1
事务作为输入的地方。假设断开已经到位,且断开仅被权限标记移除所替代。如果在您的情况下不属实,请参见场景3,我们将在其中详细讨论在数据集上应用权限标记的影响。
建议按照以下步骤引入此更改,以便在禁用数据源项目中的"传播视图要求"后添加权限标记时,用户不会失去对数据集B的访问权限:
raw_dataset_1
上应用权限标记。这一潜在复杂的场景涉及在现有管道的早期引入一个新的权限标记,而不在管道后期意外锁定用户。
关键的是要注意,数据集A上引入的权限标记将立即传播到该数据集下游的所有资源,沿着事务沿袭线。用户将需要该权限标记才能访问从标记数据集派生的任何内容。
为了更好地理解这一点,让我们将上面的示例扩展为如下管道:数据集A → 数据集B → 下游数据集:
在此示例中的目标是确保下游数据集永远不会继承来自数据集A的权限标记。
首先需要了解的是,标记数据集A(或包含数据集A的文件夹)实际上标记了数据集A整个历史中的所有事务。结果是,数据集B和下游数据集立即继承了该权限标记。
如果我们执行以下步骤:
... 那么数据集B的最新快照事务将不再有权限标记,但数据集B上的所有较旧事务仍将被标记。
注意,尽管标记一个数据集将标记其所有事务,但在变换中移除权限标记只会从新输出事务中移除权限标记。权限标记不会从现有事务中移除。这种行为是不对称的。
这意味着从数据集B上的较旧事务派生的任何下游数据中的数据,例如增量搭建的下游数据集,仍将继承该权限标记。
为了确保每个增量下游数据集都未标记,必须在数据集B上应用取消标记变换后,下游数据集与取消标记变换之间的所有内容必须重新快照。这将确保每个下游数据集仅依赖于数据集B上的最新(未标记)事务,而不是较早的(已标记)事务。简单的重新搭建是不够的。
如果下游数据集的数量过多,无法手动触发重新快照,我们建议采取以下步骤:
考虑进行此交换的性能影响,因为这可能会触发数据集B的SNAPSHOT
搭建。
如果您在重要管道中进行这些更改或对任何步骤不确定,请联系您的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))
这取决于您的权限标记移除变换所在的仓库设置的是需要重新审批还是不需要重新审批审批模式。了解更多关于审批模式的信息。
理想情况下,每次权限标记移除变换的逻辑发生变化时,都应进行安全审批。为了在审批过程中的过度摩擦和良好的安全姿态之间取得平衡,我们建议如果可能的话,将所有带有权限标记移除逻辑的变换(如模糊数据、移除列等)移动到一个单独的仓库,并将该单独的仓库设置为“需要重新审批”。
不行,这些是输入属性,不能添加到输出上。如果您的目标是从某个输出中移除权限标记,您需要识别所有携带权限标记的输入,并分别向它们添加stop_propagating
语句。有关更多详细信息,请参阅输入变换属性文档。
以下语言支持权限标记移除:
解密应该谨慎执行,不应分散在项目和仓库中。平台中的权限标记移除功能提供对权限传播更改的细粒度控制,并确保此类更改经过适当审查。
请联系您的Palantir代表,以禁止在先前未启用断开的数据集上添加断开。