管理 Lakeflow 作业的标识、权限和特权

Lakeflow 作业使用两组权限：作业权限用于控制谁可以查看、运行和管理作业，以及 Run as 权限用于确定作业访问数据和其他资源时使用的身份。本文介绍这两者以及治理最佳做法。

注意

机密信息不会从经典计算资源中 Spark 驱动程序的 stdout 和 stderr 流中脱敏。为了保护敏感数据，默认情况下，在专用或标准访问模式下，Spark 驱动器日志仅对在作业计算资源和通用计算资源上具有 CAN MANAGE 权限的用户可见。同样的默认值也适用于从池创建的计算资源。若要允许用户具有 CAN ATTACH TO 或 CAN RESTART 权限查看日志，请在计算的 Spark 配置字段中设置以下属性： spark.databricks.acl.needAdminPermissionToViewLogs false

在没有隔离共享访问模式的旧计算中，可以使用 CAN ATTACH TO、CAN RESTART 或 CAN MANAGE 权限的用户查看 Spark 驱动程序日志。若要限制只有具有“CAN MANAGE”权限的用户才能读取日志，请将 spark.databricks.acl.needAdminPermissionToViewLogs 设置为 true。

由于 spark.databricks.acl.needAdminPermissionToViewLogs 是计算级 Spark 属性，因此必须在需要它的每个计算上设置它。对于通过 jobs/runs/submit 提交的临时作业运行实例（例如由外部编排程序触发的运行实例），请在提交时在 new_cluster.spark_conf 中设置该属性，并同时添加任何 access_control_list 条目。

作业特权和以某用户身份运行

作业是 Azure Databricks 中的对象，具有允许访问或管理这些作业的权限。本页将这些特权描述为 作业特权 （或权限）。

作业还代表具有自己权限的用户（或主体）运行和执行任务，以操作作业所引用的资源。作业所模拟的用户称为“以用户身份运行”，而此页面上的这些特权称为“以用户身份运行的权限”（或权限）。运行作业时，将使用 “以用户身份运行 ”权限。

例如，如果用户 A 创建作业并将 运行方式 用户设置为 用户 B，则作业将使用用户 B 的权限运行。如果用户 C 运行作业，该作业仍使用用户 B 的权限运行。这意味着，可以让某人能够运行作业，从他们自己无权访问的数据集获取信息。

作业的默认权限

作业默认设置了以下权限：

作业的创建者被授予对作业的 IS OWNER 权限。
工作区管理员被授予“CAN MANAGE”权限来管理作业。
作业的创建者被设置为以...身份运行。
运行作业时使用 以...身份运行 的用户权限（包括作业中的任务）。

由于默认设置是将创建者同时设置为所有者和 Run as 用户，因此在默认情况下，运行作业时会使用创建者的权限。 Databricks 建议将 以...身份运行 用户更改为服务主体，以便特权可以独立于所有者的权限进行控制，从而在所有者离开或更改权限时，不会导致作业中断。

作业的管理员权限

默认情况下，工作区管理员可以将作业所有者或运行身份配置更改为工作区中的任何用户或服务主体。帐户管理员可以配置 RestrictWorkspaceAdmins 设置以更改此行为。请参阅限制工作区管理员。

作业如何与 Unity Catalog 权限交互

作业以用户在运行方式设置中的身份运行。运行任务时，会根据这些任务中使用的以下资源的权限授予来评估此标识：

Unity Catalog 托管的资产，包括表、存储卷、模型和视图。
旧版 Hive 元存储中注册的资产的旧表访问控制列表 (ACL)。
计算、笔记本、查询及其他工作区资源的 ACL。
Databricks 的机密信息。请参阅机密管理。

注意

Unity Catalog 授权和遗留表的 ACL 都需要兼容的计算访问模式。请参阅配置作业的计算。

评估权限时

当用户对该作业执行操作时，例如编辑或运行作业，将会评估该作业的权限。

在作业运行期间评估运行方式权限。因此，每个任务可能会在任务启动时或运行期间检查特权。

注意

并非所有 运行方式权限 都在作业运行开始时进行验证。如果在作业运行期间更改“以用户身份运行”的权限，尤其是在移除权限时，作业可能会在完成前失败。

SQL 任务和权限

