[devworkspace-che-operator] Prototype and plan of controller that is reconciling resources in user's namespace

[skabashnyuk]

Is your task related to a problem? Please describe.

The goal of this task is to have Prototype and plan version of #20168

Describe the solution you'd like

We need to understand what will be a trigger to start. It could be

1. New CR, for Example, CheUser
2. Namespace create/update/delete with proper labels.

If we decide to go in the direction of 1. we need to define a model of this CustomeResource.
Here #20168 we want to reconcile certs and secretes, however
for the prototype I think we can choose one. What is easier.

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

• Q1. What if the user changes the username/id?

Describe alternatives you've considered

Trigger on Namespace create/update/delete with proper labels.

Additional context

#20164

[sparkoo]

we should explore what oidc guarantees us for user https://openid.net/specs/openid-connect-core-1_0.html#UserInfo and how it is implemented on OpenShift

[sparkoo]

This is what I've got from dex on /userinfo request as configured here https://github.com/che-incubator/che-auth-playground/tree/master/minikube_dex

[~/dev/che-auth-playground/minikube_dex] (master ✘)✹✭ λ curl -k -H "Authorization: Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6IjQwMDczNTI1NzBmYzFhNGZiMjM3MTcxYzE5YjZlN2RlYjA4NmQ5NzkifQ.eyJpc3MiOiJodHRwczovL2RleC4xOTIuMTY4LjM5LjE2NS5uaXAuaW86MzIwMDAiLCJzdWIiOiJDZ0V4RWdWc2IyTmhiQSIsImF1ZCI6ImV4YW1wbGUtYXBwIiwiZXhwIjoxNjI4MDk1NjcwLCJpYXQiOjE2MjgwMDkyNzAsImF0X2hhc2giOiJHcDgzdXFVV0N6bVVlajkzRFVNYXNnIiwiZW1haWwiOiJ1c2VyMUBjaGUiLCJlbWFpbF92ZXJpZmllZCI6dHJ1ZSwibmFtZSI6InVzZXIxIn0.k2T1RQgOjCU8wli0p5RUEgAXftMjqFnR3pDxgERcHZvxk0uHMiytyjRf6HoKckAg0IcnGLOu63CfX1nsB1CIICtff6E3HwVxOLJupGiZ2g7i9PcxiNHEj-LnqC6mQ7Io13T_DW_dRc9y7mVBiu8G6DP91uETFVy23AVREsbDSKkeQcgJOFUFakWpcLoSUlY-vfORmdpubYqj4XVSEOOpzp4-tRzNr200vSDj4idMv2fyFpRouEdgzGbk3W6KLluY-2kTQFC0Qh72Wki2AYNVJGBTUqKQH4pPAY_SFFu2E71TxU2HjWkmyNLTrW2VmkuP2k3L8gmbvS_-6AsczYKeuA" https://dex.192.168.39.165.nip.io:32000/userinfo | jq
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   218  100   218    0     0   6606      0 --:--:-- --:--:-- --:--:--  6812
{
  "iss": "https://dex.192.168.39.165.nip.io:32000",
  "sub": "CgExEgVsb2NhbA",
  "aud": "example-app",
  "exp": 1628095670,
  "iat": 1628009270,
  "at_hash": "Gp83uqUWCzmUej93DUMasg",
  "email": "user1@che",
  "email_verified": true,
  "name": "user1"
}

Openshift implementation does not have /userinfo endpoint at all, so we have to access it thgrough openshift client, as we're already doing here https://github.com/eclipse-che/che-server/blob/main/infrastructures/openshift/src/main/java/org/eclipse/che/workspace/infrastructure/openshift/multiuser/oauth/OpenshiftTokenInitializationFilter.java#L113

[metlos]

According to https://docs.microsoft.com/en-us/azure/active-directory/develop/userinfo the ID token should contain the same information as userinfo.. does openshift oauth give access to the id token?

[sparkoo]

does openshift oauth give access to the id token?

IMHO openshift uses only sha256 token so we can't get anything from the token itself. I've never seen anything else on openshift (You can get it in openshift console https://docs.openshift.com/online/pro/cli_reference/get_started_cli.html#installing-the-cli see the 1st paragraph)

[skabashnyuk]

PR eclipse-che/che-operator#1027 and plan #20168 (comment)

[metlos]

I've compiled a list of "settings" that the che-server is currently provisioning into the workspace pod that are not yet explicitly done in DWO or che-operator. @sleshchenko , @skabashnyuk, could you please take a look if I missed or misinterpreted something there?

• environment variables - this could be considered a part of An admin should be able to specify Secrets, ConfigMaps and PersistentVolumesClaims that need to be provisioned on each user's namespace #20501. Che server supports the values of other environment variables referenced - do we need to support that, too here?
• default workspace memory/cpu limits - this is currently hardcoded by DWO to 64M/128M for memory. Do we need to make it configurable?
• default PVC size - this is currently hardcoded by DWO to 1Gi, and can be configured with namespaces configmap Add support for per-namespace configuration and add setting for workspace PVC request size devfile/devworkspace-operator#487
• git credentials - support for this is probably ready in DWO, but don't understand the feature set of both impls fully Validate factory flow with devfile v2 from private repos #20432
• image pull secrets - DWO supports image pull secrets on the workspace service account, but not externally defined. Update: Attach dockercfg secrets as pull image secret devfile/devworkspace-operator#284
• security context - DWO hardcodes this, che-server supports setting custom run-as and fs-group globally for all workspaces of all users Users should be able to configure their workspace pods securityContext capabilities #20459
• service account - DWO defines per-workspace service account with a hardcoded name, che-server supports setting a custom service account for all workspaces
• SSH keys - I remember we discussed this but could not find it in my quick search through the issues.
  • Use git binary for fetch to make ssh easier devfile/devworkspace-operator#492
  • Include ssh keys and tls certs into gitconfig devfile/devworkspace-operator#613
• pod tolerations - not supported by DWO, configured globally for all workspaces by che-server
• node selector - not supported by DWO, configured globally for all workspaces by che-server
• termination grace period - DWO hardcodes to 1s, configured globally for all workspaces by che-server

[metlos]

I've updated #20168 with the list of issues for the above findings and the MVP has been merged into the che-operator, so I'm closing this MVP and planning issue.