Introduction to Multi-user Isolation
In a production environment, it is often necessary to share the same pool of resources across different teams and users. These different users need a reliable way to isolate and protect their own resources, without accidentally viewing or changing each other’s resources.
Kubeflow v1.1.0 supports multi-user isolation, which applies access control over namespaces and user-created resources in a deployment. This feature provides the users with the convenience of clutter-free browsing of notebooks, training jobs, serving deployments and other resources. The isolation mechanisms also prevent accidental deletion/modification of resources of other users in the deployment.
Note that the isolation support in Kubeflow doesn’t provide any hard security guarantees against malicious attempts by users to infiltrate other user’s profiles.
Key concepts
Administrator: An administrator is someone who creates and maintains the Kubeflow cluster. This person has the permission to grant access permissions to others.
User: A user is someone who has access to some set of resources in the cluster. A user needs to be granted access permissions by the administrator.
Profile: A profile is a grouping of all Kubernetes clusters owned by a user.
Current integration and limitations
The Jupyter notebooks service is the first application to be fully integrated with multi-user isolation. Access to the notebooks and the creation of notebooks is controlled by the profile access policies set by the administrator or the owners of the profiles. Resources created by the notebooks (for example, training jobs and deployments) also inherit the same access.
Kubeflow Pipelines is partially integrated with multi-user isolation starting from Kubeflow v1.1. You can find more information on Multi-user Isolation for Pipelines.
Metadata or any other applications currently don’t have full fledged integration with isolation, though they do have access to the user identity through the headers of the incoming requests. It’s up to the individual applications to use the available identity and isolation features in a way that makes sense for each application.
On Google Cloud Platform (GCP), the authentication and identify token is generated by GCP IAM and carried through the requests as a JWT Token in the request header. Other cloud providers can have a similar header to provide identity information.
For on-premises deployments, Kubeflow uses Dex as a federated OpenID connection provider and can be integrated with LDAP or Active Directory to provide authentication and identity services.
Next steps
- Understand the detailed design of Kubeflow’s multi-user isolation feature.
- Learn how to use multi-user isolation and profiles.
Feedback
Was this page helpful?
Glad to hear it! Please tell us how we can improve.
Sorry to hear that. Please tell us how we can improve.