fix(cli): honor kubeconfig env and exec auth tokens

[dronenb]

Changes

Fixes #1388

tkn-results built its Kubernetes client configuration differently from oc, kubectl, and tkn, which broke common kubeconfig-based authentication flows.

This PR fixes two related CLI authentication issues:

• Honor standard client-go kubeconfig precedence: explicit --kubeconfig, then $KUBECONFIG, then ~/.kube/config, including merged kubeconfig files.
• Resolve bearer tokens through client-go credential transport behavior instead of only reading rest.Config.BearerToken, so kubeconfig exec credentials such as oc get-token are invoked and their bearer token can be forwarded to the Results API.
• Preserve explicit --token and configured token overrides.
• Leave non-bearer-token authentication, such as client certificate auth, as an empty token result rather than an error.
• Correct the CLI help text for --kubeconfig and --namespace to match the actual precedence/default behavior.
• Add unit coverage for kubeconfig precedence, NewConfig, static token handling, nil config handling, non-token auth, exec credential token resolution, and CLI flag help text.

/kind bug

Submitter Checklist

These are the criteria that every PR should meet, please check them off as you review them:

• Has Docs included if any changes are user facing
• Has Tests included if any functionality added or changed
• Tested your changes locally (if this is a code change)
• Follows the commit message standard
• Meets the Tekton contributor standards (including functionality, content, code)
• Has a kind label. You can add a comment on this PR that contains /kind <type>. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tep
• Release notes block below has been updated with any user-facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings)
• Release notes contain the string "action required" if the change requires additional action from users switching to the new release

Testing

• go test ./pkg/cli/...
• Tested locally on work machine against real clusters, including kubeconfig-backed cluster authentication flows.

AI Assistance

This PR was prepared with assistance from OpenCode using GPT-5.5. The submitter reviewed the changes and ran the testing noted above.

Release Notes

tkn-results now honors $KUBECONFIG when loading kubeconfig and resolves bearer tokens from kubeconfig exec/auth-provider credentials, allowing CLI authentication flows such as OpenShift external OIDC `oc get-token` to work without manually supplying --token.

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: dronenb / name: Ben Dronen (f9bd147)

[dronenb]

/kind bug

[Copilot]

Pull request overview

This PR fixes tkn-results CLI authentication to match standard client-go/kubectl behavior by honoring kubeconfig loading precedence (including $KUBECONFIG) and correctly resolving bearer tokens from kubeconfig-backed credential providers (notably exec plugins like oc get-token), with accompanying unit tests and updated flag help text.

Changes:

• Switch kubeconfig loading to clientcmd.NewDefaultClientConfigLoadingRules() so precedence is --kubeconfig → $KUBECONFIG → ~/.kube/config (including merged kubeconfigs).
• Add bearer-token resolution that drives client-go’s auth transport so exec/auth-provider credentials can mint a token for forwarding to the Results API.
• Update CLI help text and add unit tests for kubeconfig precedence and token resolution paths.

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
pkg/cli/flags/flags.go	Updates --kubeconfig / --namespace help strings to match actual kubeconfig precedence/default behavior.
pkg/cli/config/config.go	Loads kubeconfig via default client-go rules and resolves tokens via the new token resolution helper.
pkg/cli/config/token.go	Introduces resolveBearerToken helper to obtain bearer tokens via client-go transport credential behavior.
pkg/cli/config/token_test.go	Adds unit tests for static token, nil config, wrap-transport token injection, and exec credential token resolution.
pkg/cli/config/config_auth_test.go	Adds end-to-end unit coverage for $KUBECONFIG precedence and exec credential token resolution through NewConfig().

Comments suppressed due to low confidence (1)

pkg/cli/config/token.go:79

• resolveBearerToken() claims to return a bearer token, but currently returns any non-empty Authorization header verbatim when it isn't "Bearer". That can accidentally forward Basic/custom auth material as a Results token; non-bearer schemes should resolve to an empty token.

	authz := capture.authorization
	if authz == "" {
		return "", nil
	}
	// Strip the "Bearer " scheme prefix if present.
	if parts := strings.SplitN(authz, " ", 2); len(parts) == 2 && strings.EqualFold(parts[0], "Bearer") {
		return parts[1], nil
	}
	return authz, nil

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[dronenb]

