Hey all, how is everyone handling Kubeconfig token expiration? We have a requirement of a max 30 day token. With a manual download of a new kubeconfig, are you importing the new file (using something like Krew Konfig plugin, etc.) or just replacing the token in the existing kubeconfig file?

I normally just copy the config to my clipboard and then edit and patch into my configuration with vim

Only token update is required

you using RMS?

Thanks all! We started with disabling the kubeconfig token altogether, and using RancherCLI to auth via AD account which works awesome), but ran into issues when it came to CI/CD setup with Jenkins -- where it got more complicated with the additional login prompt... So back to using the kubeconfig token at 30 days.

Instead of using the Rancher CLI, you can call the Rancher API with curl. • login to rancher using curl and the api to get a bearer token

bearer_token = curl -s "<rancher_url>/v3-public/localProviders/local?action=login" \
  -H "Content-Type: application/json" \
  --data '{"username":"<username>","password":"<password>"}'

• use the bearer token to get your cluster id

cluster_id = curl -H 'Authorization: Bearer <bearer_token>' <rancher_url>/v3/clusters?name=$<cluster_name> | jq -r '.data[0].id'

• use the bearer token + cluster id to get the kubeconfig

"curl -X POST -H 'Authorization: Bearer <bearer_token>' <rancher_url>/v3/clusters/<cluster_id>?action=generateKubeconfig | jq -r .config > cluster-kube-config.yml

• use kubeconfig to interact with your cluster

helm install --kubeconfig cluster-kube-config.yml

syntax might not be correct, but you can fiddle around. You will need jq to parse json response to extract data from the curl calls. This eliminates the dependency on rancher cli