How to Manage your LLM Teams using MLflow's Role-Based Access Control

如何使用 MLflow 的基于角色的访问控制管理您的 LLM 团队 | MLflow

如何使用 MLflow 的基于角色的访问控制管理您的 LLM 团队

2026 年 6 月 15 日

·

9 分钟阅读

Khalil Kafrouni

Databricks 的 MLflow GTM 首席

您的 AI 团队运行顺畅：提示工程师正在调整系统提示，评估研究员正在借助评委使用评估流程运行测试场景，平台工程师同时在管理 AI 网关端点。所有工作都集中记录在一台 MLflow 服务器上。

突然，事情出了问题。您的团队成员之一删除了正在使用的系统提示，导致三个依赖该提示的工具突然失效。一位临时雇员首次加入团队时，意外访问了机密的测试数据。某 AI 网关端点被更新了，尽管此人本不应拥有修改权限。

如果这些场景听起来很熟悉，您肯定不是唯一遇到这些问题的人。而这些场景正是我们激动地发布 MLflow 基于角色的访问控制（RBAC）的原因。

传统权限模型难以满足 LLM 团队需求

大多数传统 ML 团队规模较小且封闭，可能只有 3-4 名数据科学家轮流共享模型实验。然而，处理 LLM 或代理工作流的团队往往截然不同。以现代 AI 工作流为例，可能涉及以下角色：

• 提示工程师在您的提示注册表中调整提示和模板。
• 评估研究员测试您的模型，并对跟踪记录运行评分器。
• AI 网关操作员管理您的端点、密钥和模型定义。
• 需要管理 MLflow 部署本身的平台工程师。
• 临时员工（临时工、外部承包商等），他们不属于您的组织，仅需有限范围的只读权限。

在 MLflow 的权限模型更新之前，每个用户的每个资源都需要单独显式调用权限，例如：create_experiment_permission()。如果只有三名用户需要访问单个实验，这样是可以接受的。但当团队需要处理大量提示、评分工具、网关和测试，且权限需求差异巨大时，自行管理权限会迅速变得混乱。团队规模越大，无意中使用不当权限的可能性就越微妙。

RBAC 提供的解决方案

角色可重用性：只需创建一次“提示编辑器”角色，然后将其分配给所有需要编辑提示的用户。如果招聘新成员或有人离职，只需将用户添加到或移除出“提示编辑器”角色即可。您无需逐一处理为团队创建的数十个不同提示角色。

自动覆盖未来资源：角色与资源模式（resource_pattern）相关联，这决定了拥有该角色的用户可以访问哪些资源。例如，您可以将（prompt, *, EDIT）角色分配给需要编辑提示的用户。这将赋予用户编辑所有当前和未来提示的权限！这个通配符将在该特定角色的工作区中解析（意味着您的提示编辑权限不会影响到其他团队的提示库）。您的访问权限会自动保持最新。

注意：在 UI 中，通配符 * 显示为 all。

四种直观的权限级别：

| 权限 | 可读 | |--------------|------| | | |

Can Use

Can Update

Can Delete

Can Manage Permissions

READ

âœ

❌

USE

EDIT

MANAGE

注意：USE 表示在不修改资源的情况下使用它（调用网关端点、引用模型定义或在工作区中创建新资源）。创建新资源属于 USE 的范畴，而不是 EDIT，这是一个附加权限，而非原地修改权限，因此没有单独的“创建”列。EDIT 不包含删除权限；只有 MANAGE 包含删除权限。

将 LLM 团队角色映射到 MLflow 权限

这是典型 AI 团队在 MLflow 中的角色映射方式：

团队成员

权限

提示工程师

对提示、实验有权限

评估研究员

对实验、评分器有权限

网关操作员

对 AI 网关资源有权限

外部助手

仅对实验 42 有权限

团队负责人

对整个工作区有权限

入门 - 创建角色并分配权限

1. 服务器设置

