Access Control to Models without relying on GitLab Hierarchy

Release notes

Problem to solve

Access to models, via the UI, API, or integration, should be appropriately gated.

Today, users can gate access by defining group, sub-group, and projects and adding members to the appropriate level within the hierarchy. However, models within a single model registry or even across several model registries within a group don't necessarily conform to GitLab Hierarchies. Given that there may be sensitive data involved, it is important to provide organizations additional levers to control access.

One potential workaround is to create multiple projects/model registries with the appropriate group/project membership defined, but this doesn't support the idea of a centralized data science or ML engineering team that is responsible for looking across all of the models in a central location.

Verified ways customers might want to restrict access in this setup.

  • By Model Family (model family are simply a grouping of related models defined by the user)

Unverified potential ways customers want to restrict access

  • By Model (Though this case becomes unlikely if there are lots of models)

Intended users

Central ML Admin

User experience goal

For data scientist/ML engineers, they shouldn't have to think about whether or not they have access. They simply do or don't and should not experience ugly no access screens.

Proposal

Define a convention for users to easily define model family. Create access control based on model family.

Permissions and Security

Who can define a model family for a model?
  • Developer+
Where are the model families defined?

TBD

  • Within any GitLab Hierarchy, similar to Labels (it might end up being just be a scoped label)
  • At a specific level within the hierarchy, e.g. top-level group or organization
Who can define access permission?

TBD - depends on the decision above

Available Tier

GitLab Ultimate in GitLab.org / ModelOps / MLOps / Model Registry

Feature Usage Metrics

  • Model Family usage rate / Model Registry usage rate - tells us whether this feature is useful
  • Ultimately, we want to drive more adoption of model registry, this feature is about enabling enterprises to do so.

What is the competitive advantage or differentiation for this feature?

  • Flexible security

Links / references

Research Spike

See this comment

Develop a plan on how we will solve this problem. If we can prioritize some architecture of how we might go about solving this problem, that's something I would Prioritize sooner rather than later because it informs us the steps we need to take.

Edited by Sean Carroll