MLflow 工作区与访问控制
在 Alauda AI 上,MLflow 是多租户的:每个 工作区 都对应一个 Kubernetes namespace,对工作区中的 experiments、runs、datasets 和已注册模型的访问,均通过 Kubernetes RBAC 授权。本指南将展示如何将一个 namespace 暴露为工作区,并授予用户对其的访问权限。
关于底层模型,请参见 简介 → 多租户模型。
将 namespace 暴露为工作区
当一个 namespace 带有 MLflow 配置所选定的标签时(默认是 mlflow-enabled=true),它就会成为一个 MLflow 工作区。只有匹配的 namespace 才会显示为工作区。
应用该标签,或者为现有 namespace 添加标签:
跟踪服务器的默认工作区 namespace 必须在服务器首次启动之前就已存在并完成标记,否则服务器将无法启动(参见 安装 → 前提条件)。
授予用户访问权限
MLflow 会使用 mlflow.kubeflow.org API group,根据调用者在目标 namespace 中的 Kubernetes 权限对每个请求进行授权。请在工作区 namespace 中使用 Role 和 RoleBinding 授予访问权限:
绑定中的 group 或 user name 必须与 OAuth proxy 转发的令牌中的 identity claim 匹配(即平台的 OIDC groups/user)。
从客户端选择工作区
将 MLflow tracking URI 设置为集群内的 Service(或平台 route),然后选择工作区:
对于原始 HTTP 客户端,请传递工作区 header:
你只能使用账户有权访问的工作区。有关完整的身份验证细节——无需浏览器获取 identity token 并连接 SDK——请参见 在身份验证和 RBAC 下使用 MLflow Python SDK。
故障排查
- 工作区不可见。 验证其 namespace 是否与配置的
workspaceLabelSelector匹配(默认是mlflow-enabled=true)。 403 PERMISSION_DENIED。 该账户没有该工作区 namespace 的访问权限。请为该 namespace 中的用户或 group 添加RoleBinding。- 某个 run 显示了错误的 owner 或 workspace。 owner 是经过身份验证的 identity;workspace 是
set_workspace()/MLFLOW_WORKSPACE所选择的工作区(否则为服务器默认值)。请同时检查两者。