文件任务是唯一完全服从 运行方式 用户的 SQL 任务类型。

SQL 查询和警报遵循配置的共享设置。

“以所有者身份运行”：计划的 SQL 任务的运行始终使用已配置的 SQL 资产所有者的标识。
“以查看者身份运行”：计划的 SQL 任务的运行始终使用作业“运行身份”字段中设置的标识。

要了解有关查询共享设置的详细信息，请参阅配置查询权限。

示例

以下应用场景演示了 SQL 共享设置和作业“运行身份”设置的交互：

用户 A 是名为 my_query 的 SQL 查询的所有者。
用户 A 将my_query配置为共享设置以所有者身份运行。
用户 B 将 my_query 计划为名为 my_job 的作业中的任务。
用户 B 将 my_job 配置为使用名为 prod_sp的服务主体进行操作。
my_job 运行时，它将使用用户 A 的标识来运行 my_query。

现在假设用户 B 不需要此行为。从现有配置开始，将发生以下情况：

用户 A 将 my_query 的共享设置更改为“以查看者身份运行”。
my_job 运行时，它使用标识 prod_sp。

配置作业运行的用户身份设置

若要更改“运行身份”设置，必须对作业具有“可管理”或“为所有者”权限。

可以将“运行身份”设置设为自己，也可以设置为自己具有“服务主体用户”权利的工作区中的任何服务主体。

若要在工作区 UI 中为作业配置“运行身份”设置，请使用以下步骤选择现有作业：

在 Azure Databricks 工作区的边栏中，单击作业和管道。
（可选）选择 “任务” 和 “我拥有的” 筛选器，以便更轻松地查找任务。
单击列表中的作业名称。
在 “作业详细信息 ”窗格中，单击 “运行方式 ”字段旁边的铅笔图标。
搜索并选择用户或服务主体。
单击“ 保存”。

有关使用服务主体的更多信息，请参阅以下内容：

将“运行方式”设置为“组”

将作业的 运行身份 设置为组，与将其设置为用户或服务主体时的效果相同：作业将以该身份的权限运行。当 运行身份 为组时，所有任务都以该组身份运行，使用该组的权限访问数据，并且审计日志将 identity_metadata.run_as 记录为该组。由于作业始终由 Jobs 服务的应用程序服务主体执行，因此 identity_metadata.run_by 始终记录该身份。运行期间创建的工作区资产（笔记本、查询、文件）归组所有。

您无需属于该组即可将 Run as 设为该组。如果以组身份创建作业，Azure Databricks 会自动将该作业的 所有者 和 运行身份 都设置为该组。您还可以手动将 Run as 设为组。若要手动将 运行身份 配置给某个组，必须执行以下任一操作：

属于该组，或
如果该组用于独占访问，则需具有该组的“Assume”权限。

该组必须是分配给工作区的账户组。工作区本地组不能用作运行身份标识，宽泛的内置组 admins、users 和 account users 也不能。

由于作业以组的身份运行，因此该组需要访问作业使用的所有内容，包括对作业笔记本和工作区文件的读取权限。仅仅给自己授予访问权限是不够的。

要将 运行身份 配置为一个组：

工作区 UI

在 Azure Databricks 工作区的边栏中，单击作业和管道。
单击列表中的作业名称。
在 “作业详细信息 ”侧窗格中，单击 “运行方式 ”字段旁边的铅笔图标。
搜索并选择一个组。
单击“ 保存”。

REST API

将 run_as.group_name 设置为该组的名称。例如，以下请求体创建一个作为组运行的作业：

{
  "name": "sales-etl",
  "run_as": {
    "group_name": "Test Group"
  }
}

完整请求请参见创建作业。

捆绑包

在作业资源的group_name映射中设置run_as：

resources:
  jobs:
    sales_etl:
      name: sales-etl
      run_as:
        group_name: Test Group

顶层映射和目标 run_as 映射仅接受 user_name 或 service_principal_name。请参阅指定声明性自动化捆绑包工作流的运行标识。

默认情况下，捆绑包会将其文件部署到部署用户的主文件夹，而该文件夹是组无法读取的。将 workspace.root_path 设置为共享位置，比如位于 /Workspace/Shared 下的文件夹，并向该组授予对该文件夹的 CAN VIEW 权限。请查看文件夹 ACL。

