在 Databricks 上的 Unity Catalog 数据治理——身份识别与管理在面向客户的岗位上，一个好处是能出

“做你自己；其他人都已经名花有主了。”
—— 奥斯卡·王尔德（Oscar Wilde）

在面向客户的岗位上，一个好处是能出差、去不同的城市。如果你和 Karthik 一样，喜欢旅行、住舒适的酒店，那么想象一下：去一座新城市开会，住进一家设施现代的酒店。从订房到退房，中间都有哪些步骤？

第一步是预订：你选择酒店和房型，填写入住信息，并提供个人信息和支付方式。接着是入住：到店出示证件，领取门卡。在入住期间，你可以进入分配给你的房间以及一些公共区域。离店时，你在前台归还门卡完成退房。整个住宿期间，酒店会为安全与服务目的记录你的行为。例如，你可能会享用客房内的小冰箱（minibar），这通常需要额外付费，并会被跟踪与计费。这些看似琐碎的环节，其实正是 IAM（三 A） 在现实世界中的例子：认证（authentication） 、授权（authorization）与审计（auditing） 。

把酒店看作一个系统：要访问该系统，你必须满足一定条件。预订时，你定义了身份属性；入住时，前台核验你的证件，这就是认证；你只能进入自己的房间，这是授权；酒店对门卡和付费服务的使用记录，就是审计。另外你也知道，酒店员工有特权门卡，可出于工作进入任意房间。这些带有特权的活动属于管理（administration） ，可被视为 IAM 的第四根支柱。

IAM 的两大职能：

身份管理（Identity management）
在 IAM 语境中，身份是被允许访问系统资源的实体的数字化表示。身份管理涉及对试图访问系统资源的用户、服务、系统等实体进行验证与认证。
访问管理（Access management）
访问管理是控制与监控已认证实体在系统中可以访问哪些资源。

注释
任何供多人使用的系统都需要实施 IAM。此外，IAM 是数据与 AI 治理的关键组成部分：它用于保护对数据与 AI 资产的访问，并落实合规与风险管理。毋庸置疑，Databricks 将 IAM 作为其平台的核心。

如果你是 Databricks 新手，且有使用 SaaS 的背景，单靠阅读文档可能会觉得概念繁杂。因此，本章将先介绍 Databricks 的一些基础构件，再逐步过渡到 IAM 的概念。本章重点聚焦 IAM 中的身份管理，而访问管理会在第 5 章更深入地展开。

Databricks 构件（Databricks Constructs）

若你使用过 Databricks 平台，一定接触过 工作区（workspace） 的界面。工作区是一个由多种云资源组成的 Databricks 构件，允许用户创建、访问与管理工作区资产。实践中常常不止一个工作区；许多组织会用独立工作区来隔离不同开发环境、团队或业务单元的资产。

正如第 2 章简述的，Databricks 工作区会关联一个 Unity Catalog metastore（也是 Databricks 构件），用于存放你全部数据与 AI 资产的元数据。Unity Catalog metastore 存在于云区域粒度；一个工作区只能关联到同一云区域内的 metastore。

一个组织内的全部工作区通常隶属于一个称为 Databricks 账号（account） 的实体。账号是另一种 Databricks 构件，允许管理员创建/管理工作区与 UC metastores，并配置适用于所有工作区的设置。

图 3-1 展示了 Databricks 账号、工作区与 UC metastore 之间的关系：一个 Databricks 账号可以拥有多个工作区与多个 metastore；同一云区域内的所有工作区都关联到该区域的唯一 metastore。换言之，每个云区域只能有一个 metastore。

图 3-1. Databricks 账号、工作区与 Unity Catalog metastore 的关系

云厂商相关细节（Cloud-Specific Details）

由于 Databricks 的这些构件建立在云概念之上，我们分别从 AWS、Microsoft Azure 与 GCP 的语境简要说明 Databricks 账号/工作区层级。

Databricks on AWS

为简化起见，假设你的组织只有一个 AWS 组织单元（OU） 与多个 AWS 账号。你可以在多个 AWS 账号中创建隶属于同一 Databricks 账号 的工作区。换句话说，一个 Databricks 账号可以跨越多个 AWS 账号。虽然你也可以创建多个 Databricks 账号，但推荐只用一个账号，以降低在身份、元数据、协作与数据分发方面的复杂度。另一方面，你需要考虑 Databricks 对单账号可创建工作区数量的上限。图 3-2 展示了 Databricks 与 AWS 账号构件之间的映射与基数关系。

图 3-2. Databricks 与 AWS 账号构件的映射关系

Azure Databricks

Databricks 在 Azure 上是一方服务（first-party） 。这意味着你可以像使用原生 Azure 服务一样使用 Azure Databricks。图 3-3 展示了 Azure Databricks 与 Azure 云构件之间的关系与基数。在一个组织中，通常只有一个 Microsoft Entra ID 租户。对于某个 Entra ID 租户，你只能拥有一个 Azure Databricks 账号。不过，你可以在多个 Azure 订阅下创建多个 Databricks 工作区。与 AWS 不同，Azure 没有关于“每账号最多可建多少工作区”的硬性文档限制；我们见过大型组织拥有1000+ 工作区。

