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

Machine tokens become invalid when workspaces are recovered #7785

Closed
sleshchenko opened this issue Dec 8, 2017 · 3 comments
Closed

Machine tokens become invalid when workspaces are recovered #7785

sleshchenko opened this issue Dec 8, 2017 · 3 comments
Assignees
Labels
kind/enhancement A feature request - must adhere to the feature request template.

Comments

@sleshchenko
Copy link
Member

sleshchenko commented Dec 8, 2017

Description

Now machine tokens are stored in memory by workspace server. So after restarting of a workspace server, all machines token become invalid so workspace agent has no ability to request workspace server.
It is needed to investigate how is issue can be solved.
Possible solutions:

  • there should be a mechanism to provide a new valid token to recovered workspaces;
  • workspace server should persist machine tokens somehow not in memory not to lose them after restarting;
  • declare current MACHINE_TOKEN env var as something like INIT_MACHINE_TOKEN, rework AgentHttpJsonRequestFactory to use the token of the current subject instead of initing machine token, generate new machine token after workspace recovering.

The third one is preferable.

It is also required to rework a bit generating of machine tokens to make it while token requesting instead of interception of workspace start method.

@sleshchenko sleshchenko added kind/enhancement A feature request - must adhere to the feature request template. status/analyzing An issue has been proposed and it is currently being analyzed for effort and implementation approach target/che6 labels Dec 8, 2017
@sleshchenko sleshchenko added status/open-for-dev An issue has had its specification reviewed and confirmed. Waiting for an engineer to take it. and removed status/analyzing An issue has been proposed and it is currently being analyzed for effort and implementation approach labels Dec 13, 2017
@akorneta akorneta self-assigned this Dec 25, 2017
@akorneta akorneta added status/in-progress This issue has been taken by an engineer and is under active development. and removed status/open-for-dev An issue has had its specification reviewed and confirmed. Waiting for an engineer to take it. labels Dec 25, 2017
@akorneta
Copy link
Contributor

akorneta commented Dec 25, 2017

The third solution looks good, but in this case, it is not fully clear what to do with the bootstrapper which takes a machine token from an environment and use it to publish logs. So we need to figure out possible ways, how to put bootstrapper a valid token.

@akorneta
Copy link
Contributor

akorneta commented Dec 26, 2017

The goal that we are trying to achieve is to be able to provide a stateless mechanism of interaction between Che master and workspaces, so it means that we need to rework existing codebase related to machine authentication, managing of machine tokens.
One of the possible options is a replacement of machine token (that is stored on a Che master side in runtime storage) to JWT token which would be signed on master and placed with a public part in an environment of the workspace.
In this way, we avoid +1 request for token verification on machine side and we also don't need any storage for the tokens on Che master side. When new key pair generated all the workspaces must be restarted(this also may be discussed and proposed solutions welcome).

@akorneta
Copy link
Contributor

akorneta commented Jan 3, 2018

Draft with JWT tokens that are used for authentication between workspace agents and Che master.

@akorneta akorneta added status/open-for-dev An issue has had its specification reviewed and confirmed. Waiting for an engineer to take it. and removed status/in-progress This issue has been taken by an engineer and is under active development. labels Jan 3, 2018
@gorkem gorkem mentioned this issue Feb 12, 2018
19 tasks
@akorneta akorneta added status/in-progress This issue has been taken by an engineer and is under active development. and removed status/open-for-dev An issue has had its specification reviewed and confirmed. Waiting for an engineer to take it. labels Feb 26, 2018
@akorneta akorneta removed the status/in-progress This issue has been taken by an engineer and is under active development. label Mar 12, 2018
@akorneta akorneta added the status/code-review This issue has a pull request posted for it and is awaiting code review completion by the community. label Mar 26, 2018
@akorneta akorneta removed the status/code-review This issue has a pull request posted for it and is awaiting code review completion by the community. label Apr 11, 2018
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.
Projects
None yet
Development

No branches or pull requests

3 participants