Skip to main content

Workspaces

H2O workspaces group related resources together and control who can access them using role-based permissions (RBAC). Users create workspaces to collaborate with others while maintaining control over access. Workspace owners assign roles that grant uniform permissions across the entire workspace, though this doesn't extend to controlling access to individual resources within the workspace.

Note

For instructions on switching between workspaces, or creating and managing a workspace, see Create and manage a workspace.

Personal workspaces​

Each user in the platform starts with access to their own, "Personal workspace", which is a private container for their resources that cannot be shared with other users.. Users cannot add other users to their personal workspaces. It can be considered as the catch-all for general, unorganized work.

Users, user groups, and roles in workspaces​

H2O Workspaces allows roles to be assigned to either individual users or groups of users. Within a specific workspace, each user has permissions that allow them to do different actions in the workspace.

The list of users and groups is pulled from Keycloak. Keycloak may use an external identity provider to populate its internal user database. In such cases, users must log in at least once to synchronize their identity into Keycloak.

Users and administrators cannot define their own user groups—they must be defined within the Keycloak management UI or synchronized from the Keycloak identity provider using role-to-group mapping

A workspace inherits any platform roles that the user is assigned to, which may restrict certain actions (e.g., if a user's platform role does not allow them to deploy models, the user cannot do that in a particular workspace even if the workspace admin wants to grant them this permission).

Note

For more information about standard roles and permissions associated with those roles, see Workspace roles.

Workspace resource authorization​

H2O Workspaces provide first-level authorization for role-based access control. There is no resource-specific authorization. For example, if a user can view models in a workspace, they can view all models; and if a user can edit feature sets in the workspace, the user can edit all feature sets. Various products, like the App Store, implement their own authorization as a second level after workspace-level authorization.

Well known workspaces​

In addition to user-created workspaces, there are several "well known" workspaces with special meanings:

workspaces/global​

This workspace holds the global configuration for Engine Manager profiles for DriverlessAI, H2O-3, and the Notebook Engine. You cannot launch resources into this workspace (such as Engine Manager instances, App Store instances, and MLOps Models). The Global workspace is mostly read-only, except for the Engine Manager profiles.

workspaces/appstore​

The App Store workspace holds migrated App Store app instances that were launched before the Workspace feature was available, as well as managed App Store app instances that are accessible by many users.

Resources within a workspace​

Most products within H2O AI Cloud exist within a workspace, and each resource exists in exactly one workspace.

A few examples of workspace resources are:

  • App Store app instances
  • Engine Manager instances (DriverlessAI, H2O-3, and Notebook Engines)
  • MLOps datasets, experiments, and models
  • H2O Drive files
  • Secure Store credentials and OAuth clients

A few notable exceptions are:

  • App Store apps (the apps themselves, not instances)
  • Feature Store resources
  • H2O Drive app (does not currently support Workspaces)
  • h2oGPTe and EvalStudio (do not currently support Workspaces)
Feedback