图 3-3. Azure Databricks 与 Azure 账号构件的映射关系

注释
与 AWS/GCP 不同，Azure 上未规定工作区数量上限，且新建工作区更为便捷。这导致不少客户大量创建工作区，有时缺乏整体设计考量。多数情况下，建新工作区的理由是隔离工作区级资源。
建议在创建工作区时采取设计先行的做法，可考虑：

业务单元级隔离：为各 BU 明确划分资源；

运营层级隔离：如开发/预生产/生产；

平台级隔离：部分团队需要启用仅工作区级可控的特性；

数据类别隔离：如需专门处理/匿名化敏感数据集；

项目级隔离：特定项目出于合规需要需要独占资源。
关键是依据组织的真实需求制定清晰标准；并通过监控与流程来强制执行这些标准。

Databricks on GCP

假设组织有一个 GCP 组织（Organization） ，则通常对应一个 Databricks 账号，以及分布在 GCP 文件夹/项目中的多个 Databricks 工作区。图 3-4 展示了 Databricks 与 GCP 构件之间的关系与基数。

图 3-4. Databricks 与 GCP 账号构件的映射关系

访问 Databricks 与其所管理的云资源（Access to Databricks and Beyond）

Databricks 平台是云托管的解决方案。这意味着当你部署 Databricks 时，会在底层云厂商处创建必要的资源：网络、存储、安全组件等。平台投入使用后，它会为满足你的请求在云中继续创建新资源。你也可以把更多云资源（如对象存储）关联到平台，由平台来管理其上的资产。换句话说，会有一批云资源处于 Databricks 平台的作用域内。

这些 Databricks 作用域内的云资源（尤其是计算与存储）应通过 Databricks 来访问，并在 Databricks 平台的对象上设置访问控制——这些对象大多是云资源之上的抽象。例如，一个工作区里的 Spark 集群，在底层云中体现为一个或多个 虚拟机（VM） 。虽然只要你有云厂商 IAM 权限也能直连云资源，但强烈不建议这么做，因为这等于绕过 Databricks 提供的强安全与治理能力。第 5 章会更深入讨论权限建模与访问控制机制。

理想/典型的 Databricks 架构如图 3-5：用户、应用与服务通过 Databricks 访问平台内的资源、工件、工具与资产。平台用户不直接访问底层云中的资源与资产；对云资源的访问在 Databricks 内进行配置，从而把访问原生云资源的复杂性对终端用户屏蔽。访问控制也施加在 Databricks 对象上。简而言之，Databricks 是一种 PaaS。

图 3-5. 对云资源的访问在 Databricks 内进行配置

下面是通顺、准确的中文翻译（保留原有小节、注释与“图示/表格”提示，便于阅读与引用）。

Databricks 可控对象（Securables）

访问控制，说白了就是“谁能访问什么”，对吧？当然现实要复杂一些，但先这样理解。这里的“谁”称为主体（principal） ，即可以访问某个资源或资产的身份（详见“Databricks 身份”）。而“什么”指需要避免不必要或不受欢迎访问的对象——在数据平台语境下，包括计算集群、文件、数据与 AI 资产等。我们将这些统称为可控对象（securables） 。

在 Databricks 平台中，可控对象分为工作区级与metastore 级：

工作区可控对象（Workspace securables）
指工作区层面的对象，如 clusters（集群） 、jobs（作业） 、notebooks（笔记本） 等。它们的作用域限定在单个工作区，仅能从该工作区访问，生命周期也与该工作区绑定。
Unity Catalog 可控对象（Unity Catalog securables）
指 metastore 层面的对象，如 catalogs、schemas、tables、views 等。它们的作用域限定在单个 metastore，并可从与该 metastore 关联的任意工作区访问。

若你不是账号管理员（account admin） ，你将无法访问账号控制台或账号 API。

Databricks 身份（Databricks Identities）

在 Databricks 中，身份存在于账号层面，你可以允许这些身份访问账号与工作区，并可在 Databricks 的可控对象上为其授予权限。与其他 PaaS/SaaS 一样，身份是 Databricks 中 IAM 的核心组成部分。

Databricks 身份类型（Databricks Identity Types）

Databricks 中有三类身份：

用户（User）
人类用户的数字化表示，以电子邮箱唯一标识。
服务主体（Service principal）
应用、服务与自动化工具使用的技术型/非人类身份，以其标识符唯一标识。
用户组（Group）
若干用户与/或服务主体的集合。用户组可以包含另一个用户组，形成嵌套结构；在账号层以其名称唯一标识。

**认证（authentication）**适用于用户与服务主体；授权（authorization）适用于上述三类身份。

Databricks 中的用户组

