Principle:Kubeflow Kubeflow Multi User Configuration
| Knowledge Sources | |
|---|---|
| Domains | Kubeflow, Platform Deployment, Multi-Tenancy, RBAC |
| Last Updated | 2026-02-13 00:00 GMT |
Overview
Multi-user configuration is the process of establishing tenant isolation in Kubeflow by creating per-user namespaces via the Profile CRD, enforcing RBAC policies, and integrating with OIDC authentication.
Description
Kubeflow supports multi-tenancy through a combination of three mechanisms:
- Profile CRD — A custom resource that represents a user workspace. When a Profile is created, the Profile Controller automatically provisions a dedicated Kubernetes namespace, configures resource quotas, and sets up the necessary RBAC bindings. The Profile's spec.owner.name field maps to the user's OIDC identity.
- RBAC (Role-Based Access Control) — Each Profile namespace receives RoleBindings that grant the profile owner full access to their namespace while restricting access from other users. Additional contributors can be granted access via the Profile's contributor list.
- OIDC Integration — Istio AuthorizationPolicies enforce that only authenticated users can access Kubeflow services. The OIDC token (issued by Dex) carries the user identity that is matched against Profile ownership to determine namespace access.
The Profile Controller runs as a reconciliation loop: it watches for Profile custom resources and ensures the corresponding namespace, RBAC bindings, and Istio policies exist and are correctly configured. If a Profile is deleted, the controller cleans up the associated namespace and all its resources.
Kubeflow also supports a self-serve mode where authenticated users can create their own Profiles through the Central Dashboard without administrator intervention.
Usage
Configure multi-user isolation in the following scenarios:
- Initial platform setup when multiple data scientists or ML engineers will share the cluster
- Onboarding a new team member who needs their own Kubeflow workspace
- Configuring shared namespaces for collaborative projects
- Auditing namespace access to ensure compliance with organizational security policies
- Enabling self-serve namespace creation for teams that manage their own onboarding
Theoretical Basis
The multi-user configuration follows a layered isolation model:
Layer 1: Identity Establishment
- Users authenticate through the Central Dashboard, which redirects to Dex
- Dex verifies credentials against the configured upstream identity provider
- Upon successful authentication, Dex issues an OIDC token containing the user's email claim
- The OIDC token is stored in a session cookie for subsequent requests
Layer 2: Profile and Namespace Creation
- An administrator (or the user in self-serve mode) creates a Profile custom resource
- The Profile spec.owner.name is set to the user's OIDC email
- The Profile Controller reconciles by creating a namespace matching the Profile name
- The controller creates RoleBindings granting the owner cluster-role/kubeflow-edit in the namespace
Layer 3: Access Enforcement
- Istio AuthorizationPolicies are created in each Profile namespace
- These policies validate that incoming requests carry a valid OIDC token
- The token's email claim must match the Profile owner or be listed as a contributor
- Requests without valid tokens are rejected at the Istio sidecar level
Layer 4: Resource Isolation
- Each namespace has independent resource quotas (CPU, memory, GPU)
- Kubeflow Pipelines, Notebooks, and other components scope their resources to the user's namespace
- Cross-namespace access is blocked by default
Self-Serve Flow:
- User logs into Central Dashboard
- Dashboard presents a namespace creation form
- User submits the form, which creates a Profile CR
- Profile Controller provisions the namespace within seconds