Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use the user's roles for Kubernetes roles in Che workspaces #13795

Closed
johnmcollier opened this issue Jul 8, 2019 · 3 comments
Closed

Use the user's roles for Kubernetes roles in Che workspaces #13795

johnmcollier opened this issue Jul 8, 2019 · 3 comments
Labels
kind/enhancement A feature request - must adhere to the feature request template. lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. severity/P2 Has a minor but important impact to the usage or development of the system.

Comments

@johnmcollier
Copy link
Contributor

johnmcollier commented Jul 8, 2019

Description

I'm from the Eclipse Codewind project, and we have a plugin for its integration with Che (https://github.com/eclipse/codewind-che-plugin). On Che, Codewind allows users to create Kubernetes deployments and services for their application. However, the default roles given to the Che workspace aren't enough for that, and we currently tell users to set cheWorkspaceClusterRole (https://github.com/eclipse/che-operator/blob/master/deploy/crds/org_v1_che_cr.yaml#L28) when installing Che, so that Codewind can function properly.

It'd be nice if we had a way for workspaces (maybe via the devfile?), to specify and link to a Kubernetes role that can be used for the workspace. Then, when the workspace was created, a role binding would be created linking to that cluster role. That way, workspaces that require increased cluster roles (such as Codewind), could then be created from a default installation of Che, without additional work needed by the user.

I suppose if this was done, we'd also want something in the UI to tell the user that the workspace they're creating requires hightened roles.

@l0rd l0rd added this to the 7.x milestone Jul 8, 2019
@l0rd
Copy link
Contributor

l0rd commented Jul 8, 2019

@johnmcollier I think it may be related to this issue #13488

In other words the best way to solve this problem is to use the current user privileges instead of an hardcoded role that it's set as a che-server property. If we let user define their role in a devfile it would result in a privilege escalation.

@l0rd l0rd added severity/P2 Has a minor but important impact to the usage or development of the system. kind/enhancement A feature request - must adhere to the feature request template. labels Jul 8, 2019
@johnmcollier
Copy link
Contributor Author

johnmcollier commented Jul 8, 2019

@l0rd That's a good point. I'm good with using the current user's privileges, instead of some arbitrary role that users (or plugins) define.

@johnmcollier johnmcollier changed the title Add way for Devfiles/workspaces to specify a Kubernetes role for the workspace Use the user's roles for Kubernetes roles in Che workspaces Jul 31, 2019
@che-bot
Copy link
Contributor

che-bot commented Jan 27, 2020

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.

@che-bot che-bot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Jan 27, 2020
@che-bot che-bot closed this as completed Feb 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/enhancement A feature request - must adhere to the feature request template. lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. severity/P2 Has a minor but important impact to the usage or development of the system.
Projects
None yet
Development

No branches or pull requests

3 participants