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
external auth (exec) not working (azure/kubelogin and aws-iam-authenticator) #1885
Comments
Hi. Thanks for writing. Yeah, we use the k8s APIs rather than kubectl and haven't implemented support for the "client-go credential plugins". As a not-great work around authentication for both AKS and EKS can be done with OIDC. I realize this is probably not suitable however. Because the point of the aws-iam-authenticator is to avoid having to manage separate services. (please correct me if I'm wrong?) Supporting external auth commands isn't currently on the short term roadmap. But I personally think it's something we should support. External auth related docsexec:
apiVersion: ...
command: ...
args: ... Other related issues:A number of others have reported here and elsewhere wanting support for external auth commands. Here are some of the github issues: |
I agree this will be a must have for most companies. |
Would also like for this to work. I'm guessing there are a lot of people using some form of client-side addon (e.g. i am using passman to store the credentials in keychain):
|
From #1716 I've been able to get this working like so
Could be a work-around until the underlying connectivity issue is resolved? |
On macos, I've used the following work-around to make this work via native Finder/Dock/Spotlight launch
This ensures that the paths where my exec plugins are located are in the environment of every application I launch via Finder et al. Unfortunately, the change requires root and a reboot, but successfully unblocks Headlamp in local GUI mode to work properly with exec configuration. Incorporating something similar to shell-path in the electron startup should allow Headlamp to inherit user-configured PATH environment so that Headlamp works as expected: https://github.com/sindresorhus/shell-path (hopefully there is a newer, maintained dependency). Headlamp appears to implement kubeconfig handling in a way that already supports |
Thanks @lindblombr |
On at least MacOS, GUI apps do not take on the shell paths. However they are needed for kubectl auth plugins, and perhaps other binaries like minikube Fixes #1885 Signed-off-by: René Dudfield <[email protected]>
On at least MacOS, GUI apps do not take on the shell paths. However they are needed for kubectl auth plugins, and perhaps other binaries like minikube Fixes #1885 Signed-off-by: René Dudfield <[email protected]>
On at least MacOS, GUI apps do not take on the shell paths. However they are needed for kubectl auth plugins, and perhaps other binaries like minikube Fixes #1885 Signed-off-by: René Dudfield <[email protected]>
On at least MacOS, GUI apps do not take on the shell paths. However they are needed for kubectl auth plugins, and perhaps other binaries like minikube Fixes #1885 Signed-off-by: René Dudfield <[email protected]>
Yep, I'd love that. OpenLens picks up my AWS EKS context and connects to the clusters out of the box. Headlamp recognizes the contexts, but just shows "Bad Gateway" status for the clusters. I guess I'll stay with OpenLens for now :( edit2:
thats what my kube config looks like:
|
On at least MacOS, GUI apps do not take on the shell paths. However they are needed for kubectl auth plugins, and perhaps other binaries like minikube Fixes #1885 Signed-off-by: René Dudfield <[email protected]>
I tried connecting to our prod clusters using "azure/kubelogin" and aws-iam-authenticator.
None of these Auth Methods worked.
Is there an eta we can expect exec auth to work? We want to switch from the closed source software lens to headlamp, but this is currently blocking.
The text was updated successfully, but these errors were encountered: