[FR] MFlow Authorization - Production Solutions

[luke-gerschwitz]

Willingness to contribute

No. I cannot contribute this feature at this time.

Proposal Summary

Hi team,

I'm just wondering what kind of solutions (if any) exist for running MLlow in production with proper authorisation support? At the moment MLflow only supports basic authentication and permissions through basic_auth.db which cannot be scaled to an enterprise solution. How would on go about deploying MLflow to production and implementing fine-grained authorisation?

For example, ensuring that a data scientist on one team cannot view the experiments/runs/artifacts of another team (Without obviously hosting two separate MLflow instances).

Motivation

What is the use case for this feature?

Why is this use case valuable to support for MLflow users in general?

Why is this use case valuable to support for your project(s) or organization?

Why is it currently difficult to achieve this use case?

Details

No response

What component(s) does this bug affect?

• [ ] area/artifacts: Artifact stores and artifact logging
• [ ] area/build: Build and test infrastructure for MLflow
• [ ] area/deployments: MLflow Deployments client APIs, server, and third-party Deployments integrations
• [ ] area/docs: MLflow documentation pages
• [ ] area/examples: Example code
• [ ] area/model-registry: Model Registry service, APIs, and the fluent client calls for Model Registry
• [ ] area/models: MLmodel format, model serialization/deserialization, flavors
• [ ] area/recipes: Recipes, Recipe APIs, Recipe configs, Recipe Templates
• [ ] area/projects: MLproject format, project running backends
• [ ] area/scoring: MLflow Model server, model deployment tools, Spark UDFs
• [ ] area/server-infra: MLflow Tracking server backend
• [ ] area/tracking: Tracking Service, tracking client APIs, autologging

What interface(s) does this bug affect?

• [ ] area/uiux: Front-end, user experience, plotting, JavaScript, JavaScript dev server
• [ ] area/docker: Docker use across MLflow's components, such as MLflow Projects and MLflow Models
• [ ] area/sqlalchemy: Use of SQLAlchemy in the Tracking Service or Model Registry
• [ ] area/windows: Windows support

What language(s) does this bug affect?

• [ ] language/r: R APIs and clients
• [ ] language/java: Java APIs and clients
• [ ] language/new: Proposals for new client languages

What integration(s) does this bug affect?

• [ ] integrations/azure: Azure and Azure ML integrations
• [ ] integrations/sagemaker: SageMaker integrations
• [ ] integrations/databricks: Databricks integrations

[serena-ruan]

@gabrielfu Do you have any insights on this?

[serena-ruan]

Update: We're planning this for upcoming quarter and will get back to this :D

[luke-gerschwitz]

Update: We're planning this for upcoming quarter and will get back to this :D

Thanks for the update @serena-ruan it's great to hear that this is in the roadmap.

Third-party IDP authentication support and fine-grained authorisation are the primary obstacles preventing MLflow from being considered enterprise "ready". Looking forward to future updates!

[github-actions[bot]]

@mlflow/mlflow-team Please assign a maintainer and start triaging this issue.

[gabrielfu]

At the moment MLflow only supports basic authentication and permissions through basic_auth.db which cannot be scaled to an enterprise solution

It is possible to connect to a centralized database via the database_uri field in the auth config. I am going to update the docs for this.