Available with limitations in: Open/CE

Available without limitations in:  Core, BE, SE, SE+, Ultimate/EE

The module lifecycle stage: General Availability

The module generates role-based access model objects based on the standard Kubernetes RBAC mechanism. The module creates a set of cluster roles (ClusterRole) suitable for most user and group access management tasks.

Starting from Deckhouse Platform v1.64, the module features a experimental role-based access model. The current role-based access model will continue to operate but support for it will be discontinued in the future.

The experimental role-based access model is incompatible with the current one.

The module implements a role-based access model based on the standard RBAC Kubernetes mechanism. It creates a set of cluster roles (ClusterRole) suitable for most user and group access management tasks.

Experimental role-based model

Unlike the current DP role-based model, the new role-based one does not use ClusterAuthorizationRule and AuthorizationRule resources. All access rights are configured in the standard Kubernetes RBAC way, i.e., by creating RoleBinding or ClusterRoleBinding resources and specifying one of the roles prepared by the user-authz module in them.

The module creates special aggregated cluster roles (ClusterRole). By using these roles in RoleBinding or ClusterRoleBinding, you can do the following:

  • Manage access to modules of a specific subsystem.

    For example, you can use the d8:manage:networking:manager role in ClusterRoleBinding to allow a network administrator to configure network modules (such as cni-cilium, ingress-nginx, istio, etc.).

  • Manage access to user resources of modules within the namespace.

    For example, the d8:use:role:manager role in RoleBinding enables deleting/creating/editing the PodLoggingConfig resource in the namespace. At the same time, it does not grant access to the cluster-wide ClusterLoggingConfig and ClusterLogDestination resources of the log-shipper module, nor does it allow configuration of the log-shipper module itself.

The roles created by the module are divided into two classes:

  • Use roles — for assigning rights to users (such as application developers) in a specific namespace.
  • Manage roles — for assigning rights to administrators.

Using ClusterAuthorizationRule and AuthorizationRule together with RBAC

If multitenancy mode is enabled in the cluster (via enableMultiTenancy: true), the effective permissions of a user are the combination of all permissions granted by the following sources:

  • Permissions granted by ClusterAuthorizationRule: Applied only inside the namespaces allowed by its limitNamespaces or namespaceSelector parameters.
  • Permissions granted by AuthorizationRule: Applied inside the namespace the AuthorizationRule is created in.
  • Permissions granted by ordinary RoleBinding: Applied inside the namespace the RoleBinding is created in.
  • Permissions granted by ordinary ClusterRoleBinding that aren’t generated by the user-authz module: Applied cluster-wide.

The namespace restrictions set in a ClusterAuthorizationRule apply only to the permissions granted by that ClusterAuthorizationRule. They do not cancel permissions granted via RoleBinding, ClusterRoleBinding, or AuthorizationRule in other namespaces. Likewise, the permissions granted by ClusterAuthorizationRule do not extend to those namespaces.

For example, if a user has a ClusterAuthorizationRule with accessLevel: Editor limited to the ns-a namespace and a RoleBinding with the view role in the ns-b namespace, they get the Editor permissions in the ns-a namespace and read-only permissions in the ns-b namespace. Permissions granted by the RoleBinding aren’t restricted by the ClusterAuthorizationRule, and the Editor level set in the ClusterAuthorizationRule doesn’t apply to the ns-b namespace.

Starting with DP 1.76.5, RoleBinding and ClusterAuthorizationRule can be used together for the same user. In older DP versions, the user-authz module’s webhook rejected all requests to namespaces not listed in the user’s ClusterAuthorizationRule, even if the user had the corresponding RoleBindings.

Use roles

The use role can only be used in the RoleBinding resource.

Use roles are intended to assign rights to a user in a specific namespace. Users refer to, for example, developers who use a cluster configured by an administrator to deploy their applications. Such users don’t need to manage DP modules or a cluster, but they need to be able to, for example, create their Ingress resources, configure application authentication, and collect logs from applications.

The use role defines permissions for accessing namespaced resources of modules and standard namespaced resources of Kubernetes (Pod, Deployment, Secret, ConfigMap, etc.).

The module creates the following use roles:

  • d8:use:role:viewer — allows viewing standard Kubernetes resources in a specific namespace, except for Secrets and RBAC resources, as well as authenticating in the cluster;
  • d8:use:role:user — in addition to the role d8:use:role:viewer it allows viewing secrets and RBAC resources in a specific namespace, connecting to pods, deleting pods (but not creating or modifying them), executing kubectl port-forward and kubectl proxy, as well as changing the number of replicas of controllers;
  • d8:use:role:manager — in addition to the role d8:use:role:user it allows managing module resources (for example, Certificate, PodLoggingConfig, etc.) and standard namespaced Kubernetes resources (Pod, ConfigMap, CronJob, etc.) in a specific namespace;
  • d8:use:role:admin — in addition to the role d8:use:role:manager it allows managing the resources ResourceQuota, ServiceAccount, Role, RoleBinding, NetworkPolicy in a specific namespace.

