Che: Eclipse Che restrict access to certain functions

Created on 21 Jun 2018  路  4Comments  路  Source: eclipse/che

Hi all,

Firstly I have to say, Eclipse Che is an excellent piece of software and thank you to all for producing this.

I have a question and hope this is the correct place to raise this.

I am attempting to introduce Eclipse Che in an education environment and as such need to impose certain restrictions on it which I cant seem to get quite right.
Hopefully you can point me in the right direction.

I have Che multi user running (based on 6.6.1 as-of-writing) and connected to a directory service working fine.
I have a workflow that automatically creates an 'organisation' and subsequently a 'workspace' for each user based on LDAP group membership.
So each user gets their own organisation with a 1 workspace limit and gets a workspace created with run/use rights. They cannot remove the workspace and cannot create any more in the organisation.

This all works fine.

The issue is then I need to prevent users from the following actions:

  • Disable creating 'factories'
  • Disable adding custom 'registries'
  • Disable adding new 'stacks'
  • Disable creating workspaces (Note, with an organisation setup the web UI doesn't allow the user to create workspaces outside of this, which is good. But they can still create a workspace outside of the organisation using the API)

By default any user who can login to Che appears to be able to do all of the above things without restriction.
I can control who can login using some LDAP groups (which works fine), I just don't know how to prevent access to the above functions.

I cant seem to figure out how to do this with the permission API, I can only set permissions on existing objects with that?

I appreciate this may not be a normal use case, but this type of environment has to be controlled to ensure learning objectives can be achieved without distractions.

I'm an admin and not a developer so please use small words!

Thanks

kinquestion

All 4 comments

@donenocode I'll try to use the smallest words I have :)

First off, thanks for the nice words about Che! Appreciate it!

As to your request, can you elaborate on the motivation behind such restrictions? If it's just about to control resource consumption, just creating a factory, stacks or a registry does not cost anything to you. It is possible to set caps for orgs on the amount of RAM consumed by one or all running workspaces.

Yes, a user can create a Factory and share it. However, event if Factories are somehow disabled, a user is still capable of copying a ws config and share it - this will produce the same result. Factories are workspace templates.

Creating a new stack is just about a new entry in a db. A stack is a workspace template too.

I don't see any ways to disable Factories and Stacks.. Those are REST API services deployed with workspace master.

And you CAN disable creating workspace outside of an org - https://github.com/eclipse/che/blob/master/dockerfiles/init/manifests/che.env#L613

You can allow 1 workspace for a user in an org and 0 outside it. So, no personal workspaces (I haven't tested it though but chances are I am not lying :) )

Thanks for quick the response.

I will look into the link you have provided regarding disabling workspace creation outside of an org.
I already have a resource restriction working inside the org's so if a user cannot create outside of the org then this is fine.

On the subject of factories, it appears I have shown my lack of understanding of what a 'factory' is. I have no issue with users sharing workstation templates. It was just when I tried to create a factory it started a workspace and that concerned me a little as to what can be done with that.

On the subject of stacks, If a user cannot create a workspace outside of an org. then the issue of creating custom stacks is also not a problem as they wouldn't be able to use any custom setup they created via the UI.
The only other concern about being able to create a stack is the ability for the users to be 'silly' with the names for instance, maybe creating a stack with a name that other users can see but isn't appropriate for the environment. This is a cosmetic thing thing though really and likely wont happen and therefore not a big concern anymore.
I could add something to our automation tools that looks for these issues and removes them I guess.

The overall motivation is to try and get ahead of any way these users may try to miss-use the system.
For instance by using 'silly' names for stacks that others can see or by adding a custom registry and starting a Minecraft server or something. I know they could probably just run it inside of the workspace but if its difficult enough then most give up!
I want to at least try and remove as many ways the system may be miss-used!

Thanks again for you help, very much appreciated.

@donenocode

If a user creates a stack it's only him who can see it unless he figures out what APIs to trigger to share it with other users.

As an admin you can delete all out of the box stacks, add just one or two stacks and make them available for all users.

Once again thanks for you assistance.
I have tried your recommendation and this along with your other advice gives me what I need.

This now does exactly what I need, users cannot create workspaces outside of their organisation(s).

Thanks.

Was this page helpful?
0 / 5 - 0 ratings