API: List of available k8s namespaces for the workspace creation

[skabashnyuk]

Is your task related to a problem? Please describe.

We want to allow a user to select k8s namespace where he can create a workspace

Describe the solution you'd like

REST API that will return a list of available k8s namespaces for the workspace creation

Describe alternatives you've considered

n/a

Additional context

#13484

[l0rd]

I have created the corresponding dashboard issue and I assume that we also need:

• a new REST API to get the default namespace (c.f. Support one namespace per user strategy (che.osio like) #13488)
• update the workspace create API to allow specifying the target namespace

[sleshchenko]

I figure out some non-trivial aspects of implementing this issue and here I'm describing them and possible solutions I see:
Kubernetes
Kubernetes Infra does not have OAuth and cluster-admin rights are created by default by helm chart. So, allowing list(and potentially later created workspaces there) would introduce security issue and every Che user would be able to access to any of cluster namespace with limited (che-workspace-service account) permissions. Such namespaces may be default, cert-manager, kube,...
I'm proposing:
0.1 Allow to list all namespace but write like red upper case warning that it is not safe to do.
0.2 Delay supporting this functionality by K8s infra. My personal +1 here at least for the time being. I mean K8s infra still may return a list of namespaces but not all existing but available for workspace creation, and content of this list would depend on che.infra.k8s.namespace configuration properties:

1. che.infra.k8s.namespace=che - che is the only namespace that is listed.
2. che.infra.k8s.namespace=<username>-workspace - each user retrieves the personalized name of a namespace name, like sleshchenko-workspace, even if such namespace does not exist. Che Server should be able to create it on the first workspace start.
3. che.infra.k8s.namespace= - empty value produces a difficulty since the current behavior is - create a separate namespace for each workspace with name workspace.id. Since a list of namespaces would be the most useful before workspace creating(when workspace.id is not known), Che Server is not able to evaluate the concrete namespace name. And here I see the following solutions:
   3.1. STOP SUPPORTING new namespace per workspace. We have some input that definitely such configuration is not production-ready since it's impossible for k8s admin to control well resources consumed by users and it's why we may consider it as to go. BUT here is unclear question - what to do with existing instances with such configuration.
   3.2 Propagate <workspaceid> as namespace name, and then client would be able to analyze it and inform the user that new namespace will be created for this workspace.

OpenShift
OpenShift infra has oAuth and there is che.infra.openshift.project configuration property name, that allows admin control where workspaces should be created.
1st and 2nd options are pretty the same as for k8s but if oAuth is configured - then user personal token will be used.
3. che.infra.openshift.project= + Oauth is disabled. Should not be a valid configuration since Che does not have cluster-admin rights by default.
4. che.infra.openshift.project= + Oauth is enabled. The user retrieves all existing projects (to which he has access) and he is able to specify any of it as target project for workspace, but also he is able to specify free project name (non-existing) and Che will try to create a new project with his personal account. To keep the current behavior - with <workspace.id> we can go different ways::
4.1 we can stop supporting new namespace per workspace and make target namespace parameter required if it's not configured by admin and OAuth is configured.
4.2 we can translate empty value for target namespace as workspaceid in such case

P.S. When I mention target namespace I mean that it would be implemented in scope of next issue, not the current.
P.S.S Bold items are alternative ways to go and we should choose between them.

[skabashnyuk]

@sleshchenko I think due to a large number of existing installation 3.1 and 4.1 is hard/impossible.
I would say we should go in 3.2 and 4.2 way.
About Kubernetes. What if we set che.infra.k8s.namespace=-workspace by default. In case che.infra.k8s.namespace= - empty - return 0.1 because it's an admin decision to change the default behavior.

CC @l0rd

[l0rd]

Some easy consideration I think we agree on:

• che.infra.k8s.namespace=<username>-che should be the default
• che.infra.k8s.namespace= for retro-compatibility, behave as if <username>-che was set

The non-OAuth scenario: in real world clusters I expect OAuth to be enabled. If that's not the case, having some restrictions is acceptable:

• only return the default namespace
• do not allow to specify namespaces other than the default one

Some other proposals:

• replace che.infra.k8s.namespace with che.infra.k8s.default_namespace
• using the same che.infra.k8s.default_namespace property for both k8s and OS

[sleshchenko]

Summary of the solution we can start with:

• New che.infra.kubernetes.namespace.default property is introduced. It's like Che Admin recommendation where workspaces should be started.
  Possible values:

  • any string defines the exact name of namespace that should be used for all workspaces. Note: must be k8s compatible https://kubernetes.io/docs/concepts/overview/working-with-objects/names/
  • anystring<username>anystring defines personalized name of namespace that should be used for workspaces
  • empty value user must provide namespace name. Should not be configured if allow_user_defined=false.
    Defaults to <username>-che.
    For the single-user value should be the same as Che Server namespace.

• New che.infra.kubernetes.namespace.allow_user_defined property is introduced. It defines if Che Server should grab all user’s available namespaces from K8s/OS cluster.
  Possible values: true/false. Defaults to false.
  Should be used only if OpenShift OAuth is configured. Otherwise:

  • Che has cluster-admin rights -> user may access system namespaces if;
  • Che does not have cluster-admin rights and uses service account -> Che is not able to list namespaces;

• che.infra.kubernetes.namespace is deprecated but is not removed at all for backward compatibility. This value MUST NOT be updated anymore, otherwise, users may lose their data for existing workspaces since workspace may be started in a new namespace where existing PVCs won’t be available.

Examples how che.infra.kubernetes.namespace.default and che.infra.kubernetes.namespace.allow_user_defined works together

• che.infra.kubernetes.namespace.default=""
che.infra.kubernetes.namespace.allow_user_defined=true
  A user receives all available to him namespaces and can choose any, or even maybe specify any value for namespace name and then Che Server would try to create new one with such name.

• che.infra.kubernetes.namespace.default="che" or "<username>-che"
che.infra.kubernetes.namespace.allow_user_defined=true
  A user receives all available to him namespaces + predefined one(even if such does not exist) and can choose any, or even maybe specify any value for namespace name and then Che Server would try to create new one with such name.

• che.infra.kubernetes.namespace.default="che" or "<username>-che"
che.infra.kubernetes.namespace.allow_user_defined=false
  A user receives only predefined namespace(even if such does not exist) and is not able to create workspace outside of default one.

Note: When a user creates a workspace they specify a namespace for it.
Chosen namespace value is stored in workspace attributes.

How che.infra.kubernetes.namespace.default and che.infra.kubernetes.namespace provide backward compatibility

All newly created workspaces will have a namespace name in attributes, this value will be used for starts.

There is an existing workspace that was created like before 7.1.0 and namespace was used for it.
So,

• user start such workspace
• Che Server checks that workspace does not contain namespace attribute
• Che Server evaluates che.infra.kubernetes.namespace value and checks if such namespace exists
  • If yes - use such workspace, like
  • If no - che.infra.kubernetes.namespace.default should be evaluated and set to workspace attribute. And after used for workspace start.

cc @skabashnyuk @l0rd @metlos