Ensure user client with service account backup when fetching namespaces. #5940
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Still need to check other call-sites. Signed-off-by: Michael Nelson <minelson@vmware.com>
Signed-off-by: Michael Nelson <minelson@vmware.com>
✅ Deploy Preview for kubeapps-dev ready!
To edit notification comments on pull requests, go to your Netlify site settings. |
ppbaena
approved these changes
Feb 1, 2023
absoludity
changed the title
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description of the change
The main change here is to ensure that the request for namespaces uses the user client first, then the service account client. For a detailed analysis of the issue it is fixing, see my comment on 5755
While there, I have tried to clarify the code a little, so that it is clearer when the user client is being used (it now matches the comments again).
I also fixed an RBAC issue in the dev environment (so that
kubeapps-user@example.comis permitted to access, in addition tooidc:kubeapps-user@example.com, since the former is what pinniped uses).Benefits
Back to expected behavior when authenticated as a non-privileged user with or without a service account token configured in Kubeapps' clusters configuration.
Possible drawbacks
Applicable issues
Additional information
I've tested this pretty thoroughly locally with multiple clusters using both unprivileged and privileged users (with additional log lines showing exactly what token is being used when), but only in the namespaces call-site.