In reply to@_slack_kubeflow_UE4TG9TJ8:matrix.org
I want the Cloud Pipelines Editor app to be usable with on-prem installations. (Pipeline Editor is a drag-and-drop pipeline editor with 1st-class support for Kubeflow Pipelines: https://cloud-pipelines.net/pipeline-editor/) What would be the most common way to authenticate and connect to an on-prem API server? Think of this from the UX perspective: What is the minimum amount of information the user must enter (e.g. the endpoint URL plus token) to be able to authenticate with the API server and submit a pipeline.

In reply to@_slack_kubeflow_U01CELR6Q9E:matrix.org
An interesting option would be to deploy Pipeline Editor within a Kubeflow cluster and authenticate via ServiceAccountToken like you would typically do from a Notebook Server. This wouldn't need any information beyond the (internal) kfp endpoint. By the way, I really like the idea of the Pipeline Editor with its focus on reusable components 👍

In reply to@_slack_kubeflow_UE4TG9TJ8:matrix.org
Is that how KFP is normally used on-prem? Vis in-cluster notebook, not from outside of the cluster via proxies? Does the ServiceAccountToken end up being transformed and passed as Bearer token with the REST request? > By the way, I really like the idea of the Pipeline Editor with its focus on reusable components Thank you, Matthew. The reusable component ecosystem was my passion since 2018 when I developed the format. The Pipeline Editor was my vision from the start, but I did not know enough frontend and there were no good drag and drop UX libraries. I jumped in as soon as I saw a usable drag-and-drop web UX library.

In reply to@_slack_kubeflow_U01CELR6Q9E:matrix.org
Exactly, the ServiceAccountToken ist projected into the pod and then send as a bearer token. There is a good explanation about it here: https://github.com/kubeflow/pipelines/issues/5138 I think this would make PipelineEditor usable regardless of how authentication is set up. In addition, it would be great to access PipelineEditor as a tab in Kubeflow. When running outside the cluster, things get more complicated. In that case it's necessary to obtain a session token. This could be done programmatically as shown here: https://github.com/kubeflow/kfctl/issues/140 Unfortunately this depends on your authentication setup. By default his will be Dex (https://www.arrikto.com/blog/kubeflow/news/kubeflow-authentication-with-istio-dex/) but others use keycloak instead. The authentication routine would be different for every setup. Taking elyra as an example, they implemented authentication for a couple of different Dex configurations: https://elyra.readthedocs.io/en/latest/user_guide/runtime-conf.html#kubeflow-authentication-type-auth-type

In reply to@_slack_kubeflow_U01CELR6Q9E:matrix.org
But if you're just looking for the absolute minimum amount of information for a Proof of Concept, the API endpoint and (manually obtained) session token should suffice

In reply to@_slack_kubeflow_U01CELR6Q9E:matrix.org
On second thought: It's probably also necessary to specify in which namespace the run should be started.