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

Using authentication to access dashboard / IDE #690

Closed
thejaay opened this Issue Mar 11, 2016 · 18 comments

Comments

Projects
None yet
7 participants
@thejaay

thejaay commented Mar 11, 2016

I was wondering if it is possible to use some sort of authentication before accessing the Che dashboard or a Che IDE.
I'm not very familiar with Tomcat either so maybe it is possible to use htaccess protection (or the equivalent for Tomcat server), but I'm quite surprised that Che didn't provide an authentication mechanism, is there any future plan to add this feature?

PS : I need to protect the dashboard from people using the workspaces (and protect workspaces for each user)

@sjjones85

This comment has been minimized.

sjjones85 commented Mar 12, 2016

I believe (and I hope to be corrected if wrong) from what my Googling produced, that this is something being considered.

I concur that this a potentially big issue given you can access any workspace IDE, fire up a terminal within the IDE and be able to potentially run something like rm -rf / --no-preserve-root

As you can guess, this will cause issues for sure. Obviously, running the workspaces in Docker containers provides substantial damage control fortunately.

@TylerJewell

This comment has been minimized.

Contributor

TylerJewell commented Mar 12, 2016

@thejaay What we ask deployments to do right now is to consider deploying a Che farm behind an nginx router. You can then have each user routed to a dedicated instance. There are engineers from Orange, SAP, and someone from China working on this.

The other approach is that you can avoid using the dashboard and write your own client that controls access to the REST APIs, and manages the workspace generation process for each user. In this case, users would not be aware of other workspaces running on the same server, but you are into writing your own client.

Codenvy is a full multi-user, multi-account, multi-tenant implementation of the Che APIs. It has built in authentication mechanism into it. And Codenvy is free (with source code) under fair source 5 licensing.

Ok - so why did we do the architecture this way initially. The initial concern was around system complexity. Today, Che doesn't ship with any embedded database. It uses the file system to store all of its system configuration. Che actually has authentication APIs inside of it, just implemented with the universal identity. So there is a way to extend Che to support a different kind of authentication, but then we'd need a user database that shipped within the system.

No one from Codenvy is opposed to taking some of our proprietary multi-user capabilities to add it into the Che core base. But the project leaders have been struggling with how to keep Che's overall architecture simple while providing this.

@sjjones85 - you are correct in that the docker containers provide great isolation. But since all of the workspaces are advertised in the same dashboard, any user could conceivably gain access to any workspace container, and then repeat the same risk factor there. This is why a che farm with multiple VMs is safest approach right now.

@sjjones85

This comment has been minimized.

sjjones85 commented Mar 12, 2016

@TylerJewell thanks for the detailed response, I was discussing this with colleagues earlier today and you've confirmed everything we thought too. Indeed, we absolutely agree the multiple VM and Docker approach is the safest option.

@thejaay

This comment has been minimized.

thejaay commented Mar 14, 2016

@TylerJewell OK I understand why you didn't include auth access in the first place but instead of using database and manage user right inside Che core, can't we use the workspace agent to grant SSH access (set a default password that can be updated later). This will block workspace to connect to the docker machine obtaining a first protection level.

@TylerJewell

This comment has been minimized.

Contributor

TylerJewell commented Mar 15, 2016

@thejaay That is an interesting concept.

At Codenvy, about 3 months ago we started a team of three engineers that began looking into a few different concepts. 1) The ability to have a permissions model for users related to core use cases around workspace management, user invites, and workspace runtime access. 2) Security model around workspace runtimes, particularly around ensuring that a workspace-level security permission would then propagate down to various runtimes that are included within the workspace. 3) And then how all of this would work in a distributed fashion if the workspace runtimes are running on different nodes.

So we are already building into Che a permissions and role-based access model.

As for your particular suggestion, I think it would only offer a partial solution. We could inject such a service into the agent itself, but the agent isn't the only thing running on the workspace runtime. We also run the terminal service on the workspace. So if we locked down the agent, it would still be possible for a user to get the workspace IP address and then directly access the terminal on its terminal port. You can actually take that terminal and run it in another tab today if you wanted. I suppose in your particular scenario, this is an acceptable risk as most users would not be sophisticated enough to figure out how to navigate around the SSH limitation imposed by the agent.

