Add a wsmaster property to specify workspaces default security context

[l0rd]

Is your enhancement related to a problem?

Currently workspace containers are run as unprivileged arbitrary users (uid is a random number of multiple digits). That has some benefits from a security point of view and works well on secured Kubernetes clusters. But some users may come with containers that only work when run as root on an unsecured cluster. See #14330

Describe the solution you'd like

Add a wsmaster property that specify the default workspace pods SecurityContext runAsUser attribute (default)

c.f.
https://kubernetes.io/docs/tasks/configure-pod-container/security-context/#set-the-security-context-for-a-container
https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.16/#securitycontext-v1-core

[l0rd]

I have raised this issue as P1 because there are use cases where Che worksapces are not usable at all if we enforce hard security constraints as running pods as arbitrary users.

[kfox1111]

Not sure this is the right issue to file this under or not. Please let me know if it is a different issue. I'd like to specify user uid's in keycloak identity tokens, and then have che workspaces run under the user's uid. This would allow extra mounts like existing nfs home directories to be made safely available to che users when integrated with keycloak/ldap.

[che-bot]

Issues go stale after 180 days of inactivity. lifecycle/stale issues rot after an additional 7 days of inactivity and eventually close.

Mark the issue as fresh with /remove-lifecycle stale in a new comment.

If this issue is safe to close now please do so.

Moderators: Add lifecycle/frozen label to avoid stale mode.