Provide a mechanism to hide charts built into Rancher

[robertpatrick]

Is your feature request related to a problem? Please describe.

In our application, we have certain components always installed into our Kubernetes clusters and we need to hide some of the the Rancher Marketplace's built-in charts (e.g., istio) to prevent users from accidentally trying to install them and hosing their environment. We currently accomplish this by injecting code into filterAndArrangeCharts function in store/catalog.js but as we move to the new plugin model, we would like to be able to accomplish this from the plugin without having to modify the shell.

Describe the solution you'd like

We don't have any particular solution in mind, we just want some mechanism to do this from the plugin that doesn't require modifying the shell.

Describe alternatives you've considered

As I stated above, we are already doing this by modifying the store/catalog.js file but that requires us to fork your repo. We have also looked at modifying the ConfigMap where the list of charts is stored and changing the attribute on the charts to make them hidden. Since this data is stored in binary form in the ConfigMap, we were concerned about doing this since it seemed like you didn't want users messing with this data (since you didn't leave it in plain text).

Additional context

@richard-cox

[richard-cox]

Note - I've removed references to plugins, although that is one option for a solution.

There is a chart annotation to do this, catalog.cattle.io/hidden : true however this cannot be used if there's no ownership of the charts (for example from one of the rancher repos).

[andygodish]

I would also be interested in seeing functionality that would allow restrictions to the list of available chart by only enabling access to the chart repositories themselves at the project or user level.

I'm working in an environment where I would like to maintain access to all the packaged charts that come with Rancher (Partners, Rancher, RKE2) for the cluster admins while only allowing developer access to a particular set of approved chart repositories.

[catherineluse]

I believe it's at least theoretically possible to filter out any Helm charts that would require cluster level permissions to install. We could check if the user has permission to edit the cluster, then if they don't have that, go through the Helm chart YAML and filter out charts that require cluster level access, or gray them out and add a warning that installation would fail due to lack of permissions.

[robertpatrick]

@catherineluse Not sure how that would help us. This is not a permissions-type issue--this is a Kubernetes provider issue (e.g., we provide our clusters with a number of third-party apps already installed and wired up to our product). We want to prevent users from trying to install charts that would conflict with what we already provide.

[stefanlasiewski]

We also need this. Most of these charts should only be presented to cluster admins, not ordinary users. We want to provide a curated list of Helm charts to our users. Cluster admins need access to a broader set of charts.

For users, the visibility of some of these charts within the UI will only lead to a confusing user experience. Kubernetes is hard enough as is. We must have the ability to hide charts like "Istio" or "Nginx Ingress Controller" to prevent curious users from digging themselves into a hole.

[catherineluse]

Ah. So, it sounds like, in addition to a permissions filter, there also needs to be a way to mark individual charts with minimum permissions levels such as admin permissions required or cluster-owner permissions required, on a chart-by-chart basis.

Does the catalog also need to vary based on the cluster itself? As in, owners of Cluster A should see A, B, and C charts, but owners of cluster B should see X, Y and Z charts? Or would all cluster owners see the same thing?

[stefanlasiewski]

There is a chart annotation to do this, catalog.cattle.io/hidden : true however this cannot be used if there's no ownership of the charts (for example from one of the rancher repos).

What does "ownership" mean here? Is there a way for us to modify the chart YAML to attach ownership? Perhaps with an annotation like field.cattle.io/creatorId ?

[richard-cox]

There is a chart annotation to do this, catalog.cattle.io/hidden : true however this cannot be used if there's no ownership of the charts (for example from one of the rancher repos).

What does "ownership" mean here? Is there a way for us to modify the chart YAML to attach ownership? Perhaps with an annotation like field.cattle.io/creatorId ?

Ownership as is being in control of the helm repository where the chart in question lives. For instance if you wanted to hide a Rancher chart, you cannot apply the label to a chart in the Rancher owned helm repo. In theory you could fork them, make the change and then add those forked repos to Rancher, you would also need to ensure the fork was updated/maintained.

[robertpatrick]

But the ownership of the Helm chart in a repo is irrelevant for what is needed—that is, to prevent the chart from being displayed in the Rancher Dashboard. From this discussion, it seems clear that there is a missing mechanism to accomplish customizing the UI without worry about which repo or who owns it…

[richard-cox]

@robertpatrick I was responding to Stefan's question regarding an existing mechanism. That existing mechanism is something to take in to account when a solution to this is implemented (it shouldn't break or change the existing way, or convolute the problem space)

[gaktive]

Would need to discuss with @kwwii on strategy here.

[richard-cox]

Requires SURE-6164 (permission to add an app to a specific namespace)