Multi-user Isolation for Pipelines

    Multi-user isolation for Kubeflow Pipelines is an integration to Kubeflow multi-user isolation.

    Refer to for the common Kubeflow multi-user operations including the following:

    Note, Kubeflow Pipelines multi-user isolation is only supported in the full Kubeflow deployment starting from Kubeflow v1.1 and currently on all platforms except OpenShift. For the latest status about platform support, refer to .

    Also be aware that the isolation support in Kubeflow doesn’t provide any hard security guarantees against malicious attempts by users to infiltrate other user’s profiles.

    Kubeflow Pipelines separates its resources by Kubernetes namespaces (Kubeflow profiles).

    Experiments belong to namespaces directly and there’s no longer a default experiment. Runs and recurring runs belong to their parent experiment’s namespace.

    Pipeline runs are executed in user namespaces, so that users can leverage Kubernetes namespace isolation. For example, they can configure different secrets for other services in different namespaces.

    Note, there’s no multi-user isolation for pipeline definitions right now. Refer to Current Limitations section for more details.

    When you visit the Kubeflow Pipelines UI from the Kubeflow dashboard, it only shows experiments, runs, and recurring runs in your chosen namespace. Similarly, when you create resources from the UI, they also belong to the namespace you have chosen.

    You can select a different namespace to view resources in other namespaces.

    First, you need to connect to the Kubeflow Pipelines public endpoint using the SDK. For Google Cloud, follow .

    When calling SDK methods for experiments, you need to provide the additional namespace argument. Runs, recurring runs are owned by an experiment. They are in the same namespace as the parent experiment, so you can just call their SDK methods in the same way as before.

    For example:

    To store your user namespace as the default context, use the method. This method stores your user namespace in a configuration file at . After setting a default namespace, the SDK methods default to use this namespace if no namespace argument is provided.

    Detailed documentation for the Kubeflow Pipelines SDK can be found in the .

    Similarly, when calling REST API endpoints or using , namespace argument is required for experiment APIs. Note that namespace is referred to using a resource reference. The resource reference type is and resource reference key id is the namespace name.

    The following example demonstrates how to use the generated Python API client (kf-server-api) in a multi-user environment.

    Current limitations

    The following resources do not currently support isolation and are shared without access control:

    • Pipelines (Pipeline definitions).
    • Minio artifact storage which contains pipeline runs’ input/output artifacts.

    Clients can only access the Kubeflow Pipelines API from the public endpoint that enforces authentication.

    In-cluster direct access to the API endpoint is denied by Istio authorization policies, because there’s no secure way to authenticate in-cluster requests to the Kubeflow Pipelines API server yet.

    If you need to access the API endpoint from in-cluster workload like Jupyter notebooks or cron tasks, current suggested workaround is to connect through public endpoint and follow platform specific documentation to authenticate programmatically using user credentials. For Google Cloud, you can refer to .