Databricks 中有三类用户组：账号级组（account groups） 、系统组（system groups） 与 工作区本地组（workspace-local，旧版） 。
Unity Catalog 可控对象的权限只能授予账号级组。系统组由 Databricks 创建与维护，且不可删除：

账号层面有一个系统组 account users，包含账号内所有用户与服务主体；
工作区层面有两个系统组：users（该工作区内的所有用户与服务主体）与 admins（拥有工作区管理员角色的所有用户）。

预定义管理员角色与职责（Predefined Admin Roles and Responsibilities）

从平台视角看，与 Databricks 交互的身份大致分两类：

平台用户：实现业务用例；
平台管理员：管理平台、支撑用例开发，并在安全与成本方面落实组织策略。

你可以允许平台用户访问一个或多个工作区，并在可控对象上授予其权限。平台中有三类主要的管理员角色拥有特权访问，可执行特定管理操作（见图 3-6）。

图 3-6. Databricks 管理员层级关系

表 3-1 列出了主要管理员角色、职责/任务及其典型执行频率。

表 3-1. Databricks 预定义管理员角色与职责

范围	角色	职责/任务	管理频率（大致）
Databricks 账号	Account admin（账号管理员）	账号级用户开通配置	一次性
		网络安全配置管理	低频
		功能开关启用/禁用	低频
		重大问题/事故处置（如误删用户）	低频
工作区	Workspace admin（工作区管理员）	创建账号级用户组	频繁
Unity Catalog metastore	Workspace admin（工作区管理员）	创建 UC 可控对象（catalog、external locations、storage credentials）	频繁
		将对象所有权委派给指定用户/用户组	频繁
	Metastore admin（metastore 管理员）	创建并管理所有 UC 可控对象	可选
		授予如“CREATE CATALOG”等 metastore 级权限给选定用户/组	可选（取决于数据架构）
Databricks 工作区	Workspace admin（工作区管理员）	创建与管理计算资源及其策略	频繁
		将账号级用户组分配到工作区	频繁
		管理工作区特性与设置	频繁

账号管理员（Account admin）

这是 Databricks 平台中权限最高的特权角色。成为账号管理员即可访问 Databricks 账号控制台与账号 API。账号管理员可以为自己开通对任意工作区的访问，并在工作区与 metastore 上将管理员权限授予自己；也可以把账号管理员角色分配给其他身份。
当平台完成初始化配置且你已将大多数账号级操作（如用户开通）实现自动化后，通常很少再需要账号管理员参与。

在 AWS 与 GCP 上：创建 Databricks 账号的人会成为首位账号管理员。随后，他/她可以添加其他用户，并将账号管理员角色分配给少数被选中的人。
在 Azure 上：流程不同。你不直接创建 Databricks 账号，而是先创建一个 Azure Databricks 工作区。当至少有一个工作区后，才能访问账号控制台。此时尚无账号管理员，Azure Databricks 会依赖 Entra ID 中的高权限角色来获得首次访问账号的能力——你需要具有 Entra ID 全局管理员（Global Administrator） 角色，方可首次进入账号控制台。一旦登录，你就成为首位 Databricks 账号管理员，此后即可将账号管理员角色分配给其他身份。

由于此时账号下已存在一个或多个工作区，若某些身份已在这些工作区完成接入，你会在账号控制台中看到他们。这可能让人困惑：你第一次进账号控制台，却看到已有身份出现。其原因在于：Databricks 的身份存在于账号层——即使你是在工作区里接入身份，其作用域依然是账号。

Metastore 管理员（Metastore admin）

这是一个可选角色，权限级别仅次于账号管理员。Metastore 管理员对该 metastore 拥有完整权限，也就是说，对该 metastore 下编目的所有数据与 AI 资产都拥有不受限访问。他们不能将 metastore admin 角色再分配给其他身份，但可以逐项将 metastore 上的所有权限授予任意身份。
如果你充分利用工作区管理员的权限并配合完善的自动化，则不一定需要设置 metastore 管理员。第 5 章将结合访问控制机制深入讨论“谁该担任 metastore 管理员”。

工作区管理员（Workspace admin）

工作区管理员在工作区作用域内拥有管理权限，此外还在账号层与 metastore 层拥有少量权限。这是你在日常最相关且常用的管理员角色。

注
除了账号 / metastore / 工作区管理员之外，Databricks 还预置了若干用于管理目的的特权角色，例如：Marketplace 管理员、计费管理员（billing admin） 、组管理员（group manager）与服务主体管理员（service principal manager） 。在相关章节我们将按需说明这些角色。

访问平台的接口（Interfaces to Access the Platform）

使用与管理 Databricks 平台的方法有很多，但从根本上说，有两大接口：UI 与 REST API。

Databricks UI

