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
🐛 Bug Report: ambiguously-named clusters cannot be targeted with the proxy endpoint #15901
Comments
@mclarke47 for visibility. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
@jamieklassen is this still something you're interested in? |
Personally i think tackling the much larger acceptance of ambiguisly-named clusters might be the right thing to address here but I took a look at the proxy endpoint and if all we are looking to do is to ensure that the proxy is tackling the right cluster for the case where we have multiple clusters that share the same name, we could also make it so we not only find()using the clusterName but also using the already available cluster url in the clusterDetails. Will take a look to see if this approach is one that can resolve this bug. It might be the case that the url isn't a unique identifier but that doesn't appear to be a likely case to me. it also appears like that would expect our request to include a cluster server url which doesn't seem to be very user freindly. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
📜 Description
If two clusters located by Backstage have the same name, proxy requests targeting that name will always be routed to the first one -- there's no way to target the second one! You can test this by
curl
ing the proxy endpoint for all namespaces, specifying the ambiguous cluster name, and providing a bearer token that is only valid for the second cluster.👍 Expected behavior
Well, depends on what you know. If you're only aware of the second cluster you might expect to see namespaces. If you know there are two ambiguously-named clusters, you might expect to see an error about this.
👎 Actual Behavior with Screenshots
console prints
This indicates that only the first cluster got queried -- since the token we used isn't valid for that cluster.
👟 Reproduction steps
kind create cluster --name kind-1 && kind create cluster --name kind-2
yarn start-backend
📃 Provide the context for the Bug.
Cause
We already know that this bug is caused by the
find()
call here:backstage/plugins/kubernetes-backend/src/service/KubernetesProxy.ts
Lines 121 to 123 in 38c3232
According to the MDN docs:
and this is why it is always the first cluster with the given name that gets targeted.
Background
In October 2022, in my big "Let's just do single-cluster" comment, I suggested
Unfortunately we didn't implement that requirement, and I'm just now filing part of the relevant issue! The rest of the issue should take the form of an RFC about unique identifiers for Kubernetes clusters generally.
🖥️ Your Environment
If you really wanna know, I'm running MacOS Ventura 13.1 on a 2019 16-inch Macbook Pro, and I just completed the reproduction steps with the code on master at the time of writing:
👀 Have you spent some time to check if this bug has been raised before?
🏢 Have you read the Code of Conduct?
Are you willing to submit PR?
Yes I am willing to submit a PR!
The text was updated successfully, but these errors were encountered: