[templates] Add RBAC ClusterRoles for module CRDs (astef-prototype)

[duckhawk]

Description

Add RBAC ClusterRoles for the module CRDs in two complementary layers.

1. Current model — templates/user-authz-cluster-roles.yaml

ClusterRole annotated with user-authz.deckhouse.io/access-level. user-authz creates bindings for subjects of every ClusterAuthorizationRule/AuthorizationRule with the matching level.

• User — read-only (get/list/watch).
• ClusterEditor — full CRUD (create/update/patch/delete/deletecollection).

2. admin.conf — templates/rbac-for-us.yaml

• ClusterRole d8:sds-replicated-volume:admin-kubeconfig — full CRUD on the module CRDs.
• ClusterRoleBinding d8:sds-replicated-volume:admin-kubeconfig — to Group/kubeadm:cluster-admins.

Subjects authenticated through the cluster admin.conf get the same access as ClusterEditor on module resources without going through user-authz.

3. rbacv2 — templates/rbacv2/

ClusterRoles aggregated via labels into Deckhouse rbacv2 roles.

manage (cluster-scoped CRDs) — templates/rbacv2/manage/:

• view.yaml → d8:manage:permission:module:sds-replicated-volume:view with rbac.deckhouse.io/aggregate-to-storage-as: viewer, read verbs.
• edit.yaml → d8:manage:permission:module:sds-replicated-volume:edit with rbac.deckhouse.io/aggregate-to-storage-as: manager, write verbs.

Covered resources

Cluster-scoped (via manage permissions):

• drbdmappers
• drbdnodeoperations
• drbdresourceoperations
• drbdresources
• replicatedstorageclasses
• replicatedstoragepools
• replicatedvolumeattachments
• replicatedvolumereplicas
• replicatedvolumes

Why do we need it, and what problem does it solve?

Exposes module CRDs to both Deckhouse RBAC layers so that the standard roles actually grant access to module resources:

• user-authz layer — subjects bound through ClusterAuthorizationRule/AuthorizationRule at the matching level (e.g. User, ClusterEditor) get the expected access automatically.
• admin.conf layer — kubeadm:cluster-admins group (used by the cluster admin.conf) is bound directly to the module's full-CRUD ClusterRole, bypassing user-authz.
• rbacv2 layer — aggregated roles d8:manage:storage:* (cluster-scoped) pull the module permissions in via the aggregation labels.

What is the expected result?

After applying, the following ClusterRoles are created:

• d8:user-authz:sds-replicated-volume:user (read)
• d8:user-authz:sds-replicated-volume:cluster-editor (CRUD)
• ClusterRole d8:sds-replicated-volume:admin-kubeconfig (CRUD)
• ClusterRoleBinding d8:sds-replicated-volume:admin-kubeconfig → Group/kubeadm:cluster-admins
• d8:manage:permission:module:sds-replicated-volume:view
• d8:manage:permission:module:sds-replicated-volume:edit

Checklist

• The code is covered by unit tests.
• e2e tests passed.
• Documentation updated according to the changes.
• Changes were tested in the Kubernetes cluster manually.