### Summary **Note:** this issue proposes a short term implementation of Rancher roles and projects management in a GitOps way. However, the target solution should manage role/project management and the Sylva lifecycle independently, i.e. roles/projects declaration is not part of the sylva helmrelease values. Implement a new sylva-core unit that declares a GitRepository + Kustomization which produces a ConfigMap containing Rancher roles and projects definitions. This ConfigMap will be provided as a valuesFrom input to the existing rancher-roles-management unit (Helm release), enabling cluster-ops teams to manage Rancher roles and projects via Git (GitOps). ### Background Implement a GitOps-friendly flow to manage Rancher RBAC objects and projects: cluster operators should be able to define the following resources declaratively in a Git repository: * **Global Role Management**: Create and manage Rancher global role - `GlobalRole.management.cattle.io` * **Cluster Role Management**: Create and manage Rancher Cluster role - `RoleTemplates.management.cattle.io` resources with `cluster` context * **Project Role Management**: Create and manage Rancher Project role - `RoleTemplates.management.cattle.io` resources with `project` context * **Global Role Membership**: Create and manage Rancher global role to Keycloak group membership - `GlobalRoleBinding.management.cattle.io` * **Cluster Role Membership**: Create and manage Rancher cluster role to Keycloak group membership - `ClusterRoleTemplateBindings.management.cattle.io` * **Project Role Membership**: Create and manage Rancher project role to Keycloak group membership - `ProjectRoleTemplateBindings.management.cattle.io` sylva-core should reconcile that repository and provide the resulting ConfigMap to the [rancher-roles-management](https://gitlab.com/sylva-projects/sylva-elements/helm-charts/rancher-roles-management) Helm release. This follows the same pattern already established for: - Keycloak user management (see keycloak-user-groups-repo unit) - Workload cluster teams (see workload-teams-repo): https://gitlab.com/sylva-projects/sylva-core/-/blob/main/charts/sylva-units/values.yaml The rancher-roles-management Helm chart is defined in the following repository: 🔗 https://gitlab.com/sylva-projects/sylva-elements/helm-charts/rancher-roles-management ### Proposal (detailed) 1) Add a new unit rancher-roles-projects-repo The unit should: - Create a GitRepository resource pointing to the operator-managed Git repository - Create a Kustomization resource targeting the repo path containing a ConfigMap manifest - Ensure the Kustomization outputs a ConfigMap (e.g. name: rancher-roles-cm) whose data key holds Helm values expected by rancher-roles-management (e.g. values.yaml) 2) Update the rancher-roles-management unit wrapper to accept valuesFrom input referencing the ConfigMap created by the new unit - Merge the ConfigMap data into Helm values for the release - Maintain backwards compatibility: if valuesFrom is not provided, behavior remains unchanged 3) Provide an example Git repository layout and documentation - sample ConfigMap manifest with globalRoles, clusterRoles, projectRoleTemplates, bindings, projects in the chart-expected format - README showing how operators manage users via PRs - example sylva-core values.yaml showing unit declaration and reference 4) Tests and CI - Unit/integration tests for the full flow: Git repo → Kustomization → ConfigMap → rancher-roles-management Helm release Acceptance chainsaw tests verifying: GlobalRoles are created in Rancher ClusterRoles are created and bound correctly ProjectRoleTemplates are applied RoleBindings are effective for targeted users/groups Rancher Projects are created declaratively as expected