If persistHome is enabled, the token in .kube/config isn't renewed

[batleforc]

Describe the bug

Hello,
I have setup two kinds of env, one based on the udi and one that I build. With both image and the persistHome option enabled, I end up with a Kubeconfig with outdated token after 12 hours (the liveness setup in the IDP).

This bug has been found on Kubernetes (K3s,MicroK8s,kubeadm) and will be tested on OpenShift.

Fixed by deleting the /home/user/.kube folder and restarting the workspace

Che version

7.84@latest

Steps to reproduce

1. Setup an eclipse che with the persistHome option on true (i have the bug with either PerUser storage and PerWorkspace)
2. Start a workspace
3. Wait for the time needed for your token to not be valid any more
4. Type kubectl get pod
5. Enjoy the error.

Expected behavior

Well, i expect my token to be renewed each time i start a WorkSpace

Runtime

Kubernetes (vanilla)

Screenshots

Installation method

chectl/latest, chectl/next

Environment

Windows, Linux

Eclipse Che Logs

No response

Additional context

No response

[AObuchow]

@batleforc thanks for reporting. I believe this is a Che-Dashboard issue, as the Dashboard's backend is responsible for injecting the kube config into the workspace pod, however, I believe this injection only happens if the kubeconfig file doesn't exist in the pods filesystem. When persistUserHome is enabled, the kubeconfig file will persist on the PVC and thus will persist.

The required fix would probably be to re-create the kubeconfig file on workspace startup if a certain amount of time has passed since the workspace was last started (I'm not sure if we can actually track this). Or, to just always re-inject/overwrite the kubeconfig file on workspace startup.

[batleforc]

If there is no other kubeconfig mounted through a secret/configmap, wouldn't checking if the file matches a possible template checking if the token work and if not update it ?

[AObuchow]

If there is no other kubeconfig mounted through a secret/configmap, wouldn't checking if the file matches a possible template checking if the token work and if not update it ?

That seems like a much better idea than my suggestions, +1 :)

[batleforc]

I forgot to include, but the problem has been reproduced in the latest version of DevSpaces on OpenShift

[batleforc]

Hello,
Do you have any news on this issue ?

[AObuchow]

@batleforc no update so far, unfortunately.

@ibuziuk maybe something for the next sprint for team A?

[batleforc]

Is it possible to check if it's okay for you. I kind of need this fixed :/

[AObuchow]

@batleforc Thank you for submitting a PR for this :) I've pinged members of the team responsible for the Che Dashboard to take a look at your PR.

For testing your PR, it's worth checking whether the liveness setup in the IDP can be modified to be less than 12 hours (so that the reviewers don't have to wait as long).

[batleforc]

In the env I tested, the idp liveness was set to 6 / 8 / 12h, don't know how I can help further.
The IDP used was Zitadel.

[batleforc]

And i force logout my user too

[AObuchow]

@batleforc thanks for the info 🙏🏻
There's a time difference with the members of the team responsible for the Che Dashboard, so they will probably take a look at your PR starting tomorrow.

[ibuziuk]

@batleforc Thank you for the contribution, the fix should be part of the 7.89.0 - https://twitter.com/eclipse_che/status/1816081779607928954 🎉