早在 2022 年，在加入 Databricks 之前，Karthik 想要体验并了解其提供的数据平台。他注册了在 AWS 上使用 Databricks 的免费试用。Databricks 给了他一个登录链接，指向账号控制台（account console） 。由于是他注册了 Databricks，他自动成为账号管理员，因此能访问账号控制台。随后他严格按照 Databricks 文档的步骤创建了一个工作区（workspace） 。当工作区启动并运行后，他登录了该工作区，发现工作区的 UI与账号控制台截然不同——工作区 UI 更接近他期望的数据平台样貌。工作区 UI是**账号用户（或简称用户）**日常访问与使用的界面。

如果你是账号管理员，你可访问账号控制台以在账号层执行管理操作；如果你是账号用户，则可能拥有一个或多个工作区的访问权限。之所以说“可能”，是因为你也许已经在 Databricks 用户列表里，但尚未被账号管理员或工作区管理员授予任一工作区的访问权限，因此无法登录与使用。此外，拥有工作区的访问权并不等于自动获得该工作区内任何**可控对象（securables）**的权限，仍需他人进行授权。

Databricks REST API

Databricks 提供遵循 REST 架构风格的 API 与平台交互，这带来两方面的价值：其一是自动化 DevOps 活动，其二是在其之上构建更多接口。以下工具均建立在 Databricks REST API 之上：

Databricks CLI：用于交互式的部署、测试与调试。
Databricks Terraform provider：通过自动化工作区供给、工作区对象与 Unity Catalog 可控对象的部署与管理，来部署和管理数据平台。
Databricks SDK（Python/Java/Go） ：用于交互式开发、测试与调试。
Databricks Asset Bundles（DABs） ：帮助在数据与 AI 项目中落地 DevOps / CI/CD 与软件工程最佳实践。

Databricks 在账号层与工作区层均提供 API。通常，UI 能做的大多数操作都可以通过 API 完成；而且很多时候 API 能做的更多。

在 Databricks 中，Unity Catalog metastore 并无单独的 UI 或 API。创建/删除 metastore 与少量配置通过账号控制台完成；在目录（catalog）内创建与管理可控对象则通过工作区进行。图 3-7 展示了账号与工作区的接口关系——与 metastore 的交互要么经由账号，要么经由工作区。

图 3-7. Databricks 账号与工作区的上下文与接口

身份供给（Identity Provisioning）

在大多数组织（极早期初创公司除外）中，身份的创建、存储与管理由称为身份提供方（IdP）的系统承担。常见 IdP 包括 Microsoft Entra ID（原 Azure AD）、Okta、OneLogin、Ping Identity。在一个组织中，IdP 是全部身份的权威源（source of truth）。

这种集中式身份管理有诸多优点：更容易处理认证、为多系统提供简化的登录机制、简化用户入/离职流程；还可强制多因素认证（MFA）等额外安全措施。因此，当你为组织技术栈引入新的工具/服务/平台时，通常会接入 IdP以承担用户认证等身份管理职能。

Databricks 同理：部署 Databricks 平台时，应接入你的 IdP。虽然你也可以在 Databricks 内独立创建/存储/管理身份，但最佳实践是：以 IdP 作为全部身份的权威源。换言之，在 IdP 中创建用户与用户组，并供给（provision）到 Databricks，使得 Databricks 内的身份是 IdP 中身份的镜像。

将 IdP 中的身份同步到 Databricks 账号（Syncing Identities from IdP to Databricks Account）

身份供给并非一次性工作。你需要保持 IdP 与 Databricks 中身份的持续同步，让 IdP 中的变更（如组成员变动、用户停用等）能反映到 Databricks。设置同步有几种方式：一种是自动身份管理（AIM） （见下节《基于 Microsoft Entra ID 的自动身份管理》）；另外几种基于 SCIM（简化跨系统身份管理的开放标准协议）。基于 SCIM 的供给选项包括：

SCIM 供给连接器（SCIM provisioning connector）
在 IdP 中配置的一个应用，通过 SCIM 协议连接到 Databricks 账号。它周期性运行，将已供给的身份同步到 Databricks。
SCIM REST API
Databricks 提供 SCIM REST API，可用于在 Databricks 内创建与管理身份。若要从 IdP 同步身份，你可调用 IdP 的 API 读取身份信息，再调用 Databricks 账号 SCIM API 在 Databricks 中创建/更新相应信息。可用 Python 等语言编写自定义脚本，或使用 Terraform 等 IaC 方案，把供给与同步完全自动化。

注释
身份供给的方向是从 IdP 到 Databricks 账号。Databricks 也支持从 IdP 到工作区的供给，但这已是旧方案（legacy） 。

为何选择其一而非其二？这需要评估后再决定。我们的观察是，拥有成熟身份管理与访问申请流程的大型组织往往倾向于使用 SCIM 供给连接器：他们对其已很熟悉，且这种标准方案通常已与内部工单系统集成，便于处理访问申请；并且已有明确的应用 Owner负责创建与运维。然而，SCIM 连接器也有限制，例如 Microsoft Entra ID 提供的 SCIM 连接器无法供给服务主体与嵌套组。

