fix: update project-scoped permissions to include missing harvester r…

[ihcsim]

Problem:

This PR addresses these two issues:

1. 1.8-rc2 QA test result reported that the project users can't manage or see the backup schedules defined in their namespaces.
2. The value of the catalog.cattle.io/rancher-version annotation also doesn't match the Rancher v2.14 convention.

Solution:

This PR adds the harvesterhci.io API groups to the project roles so that project users can manage/view all namespaced-scoped Harvester resources. This compensates for the missing RBAC rules within the harvesterhci.io:view and harvesterhci.io:edit cluster roles. Currently, not all the Harvester RBAC rules are aggregated into these two cluster roles. Hence, when the new role templates inherit their RBAC rules from the built-in view and edit cluster roles, some Harvester permissions are missed.

Related Issue(s):

harvester/harvester#7909

Test plan:

The full test plan can be found in the HEP at https://github.com/ihcsim/harvester/blob/a06b3e4a6d372c53e19ba2a6081be15d7c81da60/enhancements/20260130-rancher-integration-rbac/test-plan-ui.md

For this change, we only need to retest the proj-manager and proj-viewer scenarios to make sure they can continue to only manage and see Harvester project-scoped resources. The new addition is that they can now manage and see the backup schedules.

Additional documentation or context

[Copilot]

Pull request overview

This PR updates the harvester-rbac Helm chart to ensure Rancher project-scoped role templates include missing Harvester API group permissions (so project users can manage/view namespaced Harvester resources like backup schedules) and aligns the chart’s Rancher version annotation with the Rancher v2.14 catalog convention.

Changes:

• Add harvesterhci.io API group rules to project-scoped RoleTemplates (virt-project-view, virt-project-manage).
• Grant additional permissions for supportbundles under the harvesterhci.io API group.
• Update catalog.cattle.io/rancher-version annotation to the Rancher v2.14 range format.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

File	Description
charts/harvester-rbac/templates/virt-project-view.yaml	Adds harvesterhci.io rules to the project “view” RoleTemplate (including a new supportbundles rule).
charts/harvester-rbac/templates/virt-project-manage.yaml	Adds harvesterhci.io rules to the project “manage” RoleTemplate (including a redundant supportbundles rule).
charts/harvester-rbac/Chart.yaml	Updates the Rancher catalog compatibility annotation to the v2.14 convention.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

virt-project-view is a view-only RoleTemplate, but this rule grants supportbundles full access (verbs: ["*"]). That’s a significant privilege escalation compared to the rest of the rules here (get/list/watch) and seems inconsistent with the role’s purpose. Consider restricting this to read-only verbs (or the minimal set actually required), or moving write verbs for supportbundles to the manage role only.

Suggested change

	- "*"
	- get
	- list
	- watch

[ihcsim]

This allows read-only project user to generate support bundle. However, project users will require permissions into the harvester-system namespace for the support bundle workload to run, which isn't granted by default.

[w13915984028]

Do you mean: by default, the project-view can't successfully generate supportbundle even with this rbac?

As support-bundle includes too many system related infromation, maybe we could remove this from chart default value; if user wants to, we have a document guide about how to edit the chart Values.yaml below parts to grant this. User takes the risk.

  {{- with .Values.projectRole.virtProjectView.additionalRules }}

[ihcsim]

Do you mean: by default, the project-view can't successfully generate supportbundle even with this rbac?

Correct. This change only grants permission to the supportbundles.harvesterhci.io API resource; nothing more. It is something that all cluster/project users need. We will follow this up with a backend issue to discuss how to approach this. The controller needs to identify the namespaces where the user has permissions to run the support bundle generators. Thanks.

[ihcsim]

User takes the risk.
{{- with .Values.projectRole.virtProjectView.additionalRules }}

My thinking is that, until we have a backend enhancement, if admin wants to give project users ability to generate support bundle, they can grant these users additional permissions via other custom roles on an individual basis. Using {{- with .Values.projectRole.virtProjectView.additionalRules }} means all project users end up with these extra permissions, not just those who are approved. By including the supportbundles.harvesterhci.io rule in the built-in role, admin won't have to keep repeating them in their own custom roles.

[w13915984028]

Some questions, thanks.

[w13915984028]

Do you mean: by default, the project-view can't successfully generate supportbundle even with this rbac?

As support-bundle includes too many system related infromation, maybe we could remove this from chart default value; if user wants to, we have a document guide about how to edit the chart Values.yaml below parts to grant this. User takes the risk.

  {{- with .Values.projectRole.virtProjectView.additionalRules }}