Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
feat: add Public-Viewer support #443
feat: add Public-Viewer support #443
Changes from 83 commits
1cfcd94
2c897f6
52156fe
573aecc
fc99e4e
962c87c
ec8b470
8193b55
91ff1aa
6c2a595
ca4b882
7f015b5
941e052
4981f91
76e43eb
a85b104
75fec5c
0d3bfc5
6941c15
9136bb0
7ec2cb4
f362ac5
3b7d1c2
650a6a2
e275514
4e51460
dfa1533
69be0bf
ef8e333
8cf0f7b
29dd7fe
00dd2f4
f9b9b5a
c683c65
f533353
08cb567
43f6c58
3452b2b
ac24de1
4d863bb
2b62f6c
3ccbee7
276323b
8d944fb
f74ee96
d278ea7
6f97b34
7934119
30b980b
51fe1a4
e27d558
96b1646
048f29b
d9299c5
6408242
76ca225
a2bc3f8
1995b76
47ab59e
d4fee9b
e614e38
bd91b58
241fd5a
139809a
a2a9837
b1e93fb
ea515a6
3db6128
b18db56
d5c1503
94e45a0
306b6d6
fd3e191
13d335a
15fa0cd
83ea573
5d0f604
c071225
a3eff03
e09cd75
cf79085
599e2d2
150dbd0
c343167
087b0dc
8ba3452
0ffff03
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
Check warning on line 391 in pkg/proxy/proxy.go
Codecov / codecov/patch
pkg/proxy/proxy.go#L391
Check warning on line 412 in pkg/proxy/proxy.go
Codecov / codecov/patch
pkg/proxy/proxy.go#L412
Check warning on line 428 in pkg/proxy/proxy.go
Codecov / codecov/patch
pkg/proxy/proxy.go#L427-L428
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 really should stop checking if the namespace belongs to the workspace or not. It should be up to the cluster RBAC to manage namespace access. If there is a corresponding SpaceBinding in the namespace then everything will work. It would solve problems when users have permissions to some special namespaces in the cluster which are not part of any workspace and managed outside of kubesaw (like special global view-only namespaces for all authenticated users).
We added this additional namespace check as a workaround for the UI bag which we fixed many moons ago.
This is not related to this PR though. And let's address this in a separate PR. Just wanted to mention it here.
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.
IIUIC, if we remove this check we could enable unwanted cross-workspace requests for workspaces living in the same cluster.
Consider the scenario in which Alice has access to workspaces
alice
- with namespacealice-tenant
- andbob
- with namespacebob-tenant
. Both living in the same cluster.If we remove the check, Alice could explicitly target the workspace
alice
and access the namespacebob-tenant
. Something like.../workspaces/alice/api/v1/namespaces/bob-tenant/pods
. Am I correct?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.
Not really. Our proxy will redirect the requests indeed to the same cluster:
/api/v1/namespaces/bob-tenant/pods
as Alice. But since Alice does not have permissions to access that namespace, kube will reject it.It basically will still fail but on the kube side. Not on the proxy side.
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.
ok, but if Alice has access to
bob-tenant
namespace because Bob gave her access to his workspace, the request will not fail. Right?If this is correct, Alice could set a workspace and perform cross-workspace requests by simply using a namespace from another workspace. The only requirements are:
So Alice can have a kubeconfig with server url set to
https://cluster-domain/workspaces/alice-workspace
and target namespaces from different workspace. To me this is a problem, because as a user I expect my requests to be confined to the workspace I set in the url.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.
This is correct but I still don't see a problem with that. It's not like Alice can hack the proxy and get access to a namespace she doesn't have access to. She just could create a weird workspace/namespace context and use
/workspaces/alice/api/v1/namespaces/bob-tenant/pods
instead of more appropriate/workspaces/bob/api/v1/namespaces/bob-tenant/pods
.This is exactly why we introduced it in the first place. There was a bug in HAC/UI with the workspace switching. The workspace switcher would change the workspace but wouldn't change the namespace. So we hopped that setting such a limit would make it easy to spot bugs/mistakes on the client side (like in HAC): hey, you are using a weird context, make sure you really know what namespace in what workspace you want to access otherwise you could be scratching your head wondering why it gives you weird result.
So it is not a security problem.
However it has significant side effects. We faced multiple cases when users try to access some namespaces which do not belong to any workspace at all! Some global view-only namespaces which should be available to all authenticated users. Some operators like Pipelines, Virtualization and many others use such approach.
With this limitation in place it's impossible to access such non-workspace namespaces through the proxy even if they are totally accessible using the api server directly.
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.
Here is the followup PR: #471