[STEP3] user's namespace provisioning

[skabashnyuk]

Is your task related to a problem? Please describe.

Che server is able to use its configuration to set various settings on the workspace pod and/or user's namespace. We should think about supporting them on the DevWorkspaces, too:

• custom certificates feat: Syncing of proxy settings and self-signed cert to the user's workspace namespace che-operator#1027
• proxy settings feat: Syncing of proxy settings and self-signed cert to the user's workspace namespace che-operator#1027
• Use image pull secrets stored as credentials in user preferences of Che-server in DevWorkspaces #20534
• Support setting termination grace period on the DevWorkspace pod devfile/devworkspace-operator#615
• Support custom certificates for git hosts for devworkspaces #20528 (che-platform)
• Include ssh keys and tls certs into gitconfig devfile/devworkspace-operator#613 (controller)
• Provision SSH keys that are stored in the PostgreSQL database to the user's namespace in a known to devworkspace-controller format #20832
• Support for namespace-level configuration of pod tolerations and node selector #20884 (che-platform)
• Support Pod tolerations for DevWorkspace Pods devfile/devworkspace-operator#614

Describe the solution you'd like

1. Create new custom resource CheUser like

apiVersion: org.eclipse.che/v1beta1
kind: CheUser
metadata:
 name: username
spec:
  id: 238409230-2349023049-24509i
  firstName: John
  lastName: Doe
  profile:
    attributes:
       a1:v1

2. On CheUser creation/update run k8s namespace reconcile loop that will create k8s secret with custom certificates

apiVersion: v1
kind: Secret
metadata:
  name: ca-crt-secret
  labels:
    controller.devfile.io/mount-to-devworkspace: "true"
  annotations:
    controller.devfile.io/mount-path: '/tmp/che/secret/'
data:
  ca.crt: <base64 encoded data content here>

3. Create secret with proxy settings

apiVersion: v1
  kind: Secret
metadata:
  name: env-var-secret
  labels:
    controller.devfile.io/mount-to-devworkspace: "true"
  annotations:
    controller.devfile.io/mount-as: env
data:
  https_proxy: value
  http_proxy: value
  no_proxy: value

Describe alternatives you've considered

All the settings that would be in the CheUser instance can also be placed in variously labeled config maps and secrets and the user information can be drawn from OpenShift's User object or, hopefully, from the user info of the OIDC provider of Kubernetes.

Additional context

• Automount configmaps/secrets into devworkspaces devfile/devworkspace-operator#417
• https://github.com/eclipse-che/che-server/blob/main/infrastructures/kubernetes/src/main/java/org/eclipse/che/workspace/infrastructure/kubernetes/provision/ProxySettingsProvisioner.java
• https://github.com/eclipse-che/che-server/blob/main/infrastructures/kubernetes/src/main/java/org/eclipse/che/workspace/infrastructure/kubernetes/provision/CertificateProvisioner.java
• https://www.eclipse.org/che/docs/che-7/end-user-guide/mounting-a-secret-as-a-file-or-an-environment-variable-into-a-workspace-container/#mounting-a-secret-as-a-file-into-a-workspace-container_che

[tolusha]

2. All certificates are put into ca-certs-merged configmap
3. All workspace options are put into che configmap:
   CHE_WORKSPACE_JAVA__OPTIONS
CHE_WORKSPACE_MAVEN__OPTIONS
CHE_WORKSPACE_HTTP__PROXY__JAVA__OPTIONS
CHE_WORKSPACE_HTTP__PROXY
CHE_WORKSPACE_HTTPS__PROXY
CHE_WORKSPACE_NO__PROXY

[metlos]

In the PR eclipse-che/che-operator#1027 we're implementing this by watching namespace events (or project events on OpenShift). This way, we can pre-deploy the namespace with all necessary objects for different secrets and other settings as soon as the namespace is marked as a workspace namespace for a particular user using a dedicated label.

This means that we don't have to do additional checks on workspace startup and let the devworkspace operator do its magic of auto-mounting the secrets and configmaps into the workspace pod as configured (either as files or as env vars).

[skabashnyuk]

@tolusha I propose to cover *_OPTS issue with #20501
CC @metlos @l0rd

[tolusha]

@skabashnyuk
ok for me

[metlos]

Note that since this is an epic issue, I updated it with a list of subtasks for each of the things that the che server is currently provisioning into the workspace pod. We need to figure out the priority of those and if or how to implement them. Some of the tasks are implementable only on the DWO side, some can be implemented in che-operator, some will probably require changes in both.

[skabashnyuk]

@l0rd could you please review the list of remainings and wrote your option about what is mandatory/option for Step 3.

[l0rd]

As a rule of thumb: higher priority to features that existed in che-server land but do not exist in devworkspace land, lower priority to new features that didn't exist in che-server land.

In STEP 3 milestone and ordered by priority:

• Support custom certificates for git hosts for devworkspaces #20528 (implemented in DWO)
• Include ssh keys and tls certs into gitconfig devfile/devworkspace-operator#613
• Support custom service account for DevWorkspaces #20535
• Support Pod tolerations for DevWorkspace Pods devfile/devworkspace-operator#614
• Support setting termination grace period on the DevWorkspace pod devfile/devworkspace-operator#615

Not in STEP 3 milestone:

• Mount a volume that is bound to the user and not each workspace #20600
• Configurable resource limits for devworkspaces #20527
• An admin should be able to specify Secrets, ConfigMaps and PersistentVolumesClaims that need to be provisioned on each user's namespace #20501
• Users should be able to configure their workspace pods securityContext capabilities #20459

Closed

• Use image pull secrets stored as credentials in user preferences of Che-server in DevWorkspaces #20534