But our current thinking is that role, identity, and security is a distributed issue that has to be enforced within a router that is running in front of the Che workspaces. Within Codenvy, we have a central database with users and roles, and then all traffic to / from those workspaces can be routed through it. Also, when workspaces are being created by Codenvy, we'll query the user database and then inject the permission and security restrictions into the workspace, agents, and runtimes - locking down all components of the workspace according to the identity rules that have been centrally established, regardless of where the containers are running.

I wrote a lot here so that we can let others in the community help to develop this idea. I think your thoughts on a simple SSH restriction is interesting. Maybe there is a way for a user to write a custom workspace dockerfile that enforces this, and then within the UI there is a simple user / pwd form ask from a user each time the workspace is started.

@ArthurHlt

This comment has been minimized.

ArthurHlt commented Mar 18, 2016

@TylerJewell What about use an oauth2 server which manage users ? Like this we can check user permission on the workspace, of course you will need a standalone oauth2 server which is able to register which user have permission on a workspace.

As a contributor on CloudFoundry we have something which can really suits the usecase. It's called UAA (User Account and Authentication), it's the authentication service used in CloudFoundry but it is untied to CloudFoundry and can be used as a standalone oauth2 server.

This service seems to cover the usecase for che, CloudFoundry have similarity concepts as codenvy have (be multi-tenancy and multi-user).
You can create zones (this is the multi-tenant concept on UAA), create groups of users and of course simply create users.
For the database problem, you can use the groups concept to create a group matching the workspace name and add user in this group and check if the user have access right on this group.
All the permission check can be made with UAA's API, it is easily usable with spring oauth2 client implementation and it's also written in Java which make things easier for che's team.

What I see about this, like it's work as a standalone server you're not oblige to tied che to this, you can just add properties to plug che on it if ops want to use this system.

I will be happy to contribute on this with your team.

@TylerJewell

This comment has been minimized.

Contributor

TylerJewell commented Mar 18, 2016

I like this concept. Makes me wonder why we chose not to implement it that way for Codenvy. We are about two weeks away from the 4.0 GA release of Codenvy, based upon Eclipse Che - so for Eclipse Che, that would be considered beta-stable. We'll leave the beta tag on Che for a year or so, to really prove that we are confident in branding, installation, stability.

But Codenvy is working on a major security cycle for our own products, and there are a couple dozen security-related items that we will issue as pull requests for Che. Things related to roles & permissions, resource access controls, and the so forth.

One of the things I have been eager to do is to consolidate the Che dashboard (what manages workspaces) with Codenvy's odyssey, which is just another web app that controls login, password recovery, and self-service account creation. It has oAuth 2 clients for MSFT, GitHub, and Google built-in. So, in theory if there was an oAuth 2 server available, you could configure Che to use that.

What I need to understand better is why we cannot just apply those restrictions to the workspaces themselves. I think I had asked about this 6 months or so ago and got back an answer that was vaguely related to needing to do some major open heart surgery on Che to support properly. But our engineers tend to be so security conscious that when they provide security, it leaves no oxygen in the air for any remaining attack vector. In other words, maybe a bit overkill!

@TylerJewell

This comment has been minimized.

Contributor

TylerJewell commented Mar 18, 2016

Actually, @ArthurHlt in thinking this through, I believe that the answer will be how we lock down the user with the oAuth token on the workspace itself.

There are multiple attack vectors:

  1. The workspace agent APIs running on the workspace. Can be locked with tokens.
  2. The terminal web app, which is operating as its own service on a port.
  3. The sshd that is exposed within the container, which either has hard coded user name / pass or a way for a user to upload their user keys.
  4. The projects, which are mounted into the workspace, inheriting the read / write permissions of the Che server itself.

If we only wanted to restrict the ability to open the IDE with a certain workspace open to provide a thin layer of security, then this would be easy to do with oAuth. Each user would have a unique set of workspaces in their dashboard, and these are the only ones they can gain access to.

But if other users could determine the IP and port numbers of the workspaces, then there is likely a simple way that they could gain access to such workspaces.

And I think in solving these sorts of problems, we started to figure out why Codenvy needed a Go router in the implementation where we handle interceptions of requests to either append the appropriate token, or to enforce certain security elements.

