Add ext.cattle.io/v1 token support - #632
Merged
pmatseykanets merged 10 commits intoAug 5, 2026
Merged
Conversation
The basic and OAuth login paths returned a v3 Norman Token directly. With session tokens about to migrate to ext.cattle.io/v1 server-side, the CLI needs to accept both response shapes from /v1-public/login. A parser detects the shape via apiVersion and kind, then unmarshals into a single internal type that carries the bearer token, expires-at, and user id.
The basic and OAuth login paths returned a v3 Norman Token, mixing the protocol shape into the cred-building code. These paths now return the shared internal type, and the cred builder reads only its bearer token, expires-at, and user id. The SAML path stays on v3 because the corresponding server endpoint stays on v3.
The OAuth login tests asserted only the v3 token shape and did not exercise the new ext-token branch in the response parser. The existing table-driven test gains an ext-shaped case with the corresponding bearer-token assertion, and a new test exercises the parser plus cred-building pipeline for both shapes with and without an expires-at field.
Token lookups hit only the v3 Management API. Once session tokens start being issued by the ext.cattle.io/v1 API, those lookups would 404. An HTTP helper now fetches tokens from the ext.cattle.io/v1 API. The user-id resolution and token-validation helpers try v3 first and fall back to the ext API; tokens whose id carries the ext/ prefix skip the v3 attempt entirely. Test stubs use function types so the mocks stay minimal.
…command The kubectl command resolved the current user and validated the kubeconfig token by calling the v3 Token API directly, with no fallback for ext-issued tokens. Both lookups now route through the shared helpers that try v3 first and fall back to the ext.cattle.io/v1 API. The local v3-only validation function and its dependent imports are removed.
A stale or deleted v3 token id surfaced a raw 404 from the ext API after fallback. A v3-tokened user with a stale kubeconfig also saw a hard 401 or 403 from the ext authenticator instead of getting the kubeconfig regenerated. The user-id lookup now wraps the underlying error with the failing token id so the failure is debuggable. Token validation treats 401 and 403 from the ext API the same as 404 and falls through to kubeconfig regeneration. Two new comments explain why the bearer token keeps any ext/ prefix and why a second HTTP client is needed alongside Norman's master client.
andreas-kupries
previously approved these changes
Aug 3, 2026
bigkevmcd
previously approved these changes
Aug 3, 2026
bigkevmcd
left a comment
bigkevmcd
left a comment
There was a problem hiding this comment.
Some nits around the use of contexts but otherwise, looks good.
| // | ||
| // IMPORTANT: do not wrap the returned *clientbase.APIError with fmt.Errorf("%w", ...) — | ||
| // clientbase.IsNotFound uses a direct type assertion (err.(*APIError)), not errors.As, | ||
| // so any wrap will make IsNotFound return false and break the v3-to-ext fallback contract. |
There was a problem hiding this comment.
I don't think you need to wait 'til this lands (if it does) to land your changes.
Switched all context.Background() calls in cmd/token_test.go to t.Context(), and removed underscores from test functions.
pmatseykanets
dismissed stale reviews from bigkevmcd and andreas-kupries
via
August 4, 2026 22:32
c120de3
bigkevmcd
approved these changes
Aug 5, 2026
andreas-kupries
approved these changes
Aug 5, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Issue: rancher/rancher#55988
Problem
Rancher will migrate session tokens from
management.cattle.io/v3toext.cattle.io/v1. When this lands,/v1-public/loginwill begin returningext.cattle.io/v1Token objects. Current CLI versions parse the login response as a v3.Token and would fail to extract the bearer from an ext.Token-shaped response.The kubectl command also looks up the current user and validates the kubeconfig token via the v3.Token API only, so looking up an ext.Token would return 404 and stale-kubeconfig detection would surface the error instead of regenerating the config.
Solution
Accept both response shapes from
/v1-public/loginand route token lookups through v3 with anext.cattle.io/v1fallback.ext.cattle.io/v1response shape viaapiVersionandkind, then unmarshals into a single internal type.ext.cattle.io/v1. Tokens whose id carries theext/prefix skip the v3 attempt.ext.cattle.io/v1API are treated the same as 404 so kubeconfig regeneration still runs for v3-tokened users whose credentials the ext authenticator does not accept.The SAML login path is unchanged. The SamlToken CRD used for the poll response is a transport envelope that carries an encrypted bearer string, and that encryption is agnostic to the underlying token shape (v3 name:value or ext ext/name:value).