Addressed Copilot review comments in 0a155407:

• resolveBearerToken now always runs client-go HTTP auth wrappers after the static-token fast path, so BearerTokenFile / kubeconfig tokenFile credentials resolve even when WrapTransport is nil. Added TestResolveBearerTokenFile coverage.
• Non-Bearer Authorization schemes now resolve to an empty token instead of being returned verbatim, and the test expectation was updated accordingly.

[aThorp96]

This is great, thanks! Clever idea to extract token injected by middleware as well. I have one suggestion for simplifying the token resolution logic. It should also reduce the required tests a bit

[dronenb]

Addressed @aThorp96 review feedback in bf61273c by removing the dedicated authHeaderCapturingRoundTripper and using a small terminal roundTripperFunc instead. One implementation note: client-go bearer auth can clone the request, so the resolver reads Authorization from resp.Request after the wrapper chain runs rather than from the original request. Validation: go test ./pkg/cli/..., ./test/presubmit-tests.sh --unit-tests, and make all all pass.

[dronenb]

I will do some testing with this against our Tekton clusters and mark as ready for review when I'm comfortable things are good to go

[aThorp96]

One implementation note: client-go bearer auth can clone the request, so the resolver reads Authorization from resp.Request after the wrapper chain runs rather than from the original request.

Ah, good catch. I was wondering about that possibility as well but wasn't sure.

[enarha]

I will do some testing with this against our Tekton clusters and mark as ready for review when I'm comfortable things are good to go

Thank you for this PR. Can you please remove the draft/not ready indicator.

[enarha]

@divyansh42 PTAL when you have a chance.

[dronenb]

I think I identified an issue with how I was testing this, so I marked it as draft. Will validate today or tomorrow...

[divyansh42]

@dronenb Quick question on the config set interactive prompt: for exec/OIDC credentials (e.g. oc get-token), it now pre-fills the "Token" field with a live, short-lived token instead of leaving it blank. If a user just hits Enter, that token gets saved permanently in Extension.Token, and future commands will keep using that saved value instead of asking oc for a fresh one — so things would start failing again once it expires, until the user reruns config set.

Is that the intended behavior, or should the prompt stay blank by default for non-static credentials so the CLI keeps auto-refreshing the token each time?

[divyansh42]

I think I identified an issue with how I was testing this, so I marked it as draft. Will validate today or tomorrow...

@dronenb just wanted to check, if you were able to validate it?

[dronenb]

@dronenb Quick question on the config set interactive prompt: for exec/OIDC credentials (e.g. oc get-token), it now pre-fills the "Token" field with a live, short-lived token instead of leaving it blank. If a user just hits Enter, that token gets saved permanently in Extension.Token, and future commands will keep using that saved value instead of asking oc for a fresh one — so things would start failing again once it expires, until the user reruns config set.

Is that the intended behavior, or should the prompt stay blank by default for non-static credentials so the CLI keeps auto-refreshing the token each time?

I have addressed this, PTAL

@dronenb just wanted to check, if you were able to validate it?

Just validated, should be g2g. I have rebased as well.

[divyansh42]

Thanks @dronenb!
Could you please squash the commits into one?

[tekton-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: divyansh42

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [divyansh42]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[dronenb]

Thanks @dronenb! Could you please squash the commits into one?

Thanks, @divyansh42! I have squashed the commits and rebased, should be g2g!

[divyansh42]

Thanks @dronenb! Could you please squash the commits into one?

Thanks, @divyansh42! I have squashed the commits and rebased, should be g2g!

/cc @enarha @khrm

[dronenb]

@divyansh42 @enarha @khrm any update on this? Anything needed from my end? Let me know! 🙂

[enarha]

@divyansh42 @enarha @khrm any update on this? Anything needed from my end? Let me know! 🙂

Not for now. I want to perform a test on OpenShift cluster to verify if a smaller fix isn't sufficient. Please give me a day or max two to check that.