Che: [workspace-dev] Deny attaching to existing connected exec

[sleshchenko]

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

[amisevsk]

In my opinion, applying validating webhooks to subject access reviews (if possible) would be trying to force an auth mechanism to do something it's not designed for.

Probably the cleanest way to do this is to figure out how to get user id authentication into oauth proxy. It's hard to envision a solution that doesn't open a much larger attack surface (e.g. if we add more validating/admission webhooks, etc. and have to maintain integrity between various components).

Do we have an up to date list of the entry points we have to secure?

1. Prevent users from execing into a cloud shell instance unless they're the creator (done via webhooks)
2. Limit public endpoints/ports on pod to only allow creator in (this issue)
3. Limit any changes to any related resources to allow someone to get around 1. or 2.

My concern is that in adding additional elements to support 2, implementing 3 becomes harder. E.g. to restrict exec access into pods (a single webhook), we had to add two more to ensure objects couldn't be modified to get around the first. As a result, I lean towards doing endpoint auth in the deplyoment itself.

[amisevsk]

I played with this a bit today and threw together a quick and dirty proposal. The basic gist is that we delegate user ID checking to machine exec itself using headers passed by oauth proxy. The implementation is very rough and pretty much a minimal working example with no error handling/design, but it works for preventing cluster admins from accessing the cloud-shell endpoints on crc.

For now, the changes add a new annotation on workspaces, org.eclipse.che.workspace/user, since the oauth-proxy only passes user name (ideally we would get user ID and compare that).

• Che machine exec changes: https://github.com/eclipse/che-machine-exec/compare/master...amisevsk:deny-exec
• Che workspace operator changes: https://github.com/JPinkney/che-workspace-operator/compare/deploy-registry-only-if-needed...amisevsk:deny-exec
  
  
  
  • note these changes are built off @JPinkney's branch for PR https://github.com/che-incubator/che-workspace-operator/pull/45 since it makes it really easy to swap out machine exec images
  
  

To test the changes, you can simply deploy image amisevsk/che-workspace-controller:deny-exec:

# from the operator repo
export IMG=amisevsk/che-workspace-controller:deny-exec
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

[sleshchenko]

Created an issue an authenticated-ids in OpenShift OAuth Proxy repo to collect thoughs https://github.com/openshift/oauth-proxy/issues/168

[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]

It does not seem to be as critical as before since we're not sure if we'll use OpenShift OAuth Proxy after implementing better integration with OpenShift Console https://github.com/eclipse/che/issues/16633

[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