而偏技术导向的组织则常用自定义脚本，在可供给的对象与同步频率上更灵活。尽管需要自行开发与维护脚本，但搭建相对简单，且通常无需频繁升级逻辑或端点。

也有组织采用混合方式：用 SCIM 连接器供给用户与扁平组，再用脚本供给服务主体与嵌套组，以弥补连接器的限制。无论选择哪种方案，供给与同步机制都可以全自动化。SCIM 连接器使用由账号管理员生成的 SCIM URL 与令牌；脚本则应以具备账号管理员角色的服务主体执行。

注释
从 IdP 到 Databricks 的身份同步是单向的——IdP 始终是身份的权威源。

基于 Microsoft Entra ID 的自动身份管理（Automatic Identity Management with Microsoft Entra ID）

如果你的 IdP 是 Microsoft Entra ID，可选择更便捷的 AIM（Automatic Identity Management） ，而无需设置 SCIM 同步。使用 AIM，你可以直接使用 Entra ID 中的身份，而不是在 Databricks 中再创建一份拷贝。截至目前，AIM 仅在 Azure Databricks 上、且仅支持 Entra ID。

启用后，工作区管理员可在工作区中直接搜索并添加来自 Entra ID 的用户、服务主体与用户组，无需任何同步机制。Entra ID 将作为全部主体的权威源，因此对这些主体的任何变更都会反映到 Databricks。例如，在 Entra ID 中移除某用户，该用户在 Databricks 中会被停用，无法再登录。AIM 的另一优势是无 SCIM 连接器的限制——它也支持服务主体与嵌套组。

此外，AIM 使将业务用户引入 Databricks 生态更容易。例如，某用户在工作区创建了一个 AI/BI 仪表板并想分享给一个对 Databricks 毫无概念的业务同事，他/她可以基于对方的 Entra ID 身份分享只读视图。接收者会被自动添加到 Databricks 账号，但不会被添加到工作区，也仍能查看仪表板。这有两点好处：

你无需通过 SCIM 供给把业务用户添加进 Databricks 账号，分享更快更方便；
你没有把用户加入工作区，天然遵循最小权限原则，也减少了工作区内的用户数量。把工作区级对象（如仪表板）分享给非工作区用户有助于扩展：可面向成千上万业务用户分享，而不用担心触及工作区身份上限。

Databricks 工作区分配（Databricks Workspace Assignment）

从 IdP 把用户供给到 Databricks 账号，并不会让其在账号内获得任何资源的访问权。若用户需要访问某个工作区，必须被分配到该工作区。账号管理员可以把账号中的身份分配到任一工作区；工作区管理员可以把账号级身份分配到自己管理的工作区。图 3-8 展示了身份从 IdP 供给到 Databricks 账号，再被分配到各工作区的流程。该分配过程也可自动化，通常通过 REST API 或 Terraform 脚本完成。

图 3-8. 身份从 IdP 供给到 Databricks 账号，并按需分配到工作区

在 Nexa Boutique，IdP 为 Microsoft Entra ID，所有身份都在其中创建与管理。新人入职会在 Entra ID 中创建新身份；离职则清理该身份。组织只有一个 Entra ID 租户，作为所有系统（尤其是用户与用户组）的权威源。

当 Nexa 初建其基于 Databricks 的数据平台时，Unity Catalog 与账号级身份管理尚不存在，因此 Nexa 需要从 Entra ID 分别向每个工作区供给身份，这就是所谓的工作区级身份供给。它与账号级供给原理相同，只是供给目标从账号变为工作区，同样基于 SCIM。工作区级 SCIM 供给如今已是旧方案；有趣的是，这个功能当年处于 Public Preview，并不会 GA——在 Databricks 的历史上相对少见。

Nexa 的平台近年显著扩张，已拥有数百工作区与数万用户且仍在增长。如今，随着 UC 与集中式身份供给的到位，Databricks 内的身份管理变得简单许多。当然，他们经历了将工作区本地组及相应访问控制迁移到账号级的阵痛，但得到了 Databricks 一线工程团队的支持，并利用 Databricks Labs 的开源工具 UCX，自动化将工作区本地组升级为账号组。第 11 章将介绍迁移到 Unity Catalog 的相关主题。

Nexa 选择了从 Entra ID 到 Databricks 账号的混合供给方案：用 Entra ID SCIM 连接器供给用户与用户组，再用 Python 自定义脚本供给 Entra ID 托管的服务主体。也就是说，供给的大头由 SCIM 连接器承担。原因很简单：Nexa 的云团队对其非常熟悉并愿意负责；SCIM 连接器无额外成本、无需维护，且具备事件日志，便于调试与审计。之所以用脚本供给服务主体，是因为 SCIM 连接器不支持供给 Entra ID 托管的服务主体。SCIM 连接器的同步频率为每 40 分钟，脚本配置为每小时运行一次。

