[FEATURE] Conditional Authorization on GET /workspacekinds

[andyatmiami]

Certification

• I certify I am an Epic Owner for Kubeflow Notebooks 2.0 and expected to create planning-related issues.

Motivation

Loosely, we have been viewing the /workspacekinds APIs as "administrative" APIs to be leveraged by Joel - but unfortunately its not quite that simple. The nuance comes with the GET /workspacekinds API - which is leveraged in a couple different ways in the frontend component

Bella-centric listing of workspace kinds

Joel-centric listing of workspace kinds

We want the codebase to account for the "dual persona" nature present in GET /workspacekinds. Ideally we would use RBAC with an identifiable "admin" role to identify if we should invoke GET /workspacekinds in a manner suitable to Bella or Joel. However, there is more complexity there than we want to bite off at this time. So the proposal we will pursue will be an incremental step that achieves the basic functional goal.

We will add an optional namespaceFilter query parameter to the GET /workspacekinds endpoint:

• GET /workspacekinds?namespaceFilter=

High Level Design / Mock-ups

Proposed ResourcePolicy for Bella

authPolicies := []*auth.ResourcePolicy{
		auth.NewResourcePolicy(
			auth.ResourceVerbCreate,
			&kubefloworgv1beta1.Workspace{
				ObjectMeta: metav1.ObjectMeta{
					Namespace: namespace				},
			},
		),
	}

• Admittedly, at face value, this ResourcePolicy looks like a typo (but it isn't!). Recall that Bella is actually trying to create a workspace - and just needs to list the WorkspaceKinds in the frontend to make a selection. In the absence of a clearly defined administrative role, what this ResourcePolicy is enforcing is:
  • the user has the permission to create a workspace in the given namespace (ultimately what Bella is trying to do). If a user cannot create a Workspace for the given namespace, then they cannot list workspace kinds.
  • This ONLY applies to the list workspace kinds endpoint!!!

Acceptance Criteria

Bella-centric listing of workspace kinds
When Bella is attempting to create a workspace:

• the GET /workspacekinds API will have the namespaceFilter query parameter populated by the frontend based on the active selection of the Namespace dropdown.
• the backend will use a different ResourcePolicy for authorization (see above)
• a namespaceMetrics attribute will be included in the API response (conceptually very similar to what clusterMetrics is today - but any data included would be restricted to the specific namespace)
  • workspacesCount would be the only attribute we expect to include in namespaceMetrics at this time
• the clusterMetrics attribute will NOT be included in the API response

Joel-centric listing of workspace kinds
When Joel is attempting to list workspace kinds:

• the GET /workspacekinds API will NOT include the namespaceFilter query parameter
• the backend will use the present authorization ResourcePolicy
• a namespaceMetrics attribute will NOT be included in the API response
• the clusterMetrics attribute will (continue to) be included in the API response