Manage roles

The manage role does not grant access to the namespace of user applications.

The manage role grants access only to system namespaces (starting with d8- or kube-), and only to those system namespaces where the modules of the corresponding role subsystem are running.

Manage roles are intended for assigning rights to manage the entire platform or a part of it (the subsystem), but not the users applications themselves. Using a manage role you can enable, for example, a security administrator to manage cluster security modules. Thus, the security administrator will be able to configure authentication, authorization, security policies, and other respective parameters.

A manage role does not, by itself, let you grant access to other people.

Creating a User or Group that is not already a grant subject is ordinary object creation.

Creating a User for an email that already carries a grant, or writing a ClusterAuthorizationRule, is granting roles. The request is admitted only if the requester already has covering permissions or is explicitly allowed to assign those roles.

The ClusterAuthorizationRule spec.accessLevel field is a current-model level: User, PrivilegedUser, Editor, Admin, ClusterEditor, ClusterAdmin, SuperAdmin. A security subsystem manager can assign any of those except SuperAdmin. That manager also cannot assign the Kubernetes cluster-admin ClusterRole. Experimental-model security roles stop at d8:subsystem:security:admin.

A requester with every permission across the cluster counts as SuperAdmin in these checks and can assign any role that exists in the cluster, including SuperAdmin and cluster-admin. For example, a subject of the Kubernetes cluster-admin ClusterRole has such permissions if the role is granted by a ClusterRoleBinding or by a ClusterAuthorizationRule without namespaceSelector and limitNamespaces. If multitenancy mode is enabled, such a rule must also set allowAccessToSystemNamespaces: true, otherwise it does not reach the system namespaces. Permissions from a ClusterAuthorizationRule with namespaceSelector or limitNamespaces do not count toward this, even if the rule grants cluster-admin. Any non-empty limitNamespaces counts as a limit on purpose, even if its entries match every namespace, such as .* together with allowAccessToSystemNamespaces: true. Such a rule still counts through its accessLevel: for example, accessLevel: SuperAdmin gives the SuperAdmin range whatever the namespace limits of the rule.

limitNamespaces and namespaceSelector restrict access to namespaced resources only. A subject with the ClusterAdmin or SuperAdmin access level can still create ClusterRoleBinding and ClusterAuthorizationRule objects, so these fields do not confine what it can grant across the cluster. Give these levels only to subjects that may hold access to the whole cluster.

Webhook deny messages call the accessLevel values basic, so they are not confused with manage-role levels (viewer / manager).

Permission to create User and Group objects in the user-authn module is not enough: it does not grant the roles already attached to that email.

The manage role defines access rights:

  • to cluster-wide Kubernetes resources;
  • to manage DP modules (ModuleConfig resource) within the subsystem of the role, or to all DP modules for the role d8:manage:all:*;
  • to manage cluster-wide resources of DP modules within the subsystem of the role, or to all resources of DP modules for the role d8:manage:all:*;
  • to system namespaces (starting with d8- or kube-) in which the modules of the subsystem of the role operate, or to all system namespaces for the role d8:manage:all:*.

The manage role name format is d8:manage:<SUBSYSTEM>:<ACCESS_LEVEL>, where:

  • SUBSYSTEM is the role’s subsystem. It can be one of the subsystem, or all, for access across all subsystems;

  • ACCESS_LEVEL is the access level.

    Examples of manage roles:

    • d8:manage:all:viewer — access to view the configuration of all DP modules (ModuleConfig resource), their cluster-wide resources, their namespaced resources, and standard Kubernetes objects (except Secrets and RBAC resources) in all system namespaces (starting with d8- or kube-);
    • d8:manage:all:manager — similar to the role d8:manage:all:viewer, but with admin-level access, i.e., view/create/modify/delete the configuration of all DP modules (ModuleConfig resource), their cluster-wide resources, their namespaced resources, and standard Kubernetes objects in all system namespaces (starting with d8- or kube-);
    • d8:manage:observability:viewer — access to view the configuration of DP modules (ModuleConfig resource) from the observability area, their cluster-wide resources, their namespaced resources, and standard Kubernetes objects (except secrets and RBAC resources) in the system namespaces d8-log-shipper, d8-monitoring, d8-okmeter, d8-operator-prometheus, d8-upmeter, kube-prometheus-pushgateway.

