track enablement by default in KF/manifests

[tarilabs]

see WG raised issue:

• https://github.com/kubeflow/manifests/issues/3047

[mahdikhashan]

I would like to help with it, the requirements are:

1. modify the model-registry in the main manifest repo to enable UI by default

are there anything else which should be handled @tarilabs @lucferbux ?

[rareddy]

@mahdikhashan thank you for your interest in this. There are two separate issues I am proposing overall with this work

1. Update the current manifest, where we can define a separate profile for MR called kf-model-registry and enable UI for MR in this profile. This is not much different from what we have instructions other than we leave the name of the profile and creation of the profile to the end user; what I am suggesting is to tie it to a specific profile and make it in one script which would be the default. (above ask)

The further ask here is, how user granted access to this model-registry instance in this profile as we would need to discourage using this profile for end-user application workloads. for example; end user create my-example-com profile can access kf-model-registry? it probably is nothing more than creating the permission in kf-model-registry for the my-example-com profile user.

2. As next step; MR should be moved to be installed in a kf-model-registry namespace by default(not profile); however the user in my-example-com profile is granted permission to access a particular instance in kf-model-registry. I believe the MR permission model allows for it; we need to investigate and see if that works; if not why and what solutions are available there to fix the issue?

work with @pboyd as he also mentioned interest in working towards it. He certainly can help guide you

[mahdikhashan]

Thank you very much for trusting in me for this issue @rareddy, I'll follow you guidelines and check/share every steps and approach with @pboyd.

[mahdikhashan]

/assign

[lucferbux]

Thanks @mahdikhashan to take a look into this, let me expand the current conversation with findings in previous researches.

Update the current manifest, where we can define a separate profile for MR called kf-model-registry and enable UI for MR in this profile. This is not much different from what we have instructions other than we leave the name of the profile and creation of the profile to the end user; what I am suggesting is to tie it to a specific profile and make it in one script which would be the default. (above ask)

Profiles are abstractions of namespaces + permissions. You can check the profiles resources in the link attached. The main issue on creating Profiles and deployment time is that you need to have a subject. You cannot do something like system:authenticated (see this for more info) so creating a default Profile might be challenging, you could bring this into the community in case there's a solution for this issue but bear in mind int might be a blocker. Also, Model Registry UI should be installed in the default namespace (in this case kubeflow) alongside all the rest of the components, that way we follow the same structure as any other component. To enable MR UI, you should edit the default KCD configmap with the Model Registry section (is already detailed in our installation steps).

it probably is nothing more than creating the permission in kf-model-registry for the my-example-com profile user.

https://www.kubeflow.org/docs/components/central-dash/profiles/#manage-contributors-manually

As next step; MR should be moved to be installed in a kf-model-registry namespace by default(not profile); however the user in my-example-com profile is granted permission to access a particular instance in kf-model-registry.

As I said before, we can follow this strategy, the main issue is that we'll need to cover in our docs that each an every user that wanna have access to MR should create the right permissions to be able to access it. Doing that, they would be able to access any particular instance in kf-model-registry as the default is that a user might be either viewer or editor.

The other issue, which is still on our side is that we don't support kubeflow roles still, we need to add that in our roadmpa to have a similar experience as other components.

[mahdikhashan]

/unassign

[tarilabs]

@lucferbux I'm not an SME on that area, but I wonder whether we could propose (to KF Platform) something like the following:

• in the example KF installation, we add one new Profile, to be created specifically for the "common" Model Registry (instead of using kubeflow which I understand is used for control-plane)
• this one Profile, be annotated so to identify it
• (let's assume this Profile be called shared-model-registry for this example)
• one controller (in kubeflow ns) that observes:
  • the RoleBinding to ClusterRole/kubeflow-{ROLE} to a new Profile/NS, and reconcile an analogous a RoleBinding for ClusterRole/kubeflow-view in shared-model-registry
  • the AuthorizationPolicy to a new Profile/NS, and reconcile an analogous AuthorizationPolicy for view for shared-model-registry
  • the idea being for any new user/sa, we give the necessary read access, so to be able to invoke the endpoints

very likely there are more details to be added, or for some reasons I don't know about yet this is not pursuable. but I thought noting this down, if it's of any help

[pboyd]

@tarilabs, I'm not sure that I follow you. Are you saying that every new user or service account should have access to the model registry in the shared-model-registry namespace?

Would it be sufficient to assign the default user ([email protected]) as the owner in the default manifests?

[tarilabs]

Would it be sufficient to assign the default user ([email protected]) as the owner in the default manifests?

to my understanding, that would work only for the ootb example installation. if that is sufficient for the purpose of "showcase a shared model registry", that would do. but to my understanding, the moment you create a new KF Profile, you would need to perform some additional actions (so it's not a truly shared MR instance, it works for as long as no new user have been added?) hope that explains my perspective, and for sure there are other gaps to identify

[pboyd]

but to my understanding, the moment you create a new KF Profile, you would need to perform some additional actions (so it's not a truly shared MR instance, it works for as long as no new user have been added?)

I believe you are correct. That makes sense now, I missed that you were trying to give access to any kubeflow profile, even those that will be created after the shared profile.

[adysenrothman]

/assign

[adysenrothman]

/unassign

[dhirajsb]

In general, I agree with @tarilabs proposal on this enablement requirement.

Right now, Model Registry does not play well with the profile based rbac for other components. We do provide manifests for creating a default model registry. But, without a default rbac config for it, user experience is diminished.

This default model registry was envisioned to be a cluster wide public registry from the start. So, for uniformity we could do the following:

• Create a profile called publc-model-registry for the default model registry
• Add all authenticated users to this profile

This way we remove the barrier for entry for new model registry users, while still complying with kubeflow's security model using profiles.

We should also document that this default model registry is public, and how to remove the default rolebinding for all authenticated users, if the user chooses to limit access to the default registry.

[lucferbux]

@tarilabs @dhirajsb Oh I'm sorry, I missed this conversation, but I agree with you. The only drawback right now is that the centra dashboard does not behave well with single Profile creation, we can right now create a profile and give access to all user:authenticated but we should tweak the central dashboard cause there are some lines of code that prevents us from using that solution. If we convert this into a proposal we could easily implement this, now that we are transitioning to a platform role and giving room more people to contribute to Model Registry we have bandwidth to start implementing this kind of logic. What do you guys think about that?

[tarilabs]

@lucferbux as previous comments, what about adding to the example the [email protected] from kubeflow installation access to the public-model-registry profile, and then document how to remove and add new users to this "public profile" to start with?

Happy if there is also the possibility to tweak the central dashboard to allow for user:authenticated, that would be compatible with the above as well.

[lucferbux]

Mmm, that's not a bad idea, sorry I missed @pboyd comment, but that would make so you can add more users easily to that. Yes, that way we are sticking to the current flow and we can imporove it from there. cc @manaswinidas @mturley FYI

[juliusvonkohout]

Hello, what is the current state? May i help somehow ?

[tarilabs]

Hello, what is the current state? May i help somehow ?

I think we've had some consensus on the way of proceeding summarized in this comment, but the teams are currently busy on other fronts. We could sync on it at the biweekly meeting.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[lucferbux]

@mturley FYI, we can chat about this whenever you want.

[juliusvonkohout]

I am also still on it, just busy with KFP and platform stuff.

[mturley]

@lucferbux is there any validation we need to do before we proceed with this? e2e testing on kind, that sort of thing?