如何利用 MLflow 的基于角色的访问控制（RBAC）管理您的大模型团队
您的 AI 团队运行顺利：提示词工程师在调整系统提示词，评估研究人员正在借助判断器通过评估流程运行测试场景，而平台工程师则在同时管理 AI 网关（AI Gateway）端点。所有的工作都集中记录在一个 MLflow 服务器上。
然后突然，一切都乱套了。一名团队成员删除了实时系统提示词，导致三个依赖该提示词的工具直接崩溃。一名短期雇佣人员在首次与团队合作时，意外访问了机密测试数据。其中一个 AI 网关端点被更改了，尽管该人员本不应拥有修改权限。
如果这些情况听起来很熟悉，请放心，您绝对不是一个人在面对这些问题。这正是我们发布 MLflow 基于角色的访问控制（RBAC）的原因。
传统的权限管理已无法满足 LLM 团队的需求
大多数传统的机器学习团队规模较小且相对封闭，通常只有 3 到 4 名数据科学家，他们轮流共享模型实验。然而，从事 LLM（大语言模型）或代理工作流（agent workflows）的团队情况往往大不相同。以现代 AI 工作流为例，它可能涉及：
- 提示词工程师在提示词注册中心（Prompt Registry）内调整提示词和模板。
- 评估研究人员测试模型并针对追踪记录（traces）运行评分器。
- AI 网关操作员跟踪端点、密钥和模型定义。
- 需要管理 MLflow 部署本身的平台工程师。
- 临时工（不属于贵组织，仅需有限范围内读取权限的临时员工或外部承包商）。
在 MLflow 权限模型更新之前，每一个权限授予都需要进行单独的显式调用，例如：为每个用户和资源调用 create_experiment_permission()。如果您只有三个用户且只需访问单个实验，这不成问题。但当团队需要处理多个提示词、评分工具、网关和测试，且权限需求各异时，自行管理就会迅速变得一团糟。团队规模越大，权限被非预期使用的隐患就越微妙。
RBAC 提供的优势
角色的可重用性： 只需创建一次“提示词编辑器”角色。然后将其分配给任何需要编辑提示词的人员。如果您招聘了新员工，或者有人离开了团队，您只需将该用户添加或移出“提示词编辑器”角色即可。无需在您为团队创建的几十个不同的提示词权限中逐一修改。
未来的资源也能自动覆盖： 角色与 resource_pattern（资源模式）相关联，后者决定了拥有该角色的人员可以访问哪些资源。例如，您可以将 (prompt, *, EDIT) 角色分配给任何需要编辑提示词的人。这将授予用户对所有当前和未来提示词的编辑能力！此通配符将在该特定角色的工作区内解析（意味着您的提示词编辑权限不会外溢到其他团队的提示词库）。您的访问权限会自动保持最新。
注意： 在 UI 中，通配符
*显示为all。
四个直观的权限级别
| 权限 | 可读取（Can Read） | 可使用（Can Use） | 可更新（Can Update） | 可删除（Can Delete） | 可管理权限（Can Manage Permissions） |
|---|---|---|---|---|---|
READ | ✅ | ❌ | ❌ | ❌ | ❌ |
USE | ✅ | ✅ | ❌ | ❌ | ❌ |
EDIT | ✅ | ✅ | ✅ | ❌ | ❌ |
MANAGE | ✅ | ✅ | ✅ | ✅ | ✅ |
注意：
USE涵盖了在不修改资源的前提下使用资源（调用网关端点、引用模型定义，或在工作区内创建新资源）。创建新资源属于USE而非EDIT，这是一种附加权限，而非原地修改权限，因此没有单独的“创建”列。EDIT**不包括** 删除；只有MANAGE包含删除权限。
将 LLM 团队角色映射到 MLflow 权限
以下是典型 AI 团队映射到 MLflow 角色的方式：
| 团队成员 | 权限 |
|---|---|
| 提示词工程师 | 对提示词有 EDIT 权限，对实验有 READ 权限 |
| 评估研究人员 | 对实验有 READ 权限，对评分器有 USE 权限 |
| 网关操作员 | 对 AI 网关资源有 MANAGE 权限 |
| 外部助手 | 仅对实验 42 有 READ 权限 |
| 团队主管 | 对整个工作区有 MANAGE 权限 |
入门指南 - 创建角色并分配角色
1. 服务器设置
要开始在 MLflow 中使用 RBAC，服务器必须在启用身份验证（auth）的情况下运行。
mlflow server --app-name basic-auth
推荐： 如果您需要为多个团队创建多个独立的隔离工作区，请添加 --enable-workspaces 标志。
mlflow server --app-name basic-auth --enable-workspaces
2. 配置管理身份验证
最佳实践是将凭据存储在环境变量或 ~/.mlflow/credentials 下的 .mlflow 文件中。然而，为了简单起见，在此示例中我们将身份验证信息硬编码在 Python 脚本中。
import os
os.environ["MLFLOW_TRACKING_USERNAME"] = "your_username" # admin default is 'admin'
os.environ["MLFLOW_TRACKING_PASSWORD"] = "your_password" # admin default is 'password1234'
mlflow.set_tracking_uri("https://:5000")
3. 加载身份验证客户端
身份验证客户端允许创建和管理用户及其凭据。
auth_client = get_app_client("basic-auth", tracking_uri="https://:5000")
4. 创建角色
prompt_engineer_role = auth_client.create_role(
workspace="your-workspace-name",
name="prompt-engineer",
)
auth_client.add_role_permission(
role_id=prompt_engineer_role.id,
resource_type="prompt",
resource_pattern="*", # wildcard: covers also the prompts created later
permission="EDIT",
)
auth_client.add_role_permission(
role_id=prompt_engineer_role.id,
resource_type="experiment",
resource_pattern="*",
permission="READ",
)
experiment_reader_role = auth_client.create_role(
workspace="your-workspace-name",
name="experiment-reader",
)
auth_client.add_role_permission(
role_id=experiment_reader_role.id,
resource_type="experiment",
resource_pattern="*",
permission="READ",
)
5. 为用户分配角色
for user in ("alice", "bob", "carol"):
auth_client.assign_role(username=user, role_id=prompt_engineer_role.id)
for user in ("john", "lisa"):
auth_client.assign_role(username=user, role_id=experiment_reader_role.id)
换句话说，下个月当有新的提示词工程师加入团队时，您只需审核一个角色定义（而不是 40 多个资源权限调用），管理起来既轻松又清晰。
在单个 MLflow 服务器上隔离不同团队
在实践中，MLflow 服务器通常会被多个 AI 团队同时使用（例如，一个搜索工具团队，一个客户支持工具团队）。使用 --enable-workspaces 启动 MLflow 将为每个团队提供独立的提示词、实验、评分器和网关资源空间。
因此，工程师要么属于“搜索-AI”工作区，要么属于“客户支持-AI”工作区（除非明确授予了访问两个工作区的权限）。
这意味着您只需管理一个 MLflow 部署，但它支持多个 AI 团队，每个团队都能管理自己的工作区且互不干扰。
用户层级
RBAC 建立了三种不同类型的用户：
| 层级 | 它是如何工作的 | 功能 |
|---|---|---|
| 平台管理员 | 用户记录中 is_admin = true | 无限制的系统级访问权限。是唯一可以删除用户或执行批量操作的层级。 |
| 工作区管理员 | 通过角色持有 (workspace, *, MANAGE) 权限 | 在各自工作区内拥有完全权限：创建角色、管理用户、分配权限。无法跨越到其他工作区或执行系统级操作。 |
| 常规用户 | 任何其他已验证身份 | 访问权限完全由基于角色的权限决定。无法访问管理员 UI。 |
从旧版权限迁移（3.13 之前版本）
如果您是从 3.13 之前的 MLflow 版本升级，请注意已删除了旧版按资源定义的权限（如 create_experiment_permission()）。升级时，数据库迁移程序会将权限回填到新的 role_permissions 表中，确保一致性且不会中断服务。
关键 API 变更
# Old (removed):
# auth_client.create_experiment_permission(experiment_id, username, "EDIT")
# New:
auth_client.grant_user_permission(username, "experiment", experiment_id, "EDIT")
权限解析的工作原理
当用户尝试访问资源时，MLflow 会按以下顺序解析其有效权限：
- 平台管理员： 如果
is_admin = true，则立即授予访问权限。 - 角色派生的授予： 用户在当前工作区持有的所有角色都会起作用。匹配的授权通过 max 操作进行组合：
MANAGE > EDIT > USE > READ。(workspace, *, MANAGE)授权授予对该工作区中所有内容的管理权。 - 默认权限基准
- 未启用
--enable-workspaces时： 默认权限基准是READ，当没有任何角色授予与特定资源匹配时，该基准将生效。 - 启用
--enable-workspaces时： 在多工作区模式下，我们仍需要授予用户 (WORKSPACE, *, USE) 权限以授予工作区成员身份。据此，用户除了获得default_permission（可设置为以下二者之一）外，还将获得创建资源的能力：READ（默认）NO_PERMISSION：在这种情况下，获得工作区访问权限仅允许创建资源，但不授予对现有资源的可见性。
重要提示： 在 RBAC 中，没有显式“拒绝”权限的方法。如果您想限制访问，需要更精细地授予权限，而不是添加排除项。
直接权限（无需角色）
对于“一个用户对应一个资源”的场景，您可以直接授予权限，而无需创建命名角色。
# Give Alice EDIT access to experiment 42
auth_client.grant_user_permission("alice", "experiment", "42", "EDIT")
这些调用受限于按资源的 MANAGE 权限——意味着拥有 (experiment, 42, MANAGE) 的实验所有者可以在即使没有工作区级管理权限的情况下授予他人访问权限。在后台，这些权限被放入预留的按用户角色中，但这属于您无需关心的实现细节。
参考：AuthServiceClient 方法
| 方法 | 目的 |
|---|---|
create_role(workspace, name, description?) | 创建新角色 |
delete_role(role_id) | 删除角色 |
update_role(role_id, name?, description?) | 更新角色元数据 |
add_role_permission(role_id, resource_type, resource_pattern, permission) | 向角色添加权限 |
update_role_permission(role_permission_id, permission) | 更改现有授权的级别 |
remove_role_permission(role_permission_id) | 从角色移除授权 |
assign_role(username, role_id) | 为用户分配角色 |
unassign_role(username, role_id) | 从角色中移除用户 |
grant_user_permission(username, resource_type, resource_id, permission) | 授予对单个资源的直接访问权限 |
revoke_user_permission(username, resource_type, resource_id) | 撤销直接访问权限 |
get_user_permission(username, resource_type, resource_id) | 检查用户对某资源的有效权限 |
list_roles(workspace) | 列出工作区中的角色 |
list_all_roles() | 列出所有工作区中的所有角色 |
list_role_permissions(role_id) | 列出角色内部的授权 |
list_role_users(role_id) | 列出分配给角色的用户 |
list_user_roles(username) | 列出分配给用户的角色 |
create_user(username, password) | 创建新用户 |
delete_user(username) | 删除用户（仅限平台管理员） |
update_user_admin(username, is_admin) | 提升或降级平台管理员 |
全局视角
利用大语言模型快速推进业务需要能够随团队扩展的系统，以管理日益增加的工作量和用户。基于角色的控制将焦点从权限的紧急修补和遗忘转向了集成式的安全组件。
有关完整详细信息，请参阅 MLflow RBAC 官方文档。
有问题或反馈？请通过 提交 Issue 或加入 MLflow 社区讨论 来告诉我们。
⭐ 在 GitHub 上为我们点星 — 支持该项目！