The module provides two access level for administrators:

  • viewer — allows viewing standard Kubernetes resources, the configuration of modules (resources ModuleConfig), cluster-wide resources of modules, and namespaced resources of modules in the module namespace;
  • manager — in addition to the role viewer it allows managing standard Kubernetes resources, the configuration of modules (resources ModuleConfig), cluster-wide resources of modules, and namespaced resources of modules in the module namespace;

Subsystems of the role-based model

Each DP module belongs to a specific subsystem. For each subsystem, there is a set of roles with different levels of access. Roles are updated automatically when the module is enabled or disabled.

For example, for the networking subsystem, there are the following manage roles that can be used in ClusterRoleBinding:

  • d8:manage:networking:viewer
  • d8:manage:networking:manager

The scope of a role depends on which subsystem it belongs to:

  • The scope of roles from the all subsystem is all system namespaces (starting with d8- or kube-) in the cluster.
  • The scope of roles from other subsystems includes the namespaces in which the subsystem’s modules operate (see the subsystem composition table), as well as all cluster-wide objects of the subsystem’s modules.

Role-based model subsystems composition table.

Subsystem Subsystem modules Namespaces in which modules of a scope operate
all All modules All namespaces
deckhouse
  • deckhouse
  • multitenancy-manager
  • d8-multitenancy-manager
  • d8-system
infrastructure
  • chrony
  • cloud-provider-aws
  • cloud-provider-azure
  • cloud-provider-dynamix
  • cloud-provider-gcp
  • cloud-provider-huaweicloud
  • cloud-provider-openstack
  • cloud-provider-vcd
  • cloud-provider-vsphere
  • cloud-provider-yandex
  • cloud-provider-zvirt
  • descheduler
  • istio
  • keepalived
  • local-path-provisioner
  • node-manager
  • terraform-manager
  • vertical-pod-autoscaler
  • d8-chrony
  • d8-cloud-instance-manager
  • d8-cloud-provider-aws
  • d8-cloud-provider-azure
  • d8-cloud-provider-dynamix
  • d8-cloud-provider-gcp
  • d8-cloud-provider-huaweicloud
  • d8-cloud-provider-openstack
  • d8-cloud-provider-vcd
  • d8-cloud-provider-vsphere
  • d8-cloud-provider-yandex
  • d8-cloud-provider-zvirt
  • d8-descheduler
  • d8-istio
  • d8-keepalived
  • d8-local-path-provisioner
  • d8-monitoring
  • d8-system
  • kube-system
kubernetes
  • control-plane-manager
  • flow-schema
  • kube-dns
  • kube-proxy
  • priority-class
  • d8-system
  • kube-system
networking
  • cilium-hubble
  • cni-cilium
  • cni-flannel
  • cni-simple-bridge
  • flow-schema
  • ingress-nginx
  • istio
  • kube-dns
  • kube-proxy
  • metallb
  • network-gateway
  • network-policy-engine
  • node-local-dns
  • openvpn
  • static-routing-manager
  • d8-cni-cilium
  • d8-cni-flannel
  • d8-cni-simple-bridge
  • d8-ingress-nginx
  • d8-istio
  • d8-metallb
  • d8-network-gateway
  • d8-openvpn
  • d8-static-routing-manager
  • d8-system
  • kube-system
observability
  • dashboard
  • extended-monitoring
  • log-shipper
  • monitoring-custom
  • monitoring-deckhouse
  • monitoring-kubernetes
  • monitoring-ping
  • okmeter
  • operator-prometheus
  • prometheus
  • prometheus-metrics-adapter
  • prometheus-pushgateway
  • upmeter
  • d8-log-shipper
  • d8-monitoring
  • d8-okmeter
  • d8-operator-prometheus
  • d8-upmeter
  • kube-prometheus-pushgateway
security
  • admission-policy-engine
  • cert-manager
  • operator-trivy
  • runtime-audit-engine
  • secret-copier
  • user-authn
  • user-authz
  • d8-admission-policy-engine
  • d8-cert-manager
  • d8-operator-trivy
  • d8-runtime-audit-engine
  • d8-user-authn

Migration to the new role names in DP 1.78

Prior to DP 1.78, the roles keep working under their existing names.

In DP 1.78, the roles of the experimental model will be renamed, and the current names (d8:manage:<subsystem>:<level>, d8:manage:all:<level>, and d8:use:role:<level>) will become deprecated. For backward compatibility they will be kept as alias roles for exactly one release: existing bindings will keep working and granting the same permissions as the new roles, after which the aliases will be removed.

