Che: How to enable User Account Control

[DaspawnW]

Is it possible to enable User Account Control in the free version of eclipse che?
And how to enable it. The only endpoints I found was /dashboard, /swagger and /api.
Also the logout button returns a 404 error.

[TylerJewell]

Hi Bjorn:

Thanks for reporting the logout button - it has been filed as a bug and will get a fix shortly.
https://jira.codenvycorp.com/browse/UD-1019. This is an internal tracking issue for Codenvy - will be used until we export internal issues into GitHub.

On your question on user account control in Che. Che (today) when run as a server provides multiple workspaces on a single identity. The Che APIs have a service provider mechanism that allow for extension of the user management, authentication, and identity management with different implementations.

So to get multiple users, you have the following choices:

1. Run a Che farm behind an nginx router. Each user would then get their own Che server, which provides multiple workspaces and isolation. Each Che server has a separate identity where users can configure preferences / workspaces / snapshots to their own specification.
2. Run multiple workspaces on a single server, giving each workspace to a different user. In the default configuration, those multiple users will each share a common identity, but they each have their own workspace.
3. It is possible to override the user management interfaces to provide a different user management implementation that has its own approach to authentication, identity isolation.
4. Or you can consider Codenvy, which is a multi-tenant, multi-user, elastic implementation of Che.

The Codenvy implementation is typically used for very large scale deployments where workspaces are distributed across numerous nodes. We provide free licenses for up to 5 users as well.

It's possible that the community may add a basic auth capability to Che over the coming year. But as Che works its way to GA, the emphasis is primarily around stabilizing the performance and features around the workspace lifecycle. After all,that is really the core. If the workspace isn't very fast & secure, then the product is not viable.

[achabahe]

hi Tyler !! when you say:
"Run multiple workspaces on a single server, giving each workspace to a different user. In the default configuration, those multiple users will each share a common identity, but they each have their own workspace."
you mean all of them will login into the same che server and having the possibility to override each other's work, so you mean there is no account<->workspace link , is that correct!!

[TylerJewell]

Che doesn't have a concept of "login". The Che server has a single identity, so everyone shares that same identity. The user identity is used to store preferences, like editor configuration and SSH keys. So with Che, to enforce multiple users - some people have built nginx or other proxies in front of Che with a lot of complexity, and in some cases others run che farms where each human user is given their own separate Che instance. And others upgrade to Codenvy, which has a multi-user, multi-tenancy implementation of Che.

[achabahe]

so code envy has extended eclipse che in order to support account ant team collaboration management. what about Nginx as a proxy for multi users is there an implementation or some solution that can be integrated with eclipse che to allow this user management, by the way thank you SO MUCH for the answer

[TylerJewell]

There are a few things that are floating out in the wild:
1: Bitnami has implemented a lightweight authentication mechanism for all of the Che-hosted images on Bitnami VMs at various cloud providers.
2: User @wernight has started on a hacked up kubernetes deployment that includes a simple auth in front of the kubernetes cluster. https://github.com/wernight/kubernetes-che
3: There hvae been other users that have been hacking together nginx proxies, and they are somewhere in the archives - search on nginx.

Though, also check in the archives about security. There are many points of attack for Che - so the surface area is quite large. Adding a simple auth proxy in front of che gives the allusion of security, but the workspaces have multiple contianers and agents, which will not be locked down with enforcement of permissions. The reason we haven't implemented this sort of multi-user capability in che is because it requires a distributed architecture to ensure enforcement of permissions across every touch point, and that takes away from che's single server deployment approach.

[achabahe]

i am a bitnami user and i need to confirm if bitnami does not provide a mechanism of collaborative work in the same che server instance , i was able to create a second user and i found that both can read and write in workspace created by the other so it was like creating a second account with no permission management (what i mean by permission management is a user can access only to his workspace), what bottled me is that in bitnami page Bitnami stack for eclispe che they say
'Users can replicate, distribute and share developer workspaces so that they run identically on any machine '
i felt like there is an account management .

[TylerJewell]

Bitnami's implementation is to provide a authentication mechanism so that the workspace server itself is not easily accessible by random outside users. However, for all of the accounts that are created with Bitnami, they are registered in an nginx proxy - they are not "Che accounts". All of the successful authentications are redirected to the same Che instance which has a single user persona.

I think marketing exactly what is happening is challenging. And technically, that statement that you provided from Bitnami is correct - because inside of Che you can clone & share the workspaces. It's not easy to provide short sentences that are accurate without misleading - but I understand your confusion.

[achabahe]

so i think we can have approximately similar behavior if we start multiple eclipse che instances on the same machine and create for each instance its proper user ??

[wernight]

I'd just like to clarify that my implementation is a proxy in front of the
entire Che network, so authenticates and encrypts all communications with
Che, not just the web server, but also the agent etc.

I'm not saying it's a good solution, it's not, but it doesn't have a large
attack surface area (for a single user).

That's is one of the reasons pushing for single HTTP port done by Che (so
Che being a proxy). That and not requiring to expose tons on ports through
the firewall (which can be impossible in some cases).

Le mer. 19 oct. 2016 à 11:05, achabahe [email protected] a écrit :

so i think we can have approximately similar behavior if we start multiple
eclipse che instances on the same machine and create for each instance its
proper user ??

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/eclipse/che/issues/235#issuecomment-254756365, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAI5A4X5DQ39Yk-gVHS1EaX4KyNJYzTPks5q1d1JgaJpZM4HOadB
.

[achabahe]

okey but what is your implementation @wernight is it Bitnami's eclipse che implementation ?? because i have many question if so

[wernight]

It's Eclipse Che directly or actually here on Kubernetes (but can work without). So without Bitnami. See https://github.com/wernight/kubernetes-che

[danbars]

It is possible to override the user management interfaces to provide a different user management implementation that has its own approach to authentication, identity isolation.

@TylerJewell can you please elaborate on this option? We are considering wrapping Che for multi-tenancy service. Is there a documentation of those interfaces?

Thanks

[TylerJewell]

Can you elaborate on what you are trying to do? My company, Codenvy, has spent years working on extensibility mechanisms within Che to create a system that is multi-tenant with user authentication, permissions, security controls, and resource management. We use a combination of:

1. Java dependency injection to add-to or override Che embedded APIs
2. A custom Che assembly which inherits from, but uses the overrides in (1) to activate different API implementations.
3. A series of infrastructure services including nginx, haproxy, postgresql, socat, and some web serving technology to set up a routing mesh to securely handle user management.

Securing Che is tricky as the surface areas of attack are the che server, every workspace, their terminal, eahc of the servers, and their file system. So the only way to lock it down safely is to have tokenization on each of these surface area points, and then to use proxies and reverse proxies to ensure that everyone is authenticated before accessing the right service.

Codenvy itself is extensible in the same way that Che is, and is a Che provider - so that could be a platform that is even faster to get started with, if it made commercial sense for you.

You can see the new codenvy 5 with running "docker run codenvy/cli start".

[danbars]

My company, SafeBreach, develops a platform that executes breach simulations on our customers' networks in order to find holes in the defense. The different breach methods are developed by our research team, and we are now productizing the option for our customers to write their own breach methods.
The platform can be installed on our customers' network as well as in the cloud.
For on-premises solution it looks simple enough as there are multiple users, but all work for the same company.
For cloud solution there is a need for real multi tenancy solution.

I didn't know that Codenvy is also extensible. I'll contact you in private channel to discuss.

Thanks!