Create OpenShift objects under current user account on OCP

[skabashnyuk]

Description

In some situation, it might be useful to configure
Eclipse Che to create OpenShift object under different user accounts.
Now we are creating it in a simplest possible way - under the name of the preconfigured user.
It might be useful if there is a need to use Openshift internal mechanism to limit and manage resources.

I think this mode would be reasonable to have with multi-user Che only.

• In this case, we can configure keycloak to use Openshift master to act as OAuth server
  https://docs.openshift.com/enterprise/3.0/architecture/additional_concepts/authentication.html#oauth
• Next question how to identify namespace where to create Openshift objects. Variants:

1. Create a new project for each user workspace.
2. Create all user workspaces in single project
   2.1 Namespace name is preconfigured.
   2.2. Each user has individual algorithm to identify the namespace. Which one?

[gorkem]

Isn't this a blocker for OSIO?

[skabashnyuk]

No, because on OSIO there are special components that talks to dedicated Auth services(that does not exist out of the box on OCP) that is providing necessary information about Openshift tokens and user namespaces.

[gorkem]

On the single user model, are all the workspaces created under a single project and namespace for the configured single user?

[garagatyi]

We have two modes for the namespace choosing right now. With the first one, indeed, al the objects of all the workspaces will be created in a single project(namespace). With the second one, a unique PVC will be used for each Che volume of a workspace, so all the workspaces will have different PVCs.

[gorkem]

I was looking at the behavior of the current implementation and I think we are on the wrong track there. With the current implementation we are practically shutting all the tooling like oc CLI, kedge etc to be used by Che workspaces because we do not play to the rules of openshift access control. I do not think we can afford to ignore the whole kubernetes/openshift tooling ecosystem.

Earlier I have assumed that we actually had a privileged service account used by Che to create k8s/OS objects on behalf of other OS users. I think that would still allow OS users to use OS tools to access work with their own workspaces. OTOH if we can manage this without privileged account that would go a long way. @skabashnyuk I would appreciate if you can work with @l0rd around this and consume some of the solutions created on OSIO.

[l0rd]

This has been fixed and doc is here https://www.eclipse.org/che/docs/6/che/docs/openshift-config.html#namespace-for-workspaces. @eivantsov can you confirm that we can close this one?

[ghost]

@l0rd not really fixed. We still use either predefined token, username/pass or sa to create ws objects.

[l0rd]

@eivantsov what is missing to close it?

[ghost]

@l0rd as far as I understand we have stopped thinking about this one. PMs never prioritized it as this is a SaaS scenario, like RH Che, which, however, creates objects with user's token (not directly but still on behalf of a user)

[l0rd]

Ok @eivantsov sorry my bad. I thought we could close this issue because Che is now able to deploy workspaces using a privileged service account. But what is still missing is linking the Che user with one OpenShift namespace he owns and where we will deploy his workspaces.

Currently we support the following scenarios:

• all workspaces, for all users, are deployed in the same OpenShift namespace
• each workspace is deployed in a new ad-hoc namespace

The scenario we are still missing:

• all workspaces for a given user are deployed in the user namespace

[bmicklea]

This is something that is becoming a blocker in prospect accounts. Not all users in an organization want to use Che's IDE, or some want to compliment Che's IDE with command line tools, etc... For this they'd like to be able to rsync into their Che workspace pod using their own credentials.

Do we have a sense of whether this could be tackled in the next release train?

[garagatyi]

@bmicklea in the second case described by Mario it works like you are describing:

each workspace is deployed in a new ad-hoc namespace

Does it work for your case or you mean we need something else?

[ghost]

@garagatyi yes, the idea is that a workspace owner is the owner of the workspace pod.

[bmicklea]

The goal is to make sure that if I'm the workspace owner I can access the pods in my workspace using my credentials to connect my desktop IDE, push files, etc...

[davidfestal]

The main PR related to this work #9577 has been merged, as well as the associated Docs PR eclipse-che/che-docs#406

I'll let upstream code owners close this issue if they think it should be closed now.