Name mapping:

Current name (to be deprecated) New name
d8:manage:all:<level> d8:system:<level>
d8:manage:<subsystem>:<level> d8:subsystem:<subsystem>:<level>
d8:use:role:<level> d8:namespace:<level>

The new model will also introduce the superadmin access level (for example, d8:namespace:superadmin, d8:system:superadmin) for managing system resources.

The d8:use:role:admin role will map to d8:namespace:admin and, as a result, will no longer grant the right to re-issue ServiceAccount tokens or impersonate — that will require the superadmin level.

Capabilities (the d8:manage:permission:* and d8:use:capability:* building-block roles) will be renamed without compatibility aliases, as they are meant to be aggregated into roles, not bound directly. If you have a RoleBinding or ClusterRoleBinding object pointing directly at such a capability, it will stop granting anything after the upgrade. Recreate the binding against the appropriate role (or a custom role aggregating the new capability).

The D8UserAuthzLegacyRBACv2CapabilityBindingFound alert lists such bindings to the capabilities of the Deckhouse Platform modules, and names the new name of each capability. The FAQ lists how the names change. A module installed from a module source renames its capabilities in a release of its own.

How to prepare for the migration:

  1. Find the bindings that use the current role names:

    d8 k get clusterrolebindings,rolebindings -A -o json \
  | jq -r '.items[] | select(.roleRef.name | test("^d8:(manage|use):")) | "\(.kind) \(.metadata.namespace // "-") \(.metadata.name) -> \(.roleRef.name)"'

  2. After upgrading to DP 1.78, migrate these RoleBinding and ClusterRoleBinding objects to the new role names within one release cycle. Since the roleRef field is immutable, delete the binding and recreate it with the new role name.

For a guide on migrating your custom roles, see the FAQ.

Current role-based model

Features:

In addition to the RBAC, you can use a set of high-level roles in the module:

  • User — has access to information about all objects (including viewing pod logs) but cannot exec into containers, read secrets, and perform port-forwarding;
  • PrivilegedUser — the same as User + can exec into containers, read secrets, and delete pods (and thus, restart them);
  • Editor — is the same as PrivilegedUser + can create and edit all objects that are usually required for application tasks.
  • Admin — the same as Editor + can delete service objects (auxiliary resources such as ReplicaSet, certmanager.k8s.io/challenges and certmanager.k8s.io/orders);
  • ClusterEditor — the same as Editor + can manage a limited set of cluster-wide objects that can be used in application tasks (ClusterXXXMetric, KeepalivedInstance, DaemonSet, etc.). This role is best suited for cluster operators.
  • ClusterAdmin — the same as both ClusterEditor and Admin + can manage cluster-wide service objects (e.g., MachineSets, Machines, OpenstackInstanceClasses…, as well as ClusterAuthorizationRule, ClusterRoleBindings and ClusterRole). This role is best suited for cluster administrators. Note that since ClusterAdmin can edit ClusterRoleBindings, he can broaden his privileges within the cluster;
  • SuperAdmin — can perform any actions with any objects (note that namespaceSelector and limitNamespaces restrictions remain valid).

Currently, the multi-tenancy mode (namespace-based authorization) is implemented according to a temporary scheme and isn’t guaranteed to be entirely safe and secure!

If a ClusterAuthorizationRule Custom Resource contains the namespaceSelector field, neither limitNamespaces nor allowAccessToSystemNamespacesare taken into consideration.

The allowAccessToSystemNamespaces, namespaceSelector and limitNamespaces options in the custom resource will no longer be applied if the authorization system’s webhook is unavailable for some reason. As a result, users will have access to all namespaces. After the webhook availability is restored, the options will become relevant again.

Default access list for each role

Each next role inherits permissions from the previous roles. A role block shows only the permissions added by that role.

The list below includes:

  • standard permissions from the current role-based model (k8s permissions);
  • permissions created by Deckhouse’s built-in modules.

It does not include permissions for modules from source.

When enabled in a cluster, modules from source create permissions for the resources they provide. When a module from source is disabled, the permissions it created are removed.

To view the permissions created by source modules, use the command.

verbs aliases:

  • read - get, list, watch
  • read-write - get, list, watch, create, delete, deletecollection, patch, update
  • write - create, delete, deletecollection, patch, update

Role User:

