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

Make a unique nonce as optional check in jwtproxy #10090

Closed
sleshchenko opened this issue Jun 18, 2018 · 1 comment
Closed

Make a unique nonce as optional check in jwtproxy #10090

sleshchenko opened this issue Jun 18, 2018 · 1 comment
Assignees
Labels
kind/enhancement A feature request - must adhere to the feature request template. status/open-for-dev An issue has had its specification reviewed and confirmed. Waiting for an engineer to take it.

Comments

@sleshchenko
Copy link
Member

Description

There is a plan to secure tooling servers with authentication that are done by coreos/jwtproxy. But there is a thing that prevents us to use it: a requirement to use a unique nonce for each request.
While the main client of tooling servers is IDE in a browser, where is no a way to generate a token, because it is not secure to provide a client with a private key. So, we are not able to provide new token from server side for each client's request. It is why do we need to disable this check.

It is planned to create a fork and make these changes there, build custom image and use it.
For the same time, create a PR to coreos/jwtproxy and when it will be merged just configure it and use default jwtproxy image

OS and version:

Diagnostics:

@sleshchenko sleshchenko added kind/enhancement A feature request - must adhere to the feature request template. status/open-for-dev An issue has had its specification reviewed and confirmed. Waiting for an engineer to take it. team/platform labels Jun 18, 2018
@mshaposhnik mshaposhnik self-assigned this Jul 12, 2018
@mshaposhnik
Copy link
Contributor

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. status/open-for-dev An issue has had its specification reviewed and confirmed. Waiting for an engineer to take it.
Projects
None yet
Development

No branches or pull requests

3 participants