-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
Enable to switch context in kubeconfig #4534
Conversation
5b2f979
to
4741a80
Compare
Codecov Report
@@ Coverage Diff @@
## master #4534 +/- ##
==========================================
- Coverage 45.45% 44.96% -0.50%
==========================================
Files 214 216 +2
Lines 10208 10449 +241
Branches 108 131 +23
==========================================
+ Hits 4640 4698 +58
- Misses 5293 5471 +178
- Partials 275 280 +5
Continue to review full report at Codecov.
|
4741a80
to
b07b973
Compare
b07b973
to
29815b0
Compare
29815b0
to
7f9b7c6
Compare
We will go back to this after the release, please ping if I will forget. |
7f9b7c6
to
014b742
Compare
const clusters = conf.clusters.filter(cluster => { | ||
return cluster.name === name; | ||
}); | ||
if (!clusters.length) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please use !_.isEmpty()
to check for clusters list emptiness. This is lodash utility function that can be imported with following line import * as _ from 'lodash';
.
return ctx.name === context; | ||
}) | ||
) { | ||
conf['current-context'] = context; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As before, on known types please use dot to access object params.
apiVersion: string; | ||
clusters: Cluster[]; | ||
contexts: Context[]; | ||
'current-context': string; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is no need to escape it. Can we change it to camelCase?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I found that js-yaml
can not convert keys to camelcase. Instead I found a library camelcase-keys
but it need to use require
in import
. Do you know better library or is it acceptable, i.e. using require
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can use require.
@floreks What do you think about the usability and approach here? I have done initial code review so far but we should also consider if that will not impact our current setup. |
import {KdError} from '@api/frontendapi'; | ||
import {Config, CONFIG_DI_TOKEN} from '../../../index.config'; | ||
|
||
type Cluster = { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Those are backend api types. Move it to the backendapi.ts
.
type User = { | ||
name: string; | ||
user: { | ||
token: string; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can't store token here as it is already part of our login mechanism and is stored in an encrypted cookie. This would be extremely insecure. Also, we do not support client-certificate-data
as a way of logging in anyway, so this is obsolete.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we store all the tokens contained in kubeconfig in cookies, I'm worried that all HTTP requests will get too big and impact performance.
I'm considering to encrypt tokens in jwe and store them into cookie before login sequence. But do you have any other ideas?
I have tested it locally using |
Thank you very much for your reviews! I will continue considering pointed things, check and modify this next week. |
I checked |
I will try to verify again tomorrow but it seemed okay as I was able to login with it. Is some additional info required? |
1dedb12
to
b424ad3
Compare
b424ad3
to
5739487
Compare
@maciaszczykm I improved my codes, but I'm considering about encrypting tokens with jwe and store them into cookie yet. But I'm happy if you try this UX. |
/hold |
When user is logged in with kubeconfig, add selections for contexts included in kubeconfig into user menu and enable to switch contexts included in kubeconfig. This commit implements basic functionalities for switching contexts, so to set dashboard-metrics-scraper host for each `cluster`, you need to describe it as `sidecarHost` in `cluster` directive in kubeconfig. Note: To test this with `npm run start*`, enlarge maximum http header size with `export NODE_OPTIONS=--max-http-header-size=102400`.
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: shu-mutou The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
/hold cancel |
The solution that requires us to raise limits for HTTP header size is not really acceptable. We should try to limit data passed between browser and server as much as possible. Most proxies set their limits to 8KB and many people are using that. This change would break many configurations. Processing all tokens at all times is also not good. Only one should be used at the time and others should naturally expire over time. Another issue is encrypting all auth information to all servers with a single encryption key that is stored in the main cluster. We should not do that. It decreases security and makes all servers vulnerable in case of a single cluster breach. There are a couple of more issues, but I think the general approach should be reconsidered. First, we should have some architectural concepts prepared. Possibly something like that should be handled in the user settings and we should have an option to add additional servers that we want to access. We could store some data in secrets/config maps and use multiple encryption tokens for actual auth info. |
As I expected, the HTTP header size exceeded the limit. |
@shu-mutou: PR needs rebase. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
Closing as stale. New PR can be opened as it requires major changes. |
When user is logging in with kubeconfig that have multiple contexts, add buttons for the contexts into user menu and enable to switch contexts.
This solution assumes that dashboard-metrics-scraper is deployed on each cluster.
To get metrics from dashboard-metrics-scraper in each cluster, add
sidecarHost: [endpoint URL for scraper]
intocluster
in kubeconfig like follow:Endpoints for
server
andsidecarHost
would be passed as cookies and clients for them would be created dynamically in server side.As first step, this implements basic architecture. Config editor and etc. would be implemented in future PR.
Note: To test this with
npm run start*
, enlarge maximum http header size withexport NODE_OPTIONS=--max-http-header-size=102400
.Partial implements #4522