要在 MLflow 中使用基于角色的访问控制（RBAC），服务器必须启用认证功能运行：

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'
os
.
environ
[
"MLFLOW_TRACKING_PASSWORD"
]
=
"your_password"
# 管理员默认是 'password1234'
mlflow
.
set_tracking_uri
(
"http://localhost:5000"
)

3. 加载认证客户端

认证客户端用于创建和管理用户及其凭证。

auth_client
=
get_app_client
(
"basic-auth"
,
tracking_uri
=
"http://localhost: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
=
"*"
,
# 通配符：也涵盖后续创建的提示
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 团队同时使用（例如：一个团队用于搜索工具，一个团队用于客户支持工具）。通过启动 MLflow 时添加 --enable-workspaces 参数，可以为每个团队提供独立的空间，用于管理提示、实验、评分器和网关资源。

因此，工程师要么属于 "search-AI" 工作区，要么属于 "customer-support-AI" 工作区（不能同时属于两个，除非明确被授予两个工作区的访问权限）。

在实际操作中，这意味着你只需要管理一个 MLflow 部署，但它可以支持多个 AI 团队，每个团队都能独立管理自己的工作区且不会相互干扰。

用户层级

RBAC 定义了三种不同类型的用户：

| 层级 | 工作原理 | 权限 | |------------------|--------------------------------------------------------------------------|----------------------------------------------------------------------| | 平台管理员 | 用户记录中设置 is_admin = true | 全系统无限制访问权限。只有该层级可以删除用户或执行批量操作。 | | 工作区管理员 | 通过角色持有 (workspace, *, MANAGE) | 在其工作区拥有完全权限：创建角色、管理用户、分配权限。不能跨工作区或执行系统级操作。 | | 普通用户 | 任何其他已认证的身份 | 权限完全由角色派生的权限决定。无管理员界面访问权限。 |

从旧版权限迁移（3.13 之前版本）

如果你正在从 MLflow 3.13 之前的版本升级，需要注意一个关键点：旧版的资源级权限（如 create_experiment_permission()）已被移除。升级时，数据库迁移会将这些权限回填到新的 role_permissions 表中，保持一致性且不会中断。

关键 API 变更：

# 旧版（已移除）：
#   auth_client.create_experiment_permission(experiment_id, username, "EDIT")
# 新版：
auth_client
    .grant_user_permission(
        username,
        "experiment",
        experiment_id,
        "EDIT"
    )

权限解析机制

当用户尝试访问资源时，MLflow 按以下顺序解析其有效权限：

• 平台管理员：若 is_admin = true，立即授予访问权限。
• 角色派生权限：用户在当前工作区持有的所有角色都会贡献权限。匹配的权限通过最大值运算合并：MANAGE > EDIT > USE > READ。一个 (workspace, *, MANAGE) 授权意味着可以管理该工作区的所有内容。
• 默认权限下限：
• 若未启用 --enable-workspaces：默认权限下限为 READ，当没有角色授权匹配特定资源时，该下限会被应用。
• 若启用 --enable-workspaces：在多工作区模式下，仍需授予用户 (WORKSPACE, *, USE) 权限以确认工作区成员身份（详见 RBAC 权限解析文档）。此时用户将获得创建资源的权限，同时默认权限可设置为：
• READ（默认）：仅允许创建资源，不提供对现有资源的可见性。
• NO_PERMISSION：仅允许创建资源，但不提供对现有资源的可见性。

重要：在 RBAC 中，没有显式的权限拒绝机制。如果需要限制访问，应通过更精确的授权而非添加例外。

直接授权（不通过角色）

对于一对一的用户-资源场景，可以直接授权，而无需创建命名角色：

# 授予 Alice 对实验 42 的 EDIT 权限
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 文档。

有问题或反馈？通过创建问题提交反馈或加入 MLflow 社区讨论。

⭐ 在 GitHub 上给我们点赞——支持这个项目！