My organization is scaling up, and now we have five different teams using the same MLflow instance. We’re running into issues where people are accidentally deleting each other's experiments or making the UI cluttered with "test" runs. Does the open-source version support any form of Role-Based Access Control (RBAC) or team-based workspace isolation?
3 answers
The standard open-source MLflow server is quite permissive and does not have built-in RBAC natively in the core package. However, many teams solve this by putting a reverse proxy like Nginx or an Auth Proxy in front of the server to handle basic authentication. For actual experiment-level permissions, you might need to look at managed versions like Databricks or use a plugin. Another strategy is to give each team their own "Experiment ID" range and use a strict naming convention like [TeamName]_[ProjectName]. This doesn't stop deletions, but it helps significantly with organization and ensures that people aren't accidentally looking at irrelevant data.
Could we just deploy multiple instances of the tracking server on different ports for each team to keep them completely separate?
We implemented a 'Read-Only' UI for the general public and restricted the 'Delete' API via our proxy server to only admins. It works well.
Restricting the DELETE method at the proxy level is a brilliant and simple fix! That would prevent 99% of the accidental data loss we are worried about.
You certainly could, Larry, but that makes it very hard for a manager or a lead data scientist to see the "big picture" of what's happening across the company. A better way is to use a shared SQL database backend with a shared S3 bucket but different prefixes. This keeps the data isolated at the storage level while allowing a single MLflow UI instance to browse everything. You just have to trust your teammates not to hit the delete button on things they don't own!