read:
    - acme.cert-manager.io/challenges
    - acme.cert-manager.io/orders
    - apiextensions.k8s.io/customresourcedefinitions
    - apps/daemonsets
    - apps/deployments
    - apps/replicasets
    - apps/statefulsets
    - autoscaling.k8s.io/verticalpodautoscalercheckpoints
    - autoscaling.k8s.io/verticalpodautoscalers
    - autoscaling/horizontalpodautoscalers
    - batch/cronjobs
    - batch/jobs
    - cert-manager.io/certificaterequests
    - cert-manager.io/certificates
    - cert-manager.io/clusterissuers
    - cert-manager.io/issuers
    - cilium.io/ciliumclusterwidenetworkpolicies
    - cilium.io/ciliumnetworkpolicies
    - config.gatekeeper.sh/configs
    - configmaps
    - connection.gatekeeper.sh/connections
    - constraints.gatekeeper.sh/*
    - deckhouse.io/applications
    - deckhouse.io/awsinstanceclasses
    - deckhouse.io/azureinstanceclasses
    - deckhouse.io/deschedulers
    - deckhouse.io/dexauthenticators
    - deckhouse.io/dexclients
    - deckhouse.io/dvpinstanceclasses
    - deckhouse.io/dynamixinstanceclasses
    - deckhouse.io/gcpinstanceclasses
    - deckhouse.io/huaweicloudinstanceclasses
    - deckhouse.io/hubblemonitoringconfigs
    - deckhouse.io/instances
    - deckhouse.io/keepalivedinstances
    - deckhouse.io/localpathprovisioners
    - deckhouse.io/nodegroups
    - deckhouse.io/openstackinstanceclasses
    - deckhouse.io/operationpolicies
    - deckhouse.io/projecttemplates
    - deckhouse.io/securitypolicies
    - deckhouse.io/securitypolicyexceptions
    - deckhouse.io/vcdaffinityrules
    - deckhouse.io/vcdinstanceclasses
    - deckhouse.io/vsphereinstanceclasses
    - deckhouse.io/yandexinstanceclasses
    - deckhouse.io/zvirtinstanceclasses
    - discovery.k8s.io/endpointslices
    - endpoints
    - events
    - events.k8s.io/events
    - expansion.gatekeeper.sh/expansiontemplate
    - extensions.istio.io/wasmplugins
    - extensions/daemonsets
    - extensions/deployments
    - extensions/ingresses
    - extensions/replicasets
    - extensions/replicationcontrollers
    - externaldata.gatekeeper.sh/providers
    - gateway.networking.k8s.io/backendtlspolicies
    - gateway.networking.k8s.io/gatewayclasses
    - gateway.networking.k8s.io/gateways
    - gateway.networking.k8s.io/grpcroutes
    - gateway.networking.k8s.io/httproutes
    - gateway.networking.k8s.io/listenersets
    - gateway.networking.k8s.io/referencegrants
    - gateway.networking.k8s.io/tcproutes
    - gateway.networking.k8s.io/tlsroutes
    - gateway.networking.k8s.io/udproutes
    - infrastructure.cluster.x-k8s.io/deckhouseclusters
    - infrastructure.cluster.x-k8s.io/deckhousemachines
    - infrastructure.cluster.x-k8s.io/deckhousemachinetemplates
    - infrastructure.cluster.x-k8s.io/dynamixclusters
    - infrastructure.cluster.x-k8s.io/dynamixmachines
    - infrastructure.cluster.x-k8s.io/dynamixmachinetemplates
    - infrastructure.cluster.x-k8s.io/huaweicloudclusters
    - infrastructure.cluster.x-k8s.io/huaweicloudmachines
    - infrastructure.cluster.x-k8s.io/huaweicloudmachinetemplates
    - infrastructure.cluster.x-k8s.io/vcdclusters
    - infrastructure.cluster.x-k8s.io/vcdclustertemplates
    - infrastructure.cluster.x-k8s.io/vcdmachines
    - infrastructure.cluster.x-k8s.io/vcdmachinetemplates
    - infrastructure.cluster.x-k8s.io/zvirtclusters
    - infrastructure.cluster.x-k8s.io/zvirtmachines
    - infrastructure.cluster.x-k8s.io/zvirtmachinetemplates
    - limitranges
    - metrics.k8s.io/nodes
    - metrics.k8s.io/pods
    - multitenancy.deckhouse.io/availableclusterresources
    - mutations.gatekeeper.sh/assign
    - mutations.gatekeeper.sh/assignimage
    - mutations.gatekeeper.sh/assignmetadata
    - mutations.gatekeeper.sh/modifyset
    - namespaces
    - network.deckhouse.io/egressgatewaypolicies
    - network.deckhouse.io/egressgateways
    - network.deckhouse.io/metalloadbalancerbgppeers
    - network.deckhouse.io/metalloadbalancerclasses
    - network.deckhouse.io/metalloadbalancerconfigurations
    - network.deckhouse.io/metalloadbalancerpools
    - network.deckhouse.io/servicewithhealthchecks
    - networking.istio.io/destinationrules
    - networking.istio.io/gateways
    - networking.istio.io/serviceentries
    - networking.istio.io/sidecars
    - networking.istio.io/virtualservices
    - networking.istio.io/workloadentries
    - networking.istio.io/workloadgroups
    - networking.k8s.io/ingresses
    - networking.k8s.io/networkpolicies
    - nodes
    - persistentvolumeclaims
    - persistentvolumes
    - pods
    - pods/log
    - policy/poddisruptionbudgets
    - rbac.authorization.k8s.io/rolebindings
    - rbac.authorization.k8s.io/roles
    - replicationcontrollers
    - resourcequotas
    - security.istio.io/authorizationpolicies
    - security.istio.io/peerauthentications
    - security.istio.io/requestauthentications
    - serviceaccounts
    - services
    - status.gatekeeper.sh/configpodstatuses
    - status.gatekeeper.sh/connectionpodstatuses
    - status.gatekeeper.sh/constraintpodstatuses
    - status.gatekeeper.sh/constrainttemplatepodstatuses
    - status.gatekeeper.sh/expansiontemplatepodstatuses
    - status.gatekeeper.sh/mutatorpodstatuses
    - status.gatekeeper.sh/providerpodstatuses
    - storage.k8s.io/storageclasses
    - syncset.gatekeeper.sh/syncsets
    - telemetry.istio.io/telemetries
    - templates.gatekeeper.sh/constrainttemplates

Role PrivilegedUser (includes all rules from the role User):

create:
    - pods/eviction
create,get:
    - pods/attach
    - pods/exec
delete,deletecollection:
    - pods
read:
    - secrets

Role Editor (includes all rules from the role User, PrivilegedUser):

write:
    - apps/deployments
    - apps/statefulsets
    - autoscaling.k8s.io/verticalpodautoscalers
    - autoscaling/horizontalpodautoscalers
    - batch/cronjobs
    - batch/jobs
    - cert-manager.io/certificates
    - cert-manager.io/issuers
    - configmaps
    - deckhouse.io/dexauthenticators
    - deckhouse.io/dexclients
    - discovery.k8s.io/endpointslices
    - endpoints
    - extensions/deployments
    - extensions/ingresses
    - gateway.networking.k8s.io/backendtlspolicies
    - gateway.networking.k8s.io/gateways
    - gateway.networking.k8s.io/grpcroutes
    - gateway.networking.k8s.io/httproutes
    - gateway.networking.k8s.io/listenersets
    - gateway.networking.k8s.io/referencegrants
    - gateway.networking.k8s.io/tcproutes
    - gateway.networking.k8s.io/tlsroutes
    - gateway.networking.k8s.io/udproutes
    - network.deckhouse.io/servicewithhealthchecks
    - networking.istio.io/destinationrules
    - networking.istio.io/gateways
    - networking.istio.io/serviceentries
    - networking.istio.io/sidecars
    - networking.istio.io/virtualservices
    - networking.istio.io/workloadentries
    - networking.istio.io/workloadgroups
    - networking.k8s.io/ingresses
    - networking.k8s.io/networkpolicies
    - persistentvolumeclaims
    - policy/poddisruptionbudgets
    - secrets
    - security.istio.io/authorizationpolicies
    - security.istio.io/peerauthentications
    - security.istio.io/requestauthentications
    - serviceaccounts
    - services

Role Admin (includes all rules from the role User, PrivilegedUser, Editor):

create,patch,update:
    - pods
delete,deletecollection:
    - acme.cert-manager.io/challenges
    - acme.cert-manager.io/orders
    - apps/replicasets
    - cert-manager.io/certificaterequests
    - extensions/replicasets
read:
    - deckhouse.io/applicationpackages
    - deckhouse.io/applicationpackageversions
read-write:
    - deckhouse.io/authorizationrules
write:
    - autoscaling.k8s.io/verticalpodautoscalercheckpoints
    - deckhouse.io/applications
    - extensions.istio.io/wasmplugins
    - rbac.authorization.k8s.io/rolebindings
    - rbac.authorization.k8s.io/roles
    - telemetry.istio.io/telemetries

Role ClusterEditor (includes all rules from the role User, PrivilegedUser, Editor):

delete,deletecollection:
    - acme.cert-manager.io/challenges
    - acme.cert-manager.io/orders
    - cert-manager.io/certificaterequests
patch,update:
    - nodes
read:
    - deckhouse.io/applicationpackages
    - deckhouse.io/applicationpackageversions
    - deckhouse.io/containerdintegritypolicies
    - deckhouse.io/ingressistiocontrollers
    - deckhouse.io/istiofederations
    - deckhouse.io/istiomulticlusters
    - install.istio.io/istiooperators
    - multitenancy.deckhouse.io/grantableclusterresourcedefinitions
    - multitenancy.deckhouse.io/grantableclusterresourcereferences
    - rbac.authorization.k8s.io/clusterrolebindings
    - rbac.authorization.k8s.io/clusterroles
    - sailoperator.io/istiocnis
    - sailoperator.io/istiorevisions
    - sailoperator.io/istiorevisiontags
    - sailoperator.io/istios
    - sailoperator.io/ztunnels
read-write:
    - deckhouse.io/nodegroupconfigurations
    - deckhouse.io/staticinstances
    - multitenancy.deckhouse.io/clusterresourcegrantpolicies
write:
    - apiextensions.k8s.io/customresourcedefinitions
    - apps/daemonsets
    - autoscaling.k8s.io/verticalpodautoscalercheckpoints
    - cert-manager.io/clusterissuers
    - deckhouse.io/applications
    - deckhouse.io/hubblemonitoringconfigs
    - deckhouse.io/instances
    - deckhouse.io/keepalivedinstances
    - deckhouse.io/nodegroups
    - extensions.istio.io/wasmplugins
    - extensions/daemonsets
    - gateway.networking.k8s.io/gatewayclasses
    - network.deckhouse.io/egressgatewaypolicies
    - network.deckhouse.io/egressgateways
    - storage.k8s.io/storageclasses
    - telemetry.istio.io/telemetries

Role ClusterAdmin (includes all rules from the role User, PrivilegedUser, Editor, Admin, ClusterEditor):

create:
    - deckhouse.io/dexauthenticators/allow-access-to-kubernetes
    - deckhouse.io/dexclients/allow-access-to-kubernetes
delete,deletecollection,get,list,patch,update,watch:
    - machine.sapcloud.io/alicloudmachineclasses
    - machine.sapcloud.io/awsmachineclasses
    - machine.sapcloud.io/azuremachineclasses
    - machine.sapcloud.io/gcpmachineclasses
    - machine.sapcloud.io/machinedeployments
    - machine.sapcloud.io/machines
    - machine.sapcloud.io/machinesets
    - machine.sapcloud.io/openstackmachineclasses
    - machine.sapcloud.io/packetmachineclasses
    - machine.sapcloud.io/vspheremachineclasses
    - machine.sapcloud.io/yandexmachineclasses
get,list,patch,update,watch:
    - control-plane.deckhouse.io/controlplanenodes
patch,update:
    - deckhouse.io/vcdaffinityrules
    - infrastructure.cluster.x-k8s.io/deckhouseclusters
    - infrastructure.cluster.x-k8s.io/deckhousemachines
    - infrastructure.cluster.x-k8s.io/deckhousemachinetemplates
    - infrastructure.cluster.x-k8s.io/dynamixclusters
    - infrastructure.cluster.x-k8s.io/dynamixmachines
    - infrastructure.cluster.x-k8s.io/dynamixmachinetemplates
    - infrastructure.cluster.x-k8s.io/huaweicloudclusters
    - infrastructure.cluster.x-k8s.io/huaweicloudmachines
    - infrastructure.cluster.x-k8s.io/huaweicloudmachinetemplates
    - infrastructure.cluster.x-k8s.io/vcdclusters
    - infrastructure.cluster.x-k8s.io/vcdclustertemplates
    - infrastructure.cluster.x-k8s.io/vcdmachines
    - infrastructure.cluster.x-k8s.io/vcdmachinetemplates
    - infrastructure.cluster.x-k8s.io/zvirtclusters
    - infrastructure.cluster.x-k8s.io/zvirtmachines
    - infrastructure.cluster.x-k8s.io/zvirtmachinetemplates
    - machine.sapcloud.io/machinedeployments/scale
proxy:
    - nodes
read:
    - cluster.x-k8s.io/machinedrainrules
    - control-plane.deckhouse.io/controlplaneoperations
    - infrastructure.cluster.x-k8s.io/deckhousecontrolplanes
    - infrastructure.cluster.x-k8s.io/staticclusters
    - infrastructure.cluster.x-k8s.io/staticmachines
    - nfd.k8s-sigs.io/nodefeaturegroups
    - nfd.k8s-sigs.io/nodefeaturerules
    - nfd.k8s-sigs.io/nodefeatures
read-write:
    - cluster.x-k8s.io/clusters
    - cluster.x-k8s.io/machinedeployments
    - cluster.x-k8s.io/machinehealthchecks
    - cluster.x-k8s.io/machinepools
    - cluster.x-k8s.io/machines
    - cluster.x-k8s.io/machinesets
    - deckhouse.io/clusterauthorizationrules
    - deckhouse.io/deckhousereleases
    - deckhouse.io/dexproviderchecks
    - deckhouse.io/dexproviders
    - deckhouse.io/groups
    - deckhouse.io/moduleconfigs
    - deckhouse.io/moduledocumentations
    - deckhouse.io/modulepulloverrides
    - deckhouse.io/modulereleases
    - deckhouse.io/modules
    - deckhouse.io/modulesources
    - deckhouse.io/moduleupdatepolicies
    - deckhouse.io/nodeusers
    - deckhouse.io/packagerepositories
    - deckhouse.io/packagerepositoryoperations
    - deckhouse.io/sshcredentials
    - deckhouse.io/useraccounts
    - deckhouse.io/useroperations
    - deckhouse.io/users
    - infrastructure.cluster.x-k8s.io/staticmachinetemplates
    - nodes/configz
    - nodes/healthz
    - nodes/log
    - nodes/metrics
    - nodes/pods
    - nodes/proxy
    - nodes/stats
write:
    - cilium.io/ciliumclusterwidenetworkpolicies
    - cilium.io/ciliumnetworkpolicies
    - cluster.x-k8s.io/machinedeployments/scale
    - config.gatekeeper.sh/configs
    - connection.gatekeeper.sh/connections
    - constraints.gatekeeper.sh/*
    - deckhouse.io/applicationpackages
    - deckhouse.io/applicationpackageversions
    - deckhouse.io/awsinstanceclasses
    - deckhouse.io/azureinstanceclasses
    - deckhouse.io/containerdintegritypolicies
    - deckhouse.io/deschedulers
    - deckhouse.io/dvpinstanceclasses
    - deckhouse.io/dynamixinstanceclasses
    - deckhouse.io/gcpinstanceclasses
    - deckhouse.io/huaweicloudinstanceclasses
    - deckhouse.io/ingressistiocontrollers
    - deckhouse.io/istiofederations
    - deckhouse.io/istiomulticlusters
    - deckhouse.io/localpathprovisioners
    - deckhouse.io/openstackinstanceclasses
    - deckhouse.io/operationpolicies
    - deckhouse.io/projects
    - deckhouse.io/projecttemplates
    - deckhouse.io/securitypolicies
    - deckhouse.io/securitypolicyexceptions
    - deckhouse.io/vcdinstanceclasses
    - deckhouse.io/vsphereinstanceclasses
    - deckhouse.io/yandexinstanceclasses
    - deckhouse.io/zvirtinstanceclasses
    - expansion.gatekeeper.sh/expansiontemplate
    - externaldata.gatekeeper.sh/providers
    - install.istio.io/istiooperators
    - limitranges
    - mutations.gatekeeper.sh/assign
    - mutations.gatekeeper.sh/assignimage
    - mutations.gatekeeper.sh/assignmetadata
    - mutations.gatekeeper.sh/modifyset
    - namespaces
    - network.deckhouse.io/metalloadbalancerbgppeers
    - network.deckhouse.io/metalloadbalancerclasses
    - network.deckhouse.io/metalloadbalancerconfigurations
    - network.deckhouse.io/metalloadbalancerpools
    - rbac.authorization.k8s.io/clusterrolebindings
    - rbac.authorization.k8s.io/clusterroles
    - resourcequotas
    - sailoperator.io/istiocnis
    - sailoperator.io/istiorevisions
    - sailoperator.io/istiorevisiontags
    - sailoperator.io/istios
    - sailoperator.io/ztunnels
    - status.gatekeeper.sh/configpodstatuses
    - status.gatekeeper.sh/connectionpodstatuses
    - status.gatekeeper.sh/constraintpodstatuses
    - status.gatekeeper.sh/constrainttemplatepodstatuses
    - status.gatekeeper.sh/expansiontemplatepodstatuses
    - status.gatekeeper.sh/mutatorpodstatuses
    - status.gatekeeper.sh/providerpodstatuses
    - syncset.gatekeeper.sh/syncsets
    - templates.gatekeeper.sh/constrainttemplates

You can get additional list of access rules for module role from cluster (existing user defined rules and non-default rules from other deckhouse modules):

D8_ROLE_NAME=Editor
kubectl get clusterrole -A -o jsonpath="{range .items[?(@.metadata.annotations.user-authz\.deckhouse\.io/access-level=='$D8_ROLE_NAME')]}{.rules}{'\n'}{end}" | jq -s add