Going to answer my own question…
Initially I thought I could fix it by enabling kubernetes rbac in the environment template as I had not done this.
However after enabling this I only got a different error.
Instead of getting the ‘You must be logged in to the server’ message when running kubectl with username and password I now got a ‘anonymous user is not allowed go do xxx in the default namespace’
Again when using the token (instead of username\password) as suggested in the rancher CLI window I had no problems.
Then I stumbled on this post:
And when converting my username and password (actually an account key id and account secret in such a token) things worked!!!
This token approach was independent of enabling/disabling kubernetes rbac.
As a last test I generated another token. This time with an environment key and secret. (instead of an account key/secret).
Even though this keypair was for the same admin user that was owner of the environment, this time I was back to the ‘You must be logged in to the server’ message.
So,… progress but still questions…
- Why does it work with a account token that is generated from a keyid and keysecret while it does not work when using the same keyid and secret as a username/password combination?
- Why does it work for an account key/pair but not for an environment keypair for the same admin user/environment owner?