如第 1、2 章所述，Nexa 采用多云（美国为主用 AWS，欧洲为主用 Azure），因此自然拥有不止一个 Databricks 账号：AWS 上一个 Databricks 账号，Azure 上一个 Azure Databricks 账号（对应 Azure 租户）。Nexa 使用两个 SCIM 连接器为用户与组供给：一个面向 AWS 上的 Databricks，一个面向 Azure Databricks。

当 AIM 以 Public Preview 发布后，Nexa 开始在 Azure Databricks 账号采用它，避免维护 SCIM 连接器与额外的服务主体供给脚本的开销。AIM 一旦在 AWS 上可用，Nexa 计划扩展到 AWS 场景。

用户访问的供给与回收（User Access Provisioning and De-provisioning）

Nexa 使用 ServiceNow 作为 ITSM，希望通过 ServiceNow 管理 Databricks 账号与工作区的访问供给。ServiceNow 与 Microsoft Entra ID 集成良好：当用户想获得某 Databricks 工作区访问，例如在 ServiceNow 门户提交申请，审批人会收到通知；审批通过后，将该用户身份加入拥有该工作区访问权的 Entra ID 组，并通知用户。下一次身份供给同步时，该用户便作为该组成员被同步到 Databricks。图 3-9 展示了简化版的用户访问供给流程。

图 3-9. 简化的用户访问供给流程

当用户离职时，会在 Entra ID 中禁用或删除其身份；下一次 SCIM 同步后，该用户会在 Databricks 账号中被停用。在账号层被停用的身份，也会在所有工作区被停用。图 3-10 展示了用户回收（de-provisioning）流程。若要彻底清除，应将该身份在 Databricks 中删除；从账号删除的身份也会从所有工作区删除。

图 3-10. 用户回收（去供给）流程

如你所见，你可以借助 ITSM 与 IdP 管理用户供给/回收，几乎无需直接与 Databricks 交互（清理孤儿身份除外）。

单点登录（Single Sign-On）

不论技术水平或从业年限如何，我们大多数人都有一个“通病”：在多个应用或服务里复用同一密码。明知不安全，却仍会这么做——研究显示，这在大多数人群中普遍存在。

想象一个组织里有许多应用和服务：如果每位用户都要为每个应用/服务维护一套不同的凭据，会怎样？即便大家都真的做到了——他们每次登录要花多少时间输入？会有多少次“重置密码”请求？你大概已经感受到问题的严重性。

SSO（单点登录）正是为此而生：它是一种认证方法，允许用户用一套凭据登录多个应用和服务，从而在组织中改善用户体验（UX） 、同时提升安全与效率。多数常见的 IdP 都支持 SSO，你也可以为 Databricks 配置 SSO。

实现 SSO 的开放标准有多种。Databricks 支持其中最常用的两种：

OpenID Connect（OIDC）
由 OpenID Foundation 制定，2014 年发布。它在 OAuth 2.0 授权框架之上扩展，提供标准化的用户认证与身份校验方法。OAuth 2.0 仅用于授权，让应用在不暴露用户凭据的情况下，代表用户安全访问资源。
Security Assertion Markup Language（SAML）
由 OASIS 制定的认证与授权开放标准，首次发布于 2001 年。主要用于验证用户身份并确定已认证用户可访问的资源/服务。

本书不深入展开这些协议的细节，因为超出了范围。

各云厂商的 SSO 选项（CLOUD-SPECIFIC SSO OPTIONS）

Databricks on AWS

在账号控制台配置好 SSO 后，你可以启用 Unified Login（统一登录） 。启用后，你只需在账号层维护一套 SSO 配置，它将适用于所有启用 Unity Catalog 的工作区——无需为每个工作区单独再配一次（仍可单独配置，但不推荐）。

Azure Databricks

SSO 由 Microsoft Entra ID 提供支持，默认适用于账号控制台与各工作区。

Databricks on GCP

基于 Google Cloud Identity（或 GSuite） 的 SSO 默认适用于账号控制台与各工作区。你可以将 Google Cloud Identity（或 GSuite）与外部 IdP（如 Entra ID、Okta 等）建立联合以验证用户凭据。写作时，Databricks 正在简化该流程：允许在 GCP 上的 Databricks 直接配置任意 IdP 做 SSO，以减少运维开销。

Nexa Boutique 在 Azure Databricks 上默认使用 SSO；在 AWS 上，他们为账号启用了 Unified Login，让所有 AWS 上的工作区共用一套集中式 SSO 配置。Nexa 采用 Databricks 推荐的 OIDC 协议。统一登录带来的收益包括：

集中管理降低 TCO，新建的所有工作区开箱即安全。
更易为新用户开通 AI/BI 仪表板、Genie 空间、Databricks 应用等特性。
提高生产力：账号范围的一套 SSO 配置意味着更少的故障排查、用户更满意。

编程方式认证（Programmatic Authentication Methods）

