📚 课程目录第3章身份与认证机制

3. 身份与认证机制

在 Databricks 中，“身份”与“认证”是两个必须分开理解的概念。身份回答“你是谁”，由账户级和工作区级的身份对象承载；认证回答“你如何证明自己是谁”，由登录方式、令牌、OAuth 流程等机制完成。访问控制（授权）则是在身份确认之后，决定“你能做什么”。本节聚焦身份对象与认证手段的配置与管理，这是后续权限模型能够正确落地的前提。

一、四类身份对象及其适用边界

Databricks 账户中主要存在四类身份对象，它们的生命周期和管理位置不同，混用会带来权限混乱和审计困难。

用户（User）：代表一个真实自然人，拥有唯一邮箱，是账户级对象。用户可被分配到多个工作区，其身份在账户层统一管理。人员离职时应禁用账户级用户，而不是仅从某个工作区移除。
服务主体（Service Principal）：代表非人类的应用程序、自动化任务或 CI/CD 流水线。它没有邮箱登录能力，只能通过 OAuth 或令牌认证。服务主体同样在账户级创建，再授予工作区访问权。
组（Group）：用户的集合，是权限分配的主要载体。最佳实践是“权限授予组，用户加入组”，而不是给个人直接授权。账户级组可跨工作区同步，工作区本地组仅在该工作区生效。
账户管理员与工作区管理员：这是角色而非独立对象，但决定了谁能创建上述身份、配置 SSO 和发放令牌。

一个常见的错误是：为每个数据工程师单独授予集群权限。正确做法是建立 data-engineers 组，把权限授予该组，人员变动时只调整组成员关系。这样权限模型稳定，审计时也只需检查组级授权。

二、单点登录（SSO）与多因素认证（MFA）

Databricks 支持通过 SAML 2.0 将账户接入企业身份提供商（IdP），例如 Microsoft Entra ID、Okta 或 Google Workspace。配置 SSO 的核心步骤是：在 IdP 侧创建企业应用，获取 SSO URL 与证书；在 Databricks 账户控制台的“身份验证”中上传证书、填入 SSO URL 并启用；随后通过“测试登录”验证断言是否正确返回邮箱与组信息。若启用了 SCIM 预配，IdP 中的用户和组变更会自动同步到 Databricks，避免手工维护。

MFA 通常在 IdP 侧强制实施，Databricks 本身也支持为账户启用多因素认证。需要特别注意的是：SSO 与 MFA 保护的是交互式登录，而服务主体、OAuth 令牌和 PAT 走的是另一条认证路径，不受 SSO 登录流程约束。因此，不能因为“已经上了 SSO”就认为所有访问入口都受 MFA 保护。

三、OAuth 与个人访问令牌（PAT）

对于自动化和程序化访问，Databricks 提供两类主要凭据：

OAuth：推荐用于服务主体和需要短期凭据的场景。机器对机器（M2M）流程使用 client_id 与 client_secret 换取访问令牌，令牌有效期通常为 1 小时，可自动刷新。它不依赖长期密钥，泄露风险窗口小。
个人访问令牌（PAT）：由用户或服务主体生成，作为 Bearer Token 直接调用 REST API、CLI 或 JDBC/ODBC。PAT 默认长期有效，必须手工设置过期时间并定期轮换。

下面是一个使用 OAuth M2M 获取令牌并调用 API 的示例（参数为教学示例，非真实凭据）：

# 1. 使用服务主体的 client_id / client_secret 换取 OAuth 令牌
curl -X POST https://<workspace-url>/oidc/v1/token \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "grant_type=client_credentials" \
  -d "client_id=<service-principal-client-id>" \
  -d "client_secret=<service-principal-secret>" \
  -d "scope=all-apis"

# 返回示例（节选）
# { "access_token": "eyJ...", "token_type": "Bearer", "expires_in": 3600 }

# 2. 使用令牌调用集群列表接口
curl -X GET https://<workspace-url>/api/2.0/clusters/list \
  -H "Authorization: Bearer <access_token>"

判断认证是否成功，最直接的依据是 HTTP 状态码：200 表示令牌有效且权限足够；401 表示令牌无效或已过期；403 表示身份已识别但缺少对应权限。这三者的区分对排障非常关键——401 要检查凭据，403 要检查授权。

PAT 一旦生成，明文只显示一次。若遗失只能重新生成。建议为每个自动化任务分配独立的服务主体和独立 PAT，避免多人共用同一令牌，否则审计日志无法定位到具体调用方。

四、身份与认证的整体关系

下图把身份对象、认证路径与访问结果放在同一视图中，帮助区分“交互式登录”和“程序化访问”两条链路。

五、配置与管理的落地要点

把上述机制落到日常运维，可以遵循以下判断顺序：

先建组，再授权：新项目启动时先创建对应组（如 analytics-readers、etl-writers），把权限授予组，人员通过组获得访问。
人类用 SSO，机器用 OAuth：人员登录统一走 IdP，自动化任务一律使用服务主体 + OAuth M2M，避免把个人 PAT 写进流水线。
PAT 必须设过期时间：在用户设置或服务主体详情页生成 PAT 时，明确指定有效期（例如 90 天），并记录在密钥管理系统中。
定期审计：通过账户控制台的“身份与访问”查看用户、服务主体、组的成员关系，清理离职人员和闲置服务主体。

一个实用的判断口诀：“人走 SSO，机走 OAuth，权限给组，令牌要过期。” 这四句话覆盖了本节绝大多数配置决策。