Use an explicit token to identify kubeapps cluster when required. #4591
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
For discussion. Signed-off-by: Michael Nelson <minelson@vmware.com>
Signed-off-by: Michael Nelson <minelson@vmware.com>
✅ Deploy Preview for kubeapps-dev canceled.Built without sensitive environment variables
|
castelblanque
added a commit
that referenced
this pull request
Oct 26, 2022
Signed-off-by: Rafa Castelblanque <rcastelblanq@vmware.com> ### Description of the change Adapted version of the outdated PR #4591. After removing kubeops, there has been a refactor of places changes by the old PR. It fixes the scenario in which the cluster where Kubeapps is installed is not part of the configured list of clusters. For example: ```yaml clusters: - name: second-cluster domain: ... apiServiceURL: .... certificateAuthorityData: ... serviceToken: eyJhbGciOiJS... ``` For doing so, it uses a token to reference the Kubeapps cluster: `-`. Also empty string `''` is accepted as cluster reference, for allowing payloads in which there is no cluster specified in context. Therefore, if a cluster string is empty or `-`, backend logic assumes that the Kubeapps cluster will be used. ### Benefits User can work in a multicluster setups in which the Kubeapps cluster is not part of the allowed clusters. ### Possible drawbacks N/A ### Applicable issues - fixes #4564 ### Additional information Manual tests have been done with Helm plugin (only one working in multicluster so far). CI E2E test will be done in #4563 Signed-off-by: Rafa Castelblanque <rcastelblanq@vmware.com>
|
Once #5566 was merged, can we close this one, @castelblanque ? |
|
Indeed. |
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.
Signed-off-by: Michael Nelson minelson@vmware.com
Description of the change
For discussion related to #4564 .
This PR aims to ensure that the context for an available package can always be resolved, even when there is no configured cluster name corresponding to the cluster on which Kubeapps is installed.
We need to test this as I suspect, if installing a package still requires fetching the AppRepository, that it would mean that the user credential must be valid to authenticate with the cluster on which Kubeapps is installed.
The user doesn't need any RBAC, only the ability to authenticate, since Kubeapps already includes RBAC to ensure that global repositories are readable by any authenticated user.
Also, if pinniped-proxy is being used, it won't currently handle this scenario (where the new token is used for the cluster on which Kubeapps is installed), but that will be easy to update. I'll add that depending on the discussion here.
Benefits
Possible drawbacks
Applicable issues
Additional information