使用 Databricks 的一种方式，是在浏览器里登录工作区执行操作。Databricks UI 功能丰富：你可以用 notebook 开发并运行代码，配置定时 jobs、调试失败的任务；可在 UI 中直接查看数据及元数据；也非常适合 ML/AI 模型训练、评估与部署；还能可视化数据集并创建仪表板。换言之，Databricks UI 能满足数据工程师、数据科学家、数据分析师、ML/AI 工程师等多种角色。

即便如此，你可能仍希望通过外部应用与服务访问 Databricks 及其编目的数据：例如用 VS Code 而不是 Notebook 编码；用 Power BI/Tableau 可视化；或用 Airflow 编排 ETL。这些交互都直接或间接使用 Databricks 的 API，因此需要正确设置认证。

前文我们主要关注用户的认证。下面简要介绍如何以编程方式访问 Databricks：

交互式（Interactive）

用于有人参与的编程访问（attended），可以使用 OAuth 用户到机器（U2M） 认证机制。若用户从 IDE 连接 Databricks 并执行操作，适合用 U2M OAuth（基于短时效的用户 OAuth token）。此外，应用与服务也可代表用户获取 Databricks 账号/工作区资源的 API 访问。

非交互式（Noninteractive）

用于无人值守场景，有几种方式：

OAuth token federation（令牌联合）
最安全、最推荐。它让你用 IdP 的令牌交换出短时效的 Databricks OAuth token 调用 API。详见本章后文。
OAuth 机器到机器（M2M）
应用/服务使用与服务主体（SP）关联的 OAuth 访问令牌访问账号与工作区资源（即短时效的 SP OAuth token）。适合自动化场景、或应用/服务需要独立连接 Databricks。比如用 Terraform 管理 Databricks 资源：可用服务主体及其 OAuth token 认证 Databricks Terraform provider 对账号/工作区的操作。若因故不能使用令牌联合，才使用此方案，并务必定期轮换 SP 的 client ID 与 secret。
个人访问令牌（PAT）
Databricks PAT 可用于代表用户或服务主体访问工作区资源的 API。由于 PAT 通常生命周期较长且不会自动刷新，安全性较低，应仅在目标应用/服务不支持 OAuth 等其他方式时作为最后选项。

警示：PAT 存在安全风险（PATS ARE A SECURITY RISK）

强烈不建议使用 PAT，主要因为它是长时效密钥（默认最大 2 年）。这会带来多重风险：

容易创建后被遗忘；

属于**持有者即用（bearer）**令牌，谁拿到谁能用；

可完全模拟用户：持有者可访问用户能访问的一切；

即使用户角色变更，旧 PAT 仍继续有效，可能导致权限提升（例如你用 PAT 跑 ETL，后来成为工作区管理员，则该 PAT 也随之拥有管理员权限）。

若确有不可避免的原因必须使用 PAT，请尽量限制风险：

新建 PAT 设较短过期（通常 < 90 天）；

撤销所有旧 PAT。Databricks 会自动撤销90 天未使用的 PAT；

账号管理员应在账号控制台通过token 报告监控并撤销未使用的 PAT。

详见相关视频（More details …）。

云相关认证：Azure Databricks

在我们看来，Azure 在认证与授权机制上更占优势，尤其在简洁性方面。除了强大且集成良好的 IAM，它还提供可简化资源间访问的认证方式，便于进行资源到资源访问管理。
例：你要构建一个使用 虚拟机（VM） 和 存储账号 的简单应用，若要从 VM 访问存储，最佳选择是使用 Managed Identity（MI，托管身份） 。MI 适用于 Azure 环境，凭据由 Azure 托管，无需你配置或轮换任何密钥，因而维护更少、更加安全。

并非所有 Azure 资源都支持 MI；在这种情况下可使用 Entra ID 服务主体（Azure SP） 。与 MI 不同，SP 的密钥需手动管理与轮换，因此安全性低于 MI，应仅在 MI 不可用时使用。

简而言之：从其他 Azure 资源访问 Azure Databricks，优先用 MI（若支持）；否则用 Azure SP。进行交互式开发/实验时，也可使用 Azure CLI 连接 Databricks 账号或工作区。
作为认证机制，你会为 MI、SP 与用户生成并使用 Microsoft Entra ID tokens。这些 token 短时效（通常 1 小时），非常适合自动化场景。

云相关认证：Databricks on GCP

在 GCP 上，对应于 Azure SP 的是服务账号（Service Account） 。你可以使用 GCP 凭据认证访问 Databricks 账号或工作区，其认证基于与服务账号关联的 OAuth token（服务账号作为 Databricks 用户）。另一种选择是 Google Cloud ID Authentication（使用 Google CLI 认证），同样使用服务账号对应的 OAuth token。

OAuth 令牌联合（OAuth Token Federation）

用长时效的 PAT 或 OAuth client secret 访问 Databricks API 既不安全，又增加运维负担。想象一下要在全组织范围管理成百上千个密钥；或允许团队到处创建/使用 PAT 与 OAuth 密钥所形成的安全债务（类似技术债，但指安全层面）。图 3-11 展示了应用使用服务主体的 PAT 或 OAuth secret访问 Databricks API 的方式：你给服务主体授予权限，应用拿着该 SP 的令牌/密钥即可“继承”这些权限。由于这类令牌/密钥通常生命周期长，一旦泄露，极易引发安全事故。

