-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
kubectl config Error from server (BadRequest) on leaf K8s #3716
Comments
@awly @russjones Do you happen to know if we made any changes in the later versions of 4.2.3+? |
These are the only remotely-relevant changes since 4.2.3:
It would be very useful to get root/leaf proxy debug logs here. And also more specifics on the versions of |
Can confirm I am experiencing the same behavior with tsh
Before when I was using what I think was |
I saw this same issue in testing myself (once). Trying to track it down and reproduce it is what led me to find another bug and open #3693 |
I believe #3735 should resolve this |
Description
Created on behalf of a customer.
What happened:
'm seeing some weird behavior in 4.2.9 with kubctl config but I'm testing with 4.2.3 servers
so I wonder if the versions are not 100% compatible
I do the following:
tsh logout
tsh login sfffff-dev
I can see ~/.kube/config after that and it seems fine, but if I do anything with kubectl I'm getting
Error from server (BadRequest): Unable to list "/v1, Resource=pods": the server rejected our request for an unknown reason (get pods)
orError from server (BadRequest): the server rejected our request for an unknown reason
; The root cluster doesn't show any requests to K8s in logsIf I log in to another cluster after that with
tsh login sfffff-azdev
everything begins work as expected. I can see requests in the logs, I can switch between contextswhen I'm observing the problem I can confirm that the server address is correct in kubeconfig server: https://tproxy.sffff-teleport.aws.reg.RETRACTED.com:3026
The behavior is the same with 4.2.9 servers
What you expected to happen:
How to reproduce it (as minimally and precisely as possible):
Environment
Teleport version (use
teleport version
):Tsh version (use
tsh version
):OS (e.g. from
/etc/os-release
):Where are you running Teleport? (e.g. AWS, GCP, Dedicated Hardware):
Browser environment
Relevant Debug Logs If Applicable
tsh --debug
teleport --debug
The text was updated successfully, but these errors were encountered: