[feature] Merge Pipelines Profile Controller functionality into the general profile controller

[davidspek]

Feature Area

/area backend

The Kubeflow Pipelines profile controller now takes care of launching 2 deployments (UI Artifact and Visualization Server) in each user namespace when a profile is created. While busy implementing AWS RDS and S3 support for KFP in ArgoFlow @karlschriek ended up using the KFP profile controller to create other resources (in this case an ExternalSecret) when a profile is created.

What feature would you like to see?

The flexibility and extendable nature of the KFP profile controller should be part of the main profile controller.

What is the use case or pain point?

Many Kubeflow admins would most likely want to automate creating arbitrary resources when a new Kubeflow profile is created. For example, registry secrets or secrets with credentials to object storage buckets.

Is there a workaround currently?

The KFP profile controller can be extended and used to create arbitrary resources on profile creation. However, similar to #5681, it would be best to consolidate this functionality into a single profile controller. Especially given that the use cases are not strictly tied to KFP.

/cc @kubeflow/wg-pipeline-leads @kubeflow/wg-notebooks-leads

---

Love this idea? Give it a 👍. We prioritize fulfilling features with the most 👍.

[Bobgy]

Thank you for raising the concern @davidspek!

Let me share some past context, at the time when KFP introduced KFP profile controller, we had many discussions with Kubeflow engineering team at Google (who was maintaining the main profile controller). The conclusion we reached was that it's better for everyone that KFP starts its own profile controller.

The major reason is to reduce coupling, KFP can be self contained and released on its own.
It's simpler for KFP to maintain its own profile controller than enhancing a special syntax in kubeflow profile controller and configure it to do so.

For more previous discussion, you can refer to @yanniszark's doc on profile management
Kubeflow: Evaluate and Improve our Multi-Tenancy Implementation

Profile Plugins should be implemented as separate controllers

At the moment, Profile Plugins are implemented as additional code inside the Profile controller.
This monolithic approach isn’t scalable and also makes the plugin functionality non-reusable.
Instead, plugins should follow a controller-like approach, where they watch for user-namespaces (e.g. with a specific label) and configure them accordingly.
New applications that need namespace-specific initialization should handle it themselves.

[Bobgy]

The difference between profile controller and #5681 is that, the nature of profile controller is user requests are ad-hoc:

• kubeflow has its own resources it wants to deploy to user namespaces
• KFP has some resources
• KFServing has some resources
• Kubeflow cluster admins may have some cluster-specific resources they want to deploy

A generic profile controller that can deploy any resource with configuration is only ever a worse version of more generic controller helpers like https://github.com/metacontroller/metacontroller or https://sdk.operatorframework.io/docs/building-operators/helm/tutorial/. Therefore, it's meaningless to recreate our own wheels. The existing toolings are what we recommend for these specific use-cases, because building a controller for your own requirements is no longer a hard thing.

[Bobgy]

Another point is that, the necessity of a profile controller itself is also questionable, cluster admin can use git-ops to manage namespace default resources using a parameterizable common kustomize package too. The major reason we needed kfam and profile controller was because we needed the ability to provide self service experience -- users can come and register their own namespaces. However, there are already many Kubeflow members clarifying they don't want this experience at all, it's better admin configure ACL directly.

[davidspek]

I completely agree with all the points you've raised. The reason I brought this up is because I thought it would make sense to make it easier for admins to customize the user on-boarding experience. However, if there are existing tools it makes more sense to use those.

@karlschriek and I have been working a lot on ArgoFlow for AWS using Argo CD. After re-implementing authentication I started to work on adding Keycloak as a deployment option and it got me thinking about integrating the Keycloak user creation with the profile controller. The need for the profile controller is indeed a bit questionable, the default service accounts it creates also do not cater to using fine grained permissions for users.

I've also thought the use of something like RBAC Manager or Permission Manager (the former being Apache2, the latter BSD-3 but including a UI) would be a good a good integration to give administrators the possibility to easily assign fine grained permissions to users. I haven't looked into this much yet, but I believe the main thing that would need to be changed for not relying on the profile controller is the namespace selection process in the central dashboard.

[ca-scribner]

@Bobgy I find it interesting you've gotten feedback from Kubeflow members don't want the experience of users being able to generate their profiles. From our org I think we actually appreciate this feature quite a bit, as it lets us spread access easily. Not to say it couldn't be achieved in a way other than the profile controller though of course

[stale]

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.

[stale]

This issue has been automatically closed because it has not had recent activity. Please comment "/reopen" to reopen it.