默认情况下，任务作为 “运行方式 ”组运行。如果单个任务的计算资源是分配给另一主体的专用访问模式群集，则该任务将改为以分配给该群集的主体身份运行。

有关将组用作角色的详细信息，请参阅基于角色的访问控制（RBAC）。

作业管理最佳做法

Databricks 建议对所有生产作业执行以下操作：

使用服务主体运行生产作业

默认情况下，作业以作业创建者 身份运行 。如果以身份运行的用户离开组织，作业可能会失败。

如果将 运行身份用户指定给服务主体，作业运行时将使用该服务主体的权限，并且不会因用户离职或权限发生变更而改变。

默认情况下，工作区管理员可以根据需要管理作业权限并重新分配所有权。

使用服务主体进行生产作业还能限制对生产数据的写入权限。如果你使用用户的权限运行作业，则该用户需要相同的权限才能编辑作业所需的生产数据。
始终使用兼容 Unity Catalog 的计算配置

Unity Catalog 数据治理要求使用支持的计算配置。

作业和 SQL 仓库的无服务器计算总是使用 Unity Catalog。

对于具有经典计算的作业，Databricks 建议对支持的工作负荷使用标准访问模式。根据需要使用专用访问模式。

配置有 Unity 目录的 Lakeflow 管道存在一些限制。请参阅限制。
限制生产作业的作业特权

作业权限控制谁可以查看、运行或管理作业。
- 查看作业配置或监控运行的用户需要拥有“可查看”权限。
- 触发、停止或重启作业运行的用户需要“可以管理运行”权限。
- 仅向受信任的用户授予“可管理”或“为所有者”权限以修改生产代码。

控制对作业的访问

作业所有者和管理员可以通过作业访问控制授予对作业的精细权限。可以使用以下权限：

注意

每个权限都包含下表中其下面的权限授予。

权限	授予
是所有者	默认情况下，“以...身份运行”所使用的标识。可以将 “运行方式”设置为替代此用户。
可管理	可以编辑作业定义，包括配置、任务和权限。可以暂停和恢复计划。
可管理运行	可以触发和取消作业运行。
可查看	可以查看作业运行结果，包括详细信息、历史记录和状态。

默认情况下，作业的创建者具有 IS OWNER 权限。
作业不能有多个所有者。
无法将组作为所有者分配 IS OWNER 权限。
通过 “立即运行” 触发的作业假定 运行为 用户（默认情况下是所有者）的权限，而不是发出 “立即运行”的用户。
作业访问控制适用于 作业和管道 UI 中显示的作业及其运行。它不适用于：
- 运行模块化或链接代码的笔记本工作流。这些使用笔记本本身的权限。如果笔记本来自 Git，则会创建一个新副本，其文件将继承触发运行的用户的权限。
- API 提交的作业。除非你在 API 请求中显式设置， access_control_list 否则这些权限将使用笔记本的默认权限。

有关作业权限级别的信息，请参阅作业 ACL。

配置作业权限

若要在工作区 UI 中配置作业的权限，请使用以下步骤选择现有作业：

在 Azure Databricks 工作区的边栏中，单击作业和管道。
（可选）选择作业和归我所有筛选器。
单击作业的名称链接。
在 “作业详细信息 ”窗格中，单击“ 编辑权限”。此时将显示权限设置对话框。
单击“选择用户、组或服务主体...”字段，然后开始键入用户、组或服务主体。该字段搜索工作区中的所有可用标识。
单击“添加” 。
单击“ 保存”。

若要更改或删除现有权限，请单击“ 编辑权限 ”以打开 “权限设置 ”对话框。若要更改权限，请在标识旁边的下拉列表中选择不同的级别。若要删除权限，请单击标识旁边的 x 。

管理作业所有者

只有工作区管理员可以编辑作业所有者。必须只分配一个作业所有者。作业所有者可以是用户或服务主体。

笔记本任务和 API 访问

通过 UI 运行笔记本任务时，仅当用户有权访问基础笔记本时，才能访问输出（在笔记本中）。但是，当同一作业通过 API 运行时，即使 API 用户仅有权访问作业本身，而不是笔记本，运行输出也对 API 可见。

上次更新时间为 2026-10-23