-
Notifications
You must be signed in to change notification settings - Fork 513
frontend,backend: support exec/teleport/cert based auth to clusters #4279
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
base: main
Are you sure you want to change the base?
Conversation
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: rushrs The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
|
|
|
Welcome @rushrs! |
vyncent-t
left a comment
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.
Submitting this for a copilot suggestions, feel free to adjust as you see fit.
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.
Pull request overview
This PR adds first-class support for Teleport's tsh authentication and improves authentication handling for exec credential plugins and client certificate authentication. The key changes differentiate between authentication types to use appropriate endpoints and provide better error messages.
- Backend now detects and returns specific auth types: "tsh", "exec", and "client-cert" instead of generic types
- Frontend uses the
/versionendpoint for authentication tests with tsh/exec/client-cert auth (instead of SelfSubjectRulesReview which Teleport blocks) - Teleport-specific error messages guide users to run
tsh loginwhen authentication fails
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 4 comments.
| File | Description |
|---|---|
| backend/pkg/kubeconfig/kubeconfig.go | Extends AuthType() to detect and return "tsh", "exec", and "client-cert" auth types by inspecting kubeconfig AuthInfo |
| frontend/src/lib/k8s/api/v1/clusterApi.ts | Modifies testAuth() to accept authType parameter and use /version endpoint for exec-based auth instead of SelfSubjectRulesReview |
| frontend/src/components/authchooser/index.tsx | Skips auth testing for exec and client-cert auth types to avoid conflicts with RouteSwitcher |
| frontend/src/components/App/RouteSwitcher.tsx | Adds authType to AuthRoute, shows Teleport-specific error messages for failed tsh authentication |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Just had a scan through and added the tsh check. happy with it now |
|
addressed the failing github actions steps and rebased, thanks all |
|
Thanks @rushrs I will review and test over the next days. I ran the CI jobs again (they have to be manually run the first time someone contributes a PR). Would it be possible to squash some of the commits together and to get rid of the merge commits? We follow a Linux kernel style commit message formatting… please see https://headlamp.dev/docs/latest/contributing#2-follow-commit-guidelines Are there instructions somewhere for teleport with the exec credential so we can test this manually? |
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.
Pull request overview
Copilot reviewed 4 out of 4 changed files in this pull request and generated 7 comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
It looks like teleport isn't open source exactly, so I can not manually test it myself. |
exec based auth
cert based auth
|
|
Hi, we already support client cert and exec auth. Is there a reason for changes you're introducing for those? |
34f0261 to
89d0a5b
Compare
|
there is a self hosted opensource version which has an apache 2.0 license |
Hey! the exec based support doesnt work in the frontend, it results to When connecting via teleport headlamp asks for a client id which isn't present as
|
89d0a5b to
3a60699
Compare
Ah right. Thanks for the clarification. |
3a60699 to
f1685fa
Compare
|
@rushrs do you have a link that explains the licensing? There is this file that seems to be a non open source license? https://github.com/gravitational/teleport/blob/master/build.assets/LICENSE-community I especially want to know how to use the "self hosted opensource version which has an apache 2.0 license" version in order to be able to manually test this. |
ah I hadn't realised they moved away from that licence a while back. i've just used the enterprise version mainly. looks like the new one builds on apache 2.0 but restricts building products from their source code. we are not doing that in this case just enabling support for it |
f1685fa to
3d82547
Compare
3d82547 to
4bf29ac
Compare
Add support for exec-based credential plugins (Teleport tsh, aws-iam-authenticator) and client certificate authentication. Backend changes: - kubeconfig: Detect auth type from exec config - kubeconfig: Return "tsh" for Teleport, "exec" for others Frontend changes: - clusterApi: Use /version endpoint for exec/cert auth - clusterApi: Add backward-compatible options parameter - RouteSwitcher: Show auth-type specific error messages - RouteSwitcher: Wait for clusters to load before auth check
4bf29ac to
e039819
Compare
Cool. It's just none of the headlamp maintainers has Teleport experience, and I guess we can't manually test it ourselves. Do you think you would be around if any Teleport related issues pop up? We don't have regression tests for this code either so far... so we'd have to rely on you and other Teleport users to report/fix issues. Are you able to write testing steps in the PR description? This way another teleport user in the future would find the testing steps useful for testing this if you're not around. |
| 'Exec credential plugin authentication failed. Please refresh your credentials and try again.'; | ||
| } else { | ||
| errorMessage = | ||
| 'Client certificate authentication failed. Please check your certificates.'; |
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.
Strings need to be translated with t() from useTranslate. See other strings in different components.
Afterwards “npm run i18n” needs to be run.
| } else if (authType === 'exec') { | ||
| errorMessage = | ||
| 'Exec credential plugin authentication failed. Please refresh your credentials and try again.'; | ||
| } else { |
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.
Maybe match on "client-cert" to be more explicit?
|
|
||
| if (query.isError) { | ||
| // For tsh/exec/client-cert auth, show a helpful error message | ||
| if (isExecOrCertAuth) { |
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 think this could code be in it's own component. Called something like AuthenticationError?
|
I will action these changes and don't mind being a maintainer for this part of the integration. |
Summary
Problem
Headlamp didn't properly handle Teleport's exec credential plugin authentication. When users loaded clusters configured with tsh kube credentials, they would see:
Solution
Added first-class support for Teleport's tsh authentication:
Related Issue
Steps to Test
I built the frontend backend and app locally and tried it with these changes and the tsh based auth worked.
Screenshots (if applicable)
Notes for the Reviewer