[workspace-dev] Deny attaching to existing connected exec

Describe the bug

It’s possible to get exec access with che-machine-exec for every authenticated user. It’s needed to deny attaching to existing connected exec.

We could use SubjectAccessReview from OpenShift OAuth Proxy but I’ve checked and kube:admin is still able to attach since it has exec rights for everything, Angel wonder if we could add validating webhooks for SAR as well to correctly handle them in case of exec into workspace-relateds pods And since we use Deployment - pod name is generated, so seems we need to create pods manually or find another pod manager which does not generate pod name

--openshift-sar={"namespace":"dev-ws","name":"workspace4ea4bcd0cc634fcb.workspace","resource":"pods/exec","verb":"create"}

As an alternative, we could contribute into OpenShift OAuth an ability to configure authentication userID, the same way they have authentication-emails https://github.com/openshift/oauth-proxy#command-line-options

Steps to reproduce

1. Create a cloud-shell workspace
2. Modify che-machine-exec image to the following sleshchenko/che-machine-exec:hack. See the sources code used to build it https://github.com/sleshchenko/che-machine-exec/blob/hackTheSystem/cloud-shell/src/index.ts#L70
3. Rescale Workspace deployment
4. Open cloud shell as creator
5. Open Cloud-Shell as kube:admin

Expected behavior

Kubeadmin is not able to open CloudShell created by developer.

Actual behavior

[sleshchenko]

Restricting access by user id on OpenShift OAuth Proxy side is a bit secure in terms of - nobody will get another user token. In case of checking user info on plugin/editor side - user’s token might be stolen, but of sure to make it possible attacked person should open foreign workspace URL and authorize OpenShift OAuth Proxy there. So, POC with checking user id on OpenShift OAuth Proxy:

# from the operator repo
export IMG=sleshchenko/che-workspace-controller:restrict-by-uid
export WEBHOOK_ENABLED=true
export DEFAULT_ROUTING=openshift-oauth
# manual action: update configmap to have e.g. `ingress.global.domain: apps-crc.testing`
make deploy

OpenShift OAuth Proxy changes https://github.com/openshift/oauth-proxy/compare/master...sleshchenko:authenticated-uids?expand=1 Che Workspace Controller Changes: https://github.com/che-incubator/che-workspace-operator/compare/master...sleshchenko:authenticated-uids?expand=1. Note: take a look only two latest commits since this diff also contains embedded registry and oauth client per workspace changes.

[sleshchenko]

This issue becomes more critical again)

From the latest plan - we’re not going to use OpenShift OAuth Proxy, but instead OpenShift Console will call che-machine-exec through OpenShift Console Proxy. So, instead of inventing an additional proxy on Workspace Layer it’s easier to start with making che-machine-exec checking that WorkspaceOwner is requesting if USE_BEARER_TOKEN is configured