📚 系列：亚马逊云科技上的 databricks（第二部分）
- 在亚马逊云科技上构建 databricks 人工智能平台
- 基于职能角色组的基于角色的访问控制 ← 你在这里
- 计算治理：池、策略、集群
- 引导超时之谜
- 通过亚马逊云科技私有链接修复它
- 我们如何组织地形代码结构
第一部分构建了环境。现在我们来分发密钥——三个账户级别的组、两个工作区，以及一个大部分不是由你发明的权限模型。
大多数关于 databricks 基于角色的访问控制的帖子都陷入了这样一个陷阱：它们将访问控制视为需要从头设计的东西。事实并非如此。databricks 已经在工作区级别提供了用户和管理员角色、权益、对象访问控制列表以及统一目录授权——这些都是内置的。唯一由你实际创建的部分是组。正确理解这种心理划分，基于角色的访问控制就不再像迷宫那样令人困惑。
如果你正在建立一个全新的 databricks 账户，并想知道从哪里开始划定第一条界线，那么在接触任何目录之前，先搞清楚这一层是关键。
用一句话概括模型
一切皆通过组进行流转：
用户 ──▶ 职能角色组 ──▶ 工作区（用户 / 管理员）+（稍后）数据授权
用户不会直接获得任何权限。他们被加入一个职能角色组，由该组承载权限。这种间接性正是关键所在——这意味着“这个人是谁”和“这个角色能做什么”是两个可以独立解决的问题。
我们从最小但仍能映射到实际工作的集合开始：
| 组 | 意图 | 工作区级别 |
|---|---|---|
ai_admin（人工智能管理员） |
平台管理员——运营平台 | 管理员 |
ai_engineer（人工智能工程师） |
机器学习/数据工程师——构建事物 | 用户 |
ai_analyst（人工智能分析师） |
分析师——读取和查询 | 用户 |
只有三个组，而不是三十个。你可以稍后添加 ai_scientist（人工智能科学家）、ai_guest（人工智能访客）等——每个只需一行 YAML 代码加上一个分配即可。抵制为每个假设的角色预先构建角色的冲动；人员流动会迅速破坏这种计划。
这些是账户级别的组，而不是工作区局部的组。这很重要：一个组定义可以分配给多个工作区，这正是当你拥有多个工作区时所希望的。
组是你唯一需要创建的东西
这是值得内化的部分。排列权限层级并标记谁拥有每一层：
| 层级 | 值 | 定义者 |
|---|---|---|
| 工作区分配 |
用户 / 管理员
|
databricks 内置 |
| 权益 |
工作区访问、databricks_sql_access（databricks SQL 访问）、allow_cluster_create（允许创建集群）等 |
databricks 内置 |
