Switch CheckNamespaceExist to return a connect error as expected by client

[absoludity]

Description of the change

When we switched to connect-grpc, we continued sending standard gRPC error codes from Kubeapps-APIs, and without more information, the connect-gRPC machinery was converting these to code unknown.

When we check that a user has authenticated successfully by getting the default namespace after the login dance, either an OK or a forbidden means the request was authenticated, unauthenticated means it was not. But instead the error was coming back with an unknown code and so Kubeapps was not recognising this as authenticated. This was affecting logins for users who do not have permission to get the default namespace (see #6269 for the workaround).

I reproduced this locally (though with token auth) and so before this change, the gRPC request to CheckNamespaceExists came bace with what looks like a permission denied response - but the grpc-status code is 2 - which is unknown:

grpc-message | rpc  error: code = PermissionDenied desc = Forbidden to get the Namespace  'default' due to 'namespaces "default" is forbidden: User  "system:serviceaccount:kubeapps:kubeapps-view" cannot get resource  "namespaces" in API group "" in the namespace "default"'
grpc-status | 2 <----- this is "Unknown"

After this change, the error arrives as a PermissionDenied as expected:

grpc-message | Forbidden  to get the Namespace 'default' due to 'namespaces "default" is  forbidden: User "system:serviceaccount:kubeapps:kubeapps-view" cannot  get resource "namespaces" in API group "" in the namespace "default"'
grpc-status | 7 <----- this is the "PermissionDenied" code

which Kubeapps happily recognises and assumes the user is now authenticated.

Benefits

People can login without requiring RBAC to get the default namespace.

Possible drawbacks

None

Applicable issues

• fixes Auth loop when no admin permissions set on default namespace #6269

Additional information

Although I was glad to find the fix here, I'm still uncertain why our CI integration tests did not pick this up, given that the intention is that we check login with an unprivileged user. I need to investigate that further.

Also, this is a second attempt at fixing this after #6312 ended up touching too many call-sites. I'll then followup switching other call-sites and removing the old code.

[netlify]

✅ Deploy Preview for kubeapps-dev canceled.

Name	Link
🔨 Latest commit	b61bf9f
🔍 Latest deploy log	https://app.netlify.com/sites/kubeapps-dev/deploys/648fb5acaee14f00089b1364

[RGPosadas]

Hi @absoludity , thanks for the quick work on this! 🚀
When would you expect the fix to become available as a helm chart?

[absoludity]

No problem - it's great to be fixing things people need :) I'm waiting for the development image to be published so you can verify the fix, then after than @ppbaena and the team will chat about the next release.

[absoludity]

@RGPosadas Can you please test the fix by running with this kubeapps-apis image sha, and verify whether the issue is fixed or continues? Thanks.

[RGPosadas]

@absoludity Just confirmed that the auth loop is no longer blocking authenticated users. I am still getting correct 403s on the default namespace (and other non-authorized resources), and getting valid 2XX for the correct resources on login

[absoludity]

Great, thanks for the confirmation. I'll chat with Pepe about a release soon :)

[RGPosadas]

Sounds good!

[absoludity]

Hi @RGPosadas , we chatted last night about this. I'll aim to finish the related work (switching over all the other call-sites that are sending the old encoded errors, even though they don't cause problems like this call-site did) and release once that work is done, hopefully later next week.

[RGPosadas]

Gotcha, thanks for the update. Will keep an eye out for the next 2 weeks 🚀