Error when storing large token in keyring on macOS

[Gerrit-K]

Describe the issue

kubelogin repeatedly fails with:

error: get-token: could not write the token cache: keyring write kubelogin/tokencache/8f08accac[...]: data passed to Set was too big

To reproduce

Not sure how to reproduce this, as it's probably caused by a large token from our IdP. We do have a lot of groups that are mapped in the token, which significantly increases the token size.

Your environment

• OS: macOS Sequoia 15.2
• kubelogin version: v1.32.0
• kubectl version: v1.30.6
• OpenID Connect provider: Keycloak

Additional context

I verified that this was not happening in version 1.31.1, so I'm relatively confident this is related to #973. The description of the PR states that

The code prefers the OS keyring, if supported. Falls back to file based cache

However, with every kubectl command, I noticed consecutive failures and wasn't able to obtain a token* to interact with the cluster. There was no fallback to the file-based cache. For a reason I don't understand yet, the new option --no-keyring also doesn't seem to be available (and neither is --force-keyring), so I can't work around this by any other means than downgrading to 1.31.1:

$ kubectl oidc-login --help | grep keyring
$ kubectl oidc-login --version
kubelogin version 1.32.0

*in fact, I did get a token (which I could verify with the verbose logging), but kubelogin wasn't able to persist it

[mhanc]

I can confirm the issue to be related to kubelogin version 1.32.0. Downgrading to 1.31.1 fixes the issue as a workaround.

Not working:

$ kubectl oidc-login --version
kubelogin version 1.32.0

Error message:

error: get-token: could not write the token cache: keyring write kubelogin/tokencache/4b405edc3945a844f98861a1fb987a4297184c85f01d6bf4ebef54fe15b5cb70: data passed to Set was too big

Working version:

kubectl oidc-login --version
kubelogin version 1.31.1

[jamesrwhite]

I'm also seeing this issue since upgrading from 1.31.0 to 1.32.0.

❯ kubelogin version
kubelogin version v1.32.0 (go1.23.5 darwin_arm64)

I was able to workaround it by setting the --token-cache-storage=disk option.

Our IdP is AWS Cognito and token length is around ~1,300 characters.

[bbrala]

Same same :) using keycloak/microsoft entraid

[kelveden]

Same issue. I can confirm that jamesrwhite's workaround works for me - i.e. add the --token-cache-storage=disk option to the options for get-token in my kube config file.

Technical info:

• kubelogin version: 1.32.0
• Hardware: Apple M2 Pro
• OS: Sonoma 14.6.1

So, it looks like possibly an integration issue with the OS keyring on MacOS perhaps?

[jamesrwhite]

In the underlying library (go-keyring) it claims the limit for the keychain is around 3,000 bytes (source) but if you look at how it's actually implemented it's the combination of the service, username and password that you pass to Set() that cannot exceed 4096 bytes (source).

Worth noting this is also once those values have been base64 encoded and shell escaped.

A potential fix could be to calculate the length in the same way before calling Set() in the logic that selects which storage to use or alternatively to catch the ErrSetDataTooBig error here and fallback to using disk storage.

Catching the error and falling back to disk storage seems simpler and less likely to break if the underlying library changes it's implementation in my opinion.

I'd be happy to open a PR for this.

[minimax75]

Hi,
I have the same issue on a Windows-WSL machine. I have no keyring installend and the fallback to disk is not happening.
--token-cache-storage=auto should automatically fallback to disk, if keyring is not available.

As already mentioned --token-cache-storage=disk fix the problem, but yould force us to update all our kubeconfigs

OS: Win11
kubelogin version: v1.32.0
kubectl version: v1.32.1
Ubuntu: 24.04 on WSL
OpenID Connect provider: EntraID

WSL-Version: 2.3.26.0
Kernelversion: 5.15.167.4-1
WSLg-Version: 1.0.65
MSRDC-Version: 1.2.5620
Direct3D-Version: 1.611.1-81528511
DXCore-Version: 10.0.26100.1-240331-1435.ge-release
Windows-Version: 10.0.22631.4751

[int128]

v1.32.1 is available with the fix of #1257.

I think it is difficult to cover all edge cases in the fallback mode. I tested the keyring on Linux and it causes an error if dbus is not running.

I'd like to change the default mode to --token-cache-storage=disk. Any opinions?

[jamesrwhite]

@int128 thanks for merging and releasing my hotfix, I can confirm I'm no longer getting the same issue with v1.32.1 🥳