@ArthurHlt

This comment has been minimized.

ArthurHlt commented Mar 21, 2016

@TylerJewell I thought about these problems:

  1. Yes sure this one is the easiest to secure
  2. I get that is a websocket server and user connect to this websocket to do ssh, what we can do is to pass the token to the websocket server and this server operate to the server oauth to see if user has right
  3. A small workaround that @eivantsov gave me is to generate a random password in the dockerfile
  4. Hum after had a problem with that it seems to inherit from the user set on the workspace folder, so you only require these folders to be owned by the user with UID 1000. But I don't see the security issue here

We also wanted to use gorouter but not for this, we wanted to use it to expose port in 32xxx for the docker server over 80 and 443. Did you have to update the gorouter to do this ? Cause I think that gorouter is not made to intercept request and append data in the request. The solution with gorouter seems nice.

@TylerJewell

This comment has been minimized.

Contributor

TylerJewell commented Mar 22, 2016

We've discussed this with the project team, and it's our conclusion that the only way to support this properly is to do a number of things:

  1. Move all of the related Codenvy APIs for user mgmt, authentication, and permissions into Che.
  2. Provide default implementations for those APIs that work within Che.
  3. Add in a user permission and management facility into the user dashboard.
  4. Merge the authentication dashboard (we call odyssey) with the user dashboard into a single web application.
  5. Enable registration of oAuth servers.
  6. Provide an embedded relationship database within Che that manages users.

The default implementation of our permission stack would need to provide basic multi-user support to workspaces. We have a lot of technology that enables this.

It will probably take us a couple quarters to be in a position where we can package this all together.

We kept looking or a simpler way to activate some basic security, but it all comes back to che needing a multi-user database embedded within the system. Once that was there, then all of the other API mechanisms must be there, and then it was just a cascading of other requirements we need to fulfill.

@thejaay

This comment has been minimized.

thejaay commented Mar 22, 2016

Every ideas here seems pretty exciting, I'm agree that oAuth could provide a great addition to Che to manage users and provide access (and so security to user). I'm convinced that Che need something way simpler, why not adding a file in Che that manage user permissions (tomcat-user.xml like) and manage access to IDE trought HTTP basic authentication within websocket

@poblin-orange

This comment has been minimized.

poblin-orange commented Mar 22, 2016

@TylerJewell This will be a very important contribution to the community 👍
Does your solution leverage Spring Oauth ?
Pluggable user management / authorization backend like UAA, as suggest by @ArthurHlt , would be nice

@thejaay Im not so sure about a basic tomcat level security. Decoupling che from identity management seems the way to go.
Moreover, basic auth is not really secure, if not coupled with https. So i think any deployment would front che with some nginx / or load balancer RP.
One intermediate first step for a deployment could be Oauth2 RP front-proxy in this layer, see for instance https://github.com/bitly/oauth2_proxy could provide front oauth2 interception. Also available as docker image, for out of the box experience.

@TylerJewell

This comment has been minimized.

Contributor

TylerJewell commented Mar 22, 2016

We do not use Spring oAuth. We have our own oAuth implementation that has been tested against Microsoft, Google, BitBucket and GitHub.

@TylerJewell

This comment has been minimized.

Contributor

TylerJewell commented Aug 28, 2016

With the launch of the Bitnami installers and Codenvy - those are the preferred paths for getting authenticated access to Che workspaces now.

@shadowcodex

This comment has been minimized.

shadowcodex commented Aug 30, 2016

@TylerJewell

This comment has been minimized.

Contributor

TylerJewell commented Aug 30, 2016

You can also consider Codenvy: docs.codenvy.com, which can be installed on its own.

@pavanagrawal123

This comment has been minimized.

pavanagrawal123 commented Nov 20, 2016

Hello.

To be clear: has authentication support in Eclipse Che been scraped, or is it possible in future releases?

Thanks.

@TylerJewell

This comment has been minimized.

Contributor

TylerJewell commented Nov 20, 2016

There are no plans for it, unless a community member makes a contribution. We provide it in Codenvy and it's quite complicated because of the distributed nature of the services and a large surface area of permissions enforcement.

We have a license for up to 3 users for free with Codenvy, so for now that is the best way to get authentication.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment