secure:true is not securing endpoints with jwt proxy anymore

guydog28 commented 8 months ago

Describe the bug

I have recently deployed 7.76 with a devfile 2.x.

Everything works fine, except it seems that secure:true has no effect in endpoints, as there is no jwt-proxy securing my endpoints from public access.

Che version

7.75@latest

Steps to reproduce

Install Che (Vanilla Kubernetes)
Create a devfile with an endpoint and secure:true
Verify no jwt proxy in the pod
Verify endpoint can be hit in another browser where you are not logged in to che.

Expected behavior

Going to the endpoint in another browser where the user is not logged in should not work.

Runtime

Kubernetes (vanilla)

Screenshots

No response

Installation method

OperatorHub

Environment

Linux, Amazon

Eclipse Che Logs

No response

Additional context

No response

tolusha commented 8 months ago

/cc @amisevsk

amisevsk commented 8 months ago

I believe this is a change in the Che Operator -- we no longer use JWTs to secure workspace endpoints, and instead have the urlRewriteSupported attribute. This was changed as part of https://github.com/eclipse/che/issues/12914 (IIRC).

If an endpoint has urlRewriteSupported: true, then it should be served through the main Che gateway and be secured behind auth. However, endpoints without this attribute are served over plain ingresses/routes at the moment.

guydog28 commented 8 months ago

@amisevsk That makes sense as to another way to secure, but that breaks a lot of the containers in the workspace that can't be nested under paths and require to be at the root of the url.

guydog28 commented 8 months ago

Is there some other way to secure these endpoints?

amisevsk commented 8 months ago

Currently, no -- cc: @l0rd: do we want to prioritize this?

l0rd commented 8 months ago

@amisevsk That makes sense as to another way to secure, but that breaks a lot of the containers in the workspace that can't be nested under paths and require to be at the root of the url.

Supporting the scenario with secure:true and urlRewriteSupported: false is complicated and introduces problems with untrusted certificates or wildcard certificates that we had in the past so we need to be sure that there is a real and urgent need.

@guydog28 can you please provide an example? Usually on workspaces public endpoints developers expose the web app that they are debugging: this is short lived and adding authentication is overkill. In the rare cases that I was aware of the authentication required, the app was also supporting URL rewrite. So I am curious to learn more about your use case and why you cannot just set the endpoint as internal.

On the other end, I think that we should support secure: true in the devfile:

if secure: true we should behave as if urlRewriteSupported: true. When the developer has also explicitly specified the attribute urlRewriteSupported: false we should warn the user that "When an endpoint has secure: true, URL rewrite is mandatory." and that the attribute will be reverted (the warning should happen in the dashboard at workspace startup).

amisevsk commented 8 months ago

I've created https://github.com/eclipse/che/issues/22676 for the relatively easy part (treat secure: true as urlRewriteSupported: true)

guydog28 commented 8 months ago

@amisevsk I think the main concern is for private or proprietary projects, where a team would not want a non-logged user (or web-scraper) to have access to the endpoint. The Che instance is publicly accessible, but the test versions of the applications being written in it maybe should not be. And they don't function as subpaths.

che-bot commented 2 months ago

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.

eclipse-che / che