SuperAPI AI 工具集
合作ENAI 行业资讯收藏
Skill 广场databricks-identity-governance

databricks-identity-governance

数据与分析

查看项目

更新于 10-16 17:13

技能介绍

用途

该技能用于管理 Databricks 的身份与治理。当用户需要创建群组、用户、服务主体，搭建 RBAC，管理权限，或进行工作区层面的身份配置时适用。

主要能力

  • 通过 Account SCIM API 创建账户级群组，这类群组在所有已启用 Unity Catalog 的工作区中自动可见。
  • 创建用户（需要有效的邮箱作为 userName 以及 displayName）。
  • 创建服务主体，包括按环境划分的 CI/CD 服务主体（{prefix}-cicd-dev、{prefix}-cicd-stg、{prefix}-cicd-prod）以及平台管理员服务主体（{prefix}-platform-admin-sp）。
  • 工作区分配：为群组或用户分配 USER 或 ADMIN 权限。
  • Unity Catalog 授权：在 catalog 和 schema 层面为群组授权。

硬性规则（始终强制执行）

  • 仅使用账户级 SCIM 群组。工作区本地群组对 Unity Catalog 不可见，所有授权与分配必须使用账户级群组。
  • 仅向群组授权。绝不要将 catalog/schema/table 权限授予单个用户，始终授予群组。
  • 所有自动化任务使用服务主体。CI/CD 管道、计划任务和编排必须使用服务主体，而非用户身份；用户令牌会过期，用户会离开组织，基于用户的任务会静默失败。
  • 最小权限管理模型。只有平台团队获得工作区 ADMIN，其他所有人获得 USER。数据访问通过 UC 授权控制，而非工作区角色。
  • 创建群组前先检查：账户级群组在部署和工作区删除后仍然存在，创建新群组前始终列出已有群组，避免 SCIM 冲突错误。
  • 当服务主体创建 UC 对象时，人类管理员不会继承访问权限。使用服务主体的每次部署都必须包含显式授权块，向人类管理员群组授予 catalog 的 ALL_PRIVILEGES、external locations 的 MANAGE 和 storage credentials 的 MANAGE，或将所有权转移给该群组。否则客户的人类管理员登录工作区后看不到自己的 catalog。

推荐群组结构（多环境部署默认建议）

  • platform-admins：工作区 ADMIN + catalogs 的 ALL_PRIVILEGES，拥有 metastore，管理基础设施。
  • data-engineers：工作区 USER + USE_CATALOG、USE_SCHEMA、CREATE_TABLE、CREATE_FUNCTION、SELECT、MODIFY，在所有 schema 上。
  • data-analysts：工作区 USER + USE_CATALOG、USE_SCHEMA、SELECT，仅限 silver 和 gold schema，无 dev 访问。
  • data-scientists：工作区 USER + dev 中完整 CRUD，staging 中只读用于验证，无 prod 访问。
  • ml-ops：工作区 USER + dev 中读写（实验跟踪），staging/prod 中只读。

使用方式

  • 创建账户级群组：通过 Account SCIM API。创建前先列出已有群组。账户控制台 URL 按云划分：Azure 为 accounts.azuredatabricks.net，AWS 为 accounts.cloud.databricks.com，GCP 为 accounts.gcp.databricks.com。
  • 创建用户：在账户级通过 SCIM 创建。
  • 添加用户到群组：一个用户可属于多个群组，群组成员关系决定所有访问权限。
  • 服务主体：按环境创建，加入相应群组；平台管理员服务主体加入 platform-admins 组。
  • 工作区分配：列出已有分配，为主体的分配 USER 或 ADMIN，取消分配以撤销访问。注意：在启用身份联合的工作区上，databricks_mws_permission_assignment 不可用，API 返回 "APIs not available"；账户级群组通过身份联合自动可见，无需显式分配。
  • UC 授权：分层授权模式。工程师获得完整 CRUD，分析师获得 silver/gold 只读，平台管理员获得 catalogs 的 ALL_PRIVILEGES。仅使用现代权限名，旧版名称（如 USAGE 而非 USE_CATALOG）会导致令人困惑的错误。

审批门控

在创建、修改或删除任何远程身份资源（账户/工作区群组、用户、服务主体、角色分配、授权、权限，任何 terraform apply 或 databricks ... create|delete|update）之前，呈现一个计划并获得明确批准：目标（账户/工作区、--profile 或 host、云）、变更集（所有创建/修改/删除的主体、分配、授权，批量呈现整个任务）。等待明确批准后，仅执行已批准的范围；若范围变化，重新呈现并重新批准。重试/恢复使用同一门控。清理仅限于本次会话中此工作流创建的主体/授权，并向用户报告；未经询问绝不删除或撤销已存在的主体或授权。

限制与错误处理

  • SCIM 冲突：用户或群组已存在于账户级。先列出，然后更新已有对象。
  • "Group with name X already exists"：账户级群组跨部署和工作区删除持久存在。先列出，已存在则使用 data.databricks_group 数据源而非 databricks_group 资源，或通过 SCIM API 删除陈旧群组。
  • "permissions are [...] but have to be [...]"：使用了旧版权限名，切换到现代名称。
  • "Principal does not exist"：账户级 SCIM 群组对 UC 平面（databricks_grants）立即可见，但工作区 ACL 平面（databricks_permissions）需要 5–10 分钟才能看到新群组。修复方式：仅使用 databricks_grants，或添加 time_sleep，或分两次 terraform apply。
  • 关于 databricks_grants：每个 securable 只能有一个 databricks_grants 资源。两个针对同一 securable 的资源会在 apply 时竞争并失败。正确做法是一个资源包含多个 grant {} 块。不同 securable 的两个资源可以共存。
  • 占位符账户 ID：账户 ID 是 UUID 格式（8-4-4-4-12 十六进制）。不符合该格式的都是占位符，应让客户自行获取或验证，不要套用之前部署中的账户 ID。

交叉引用

关于工作区创建，参见 platform-provisioning。关于 Unity Catalog metastore 和 catalog 设置，参见 unity-catalog-setup。

暂未提供

资料未说明该技能的收费、价格、具体安装命令或平台运行要求。