图 3-11. 外部应用使用服务主体的 PAT 或 OAuth 密钥访问 Databricks API

替代方案是使用 OAuth 令牌联合：用 IdP 的令牌去交换短时效的 Databricks OAuth token 来访问 API。因为 token 短时效且无需 Databricks 托管任何密钥，这种方式天然更安全。
例如，你希望用 GitHub Actions/Azure DevOps 等 DevOps 方案在外部自动化运行工作流，与其存储 PAT 或 OAuth secret，不如使用工作负载身份联合（workload identity federation） 。账号管理员可以为**服务主体（SP）配置联合策略（federation policy）**来启用它。

服务主体联合策略与 Databricks 中的某个 SP 关联，规定该 SP 可从哪个 IdP（issuer） 进行认证，以及允许以哪个工作负载身份（用 subject 与 audiences 描述）来作为该 SP 进行认证。
例如面向 GitHub Actions 的策略如下：

{
  "iss": "https://token.actions.githubusercontent.com",
  "aud": "https://github.com/my-github-org",
  "sub": "repo:my-github-org/my-repo:environment:prod"
}

图 3-12 展示了工作负载身份联合机制，其流程如下：

为某个 Databricks SP 设置联合策略；
客户端（外部应用/工具）向 IdP 请求联合令牌；
客户端携带该联合令牌，调用 Databricks token 端点向工作负载运行时请求 OAuth 访问令牌；
工作负载运行时校验请求并签发 OAuth 访问令牌；
客户端使用该 OAuth 令牌 调用 Databricks API。

你也可以设置账号范围的令牌联合策略（account federation policy），允许账号内所有用户与 SP使用来自 IdP 的令牌访问 Databricks API，从而将令牌签发策略的管理集中到 IdP。

图 3-12. 工作负载身份联合机制

身份最佳实践（Identity Best Practices）

Nexa Boutique 对其技术栈的管理极为自律。他们深知控制技术债的重要性，因此始终力求践行最佳实践。Nexa 与 Databricks 关系良好，并定期与 Databricks 一线工程团队同步，以掌握最新进展、最佳实践与产品愿景。

Nexa 与 Databricks 合作制定并遵循以下最佳实践。这些做法非常适合 Nexa，也适用于大多数组织：

在 Microsoft Entra ID 中启用 MFA 与条件式访问策略，以强化 Databricks 平台环境的安全性。
所有身份均在 Entra ID 中创建与维护，包括 Databricks 专用的用户组；随后将其供给到 Databricks 账号。任何组成员变更只在 Entra ID 中进行。一般不允许在 Databricks 内修改这些组的成员。来自 IdP 的组称为外部组，在 Databricks 账号控制台与工作区管理页面中默认不可变更。
避免创建嵌套组，以防权限模型复杂化。
把访问控制授予“组”而非个人（包括工作区访问与 Unity Catalog 可控对象的权限）。这样当个人状态变化（离职、转岗等）时，无需频繁改动访问控制，从而降低维护成本、保持权限整洁。
默认在所有工作区禁用 PAT（个人访问令牌） 。如确需使用，必须向安全团队申请特例并给出充分理由；所有特例均有文档记录并定期复审。
避免使用任何遗留特性。已下线全部工作区级 SCIM 供给，仅在账号级进行身份供给。
在 AWS 上启用 Unified Login（统一登录） ，仅需在账号层维护一次 SSO 配置。
不设置常驻账号管理员。改由预批准用户临时提升为账号管理员以执行任务（如启用功能、处理升级与紧急事项）。为此使用 Microsoft Entra PIM（特权身份管理） 。
监控系统表中的 Databricks 审计日志（与身份与访问相关的事件），以发现异常并触发告警。

总结（Summary）

在组织内，控制与管理谁能访问什么至关重要，这从你在 IdP 中定义的身份开始。Databricks 中的身份存在于账号层。你可以借助 IdP 实现 SSO 与身份管理，并通过 AIM 或 SCIM 将身份供给并定期同步到 Databricks。身份供给到 Databricks 账号后，可将其分配到各工作区。

Databricks 提供多种管理员角色，用于管理身份并控制对账号与工作区的访问。你主要通过 Databricks UI 或 API 访问账号与工作区。除 SSO 外，Databricks 还支持多种编程式认证：OAuth 令牌联合、基于用户与服务主体的 OAuth 令牌，以及 PAT（最后手段）——它们均与以程序方式访问平台相关。

本章聚焦 IAM 的身份管理部分。第 5 章将深入访问管理，特别是工作区与 Unity Catalog 可控对象的访问控制机制；并进一步讨论**细粒度访问控制（FGAC）与基于属性的访问控制（ABAC）**等更广泛的治理主题。