Integration with Rancher RBAC
Starting with SUSE® Security 5.4, full compatibility and integration of SUSE® Security with Rancher RBAC has been included. This offers users the possibility of customizing specific permissions based on the profile of the user or group that should access SUSE® Security.
In the Rancher console, Users & Authentication → Role Templates page, customers can create Global, Cluster, Project, and Namespace roles with specific SUSE® Security Verbs, Resources, and API Groups. When such a Rancher role is assigned to a Rancher user, the user’s SUSE® Security SSO session is assigned different SUSE® Security permissions accordingly. This is to provide SSO users with custom roles (that is, roles other than the reserved admin, reader, fedAdmin, and fedReader roles).
Supported custom SUSE® Security role mapping in Rancher SSO
Below are supported role mappings for SUSE® Security Verbs, Resources, and API Groups used in the Rancher UI at Users & Authentication → Role Templates → Create Global, Cluster, or Project Role Template.
-
APIGroup:
permission.neuvector.com -
Verbs:
-
get→ read-only (view) -
*→ read/write (modify)
-
-
Resources (cluster-scoped):
-
AdmissionControl
-
Authentication
-
CI Scan
-
Cluster
-
Federation
-
Vulnerability
-
-
Resources (namespaced):
-
AuditEvents
-
Authorization
-
Compliance
-
Events
-
Namespace
-
RegistryScan
-
RuntimePolicy
-
RuntimeScan
-
SecurityEvents
-
SystemConfig
-
Resource display and logical name mapping
The following table illustrates the logical names of resources.
| Resource display | Logical name |
|---|---|
All Permissions |
nv-perm.all-permissions |
Admission Control |
nv-perm.admctrl |
Audit Events |
nv-perm.audit-events |
Authentication |
nv-perm.authentication |
Authorization |
nv-perm.authorization |
CI Scan |
nv-perm.ci-scan |
Compliance |
nv-perm.compliance |
Events |
nv-perm.events |
Federation |
nv-perm.fed |
Registry Scan |
nv-perm.reg-scan |
Runtime Policy |
nv-perm.rt-policy |
Runtime Scan |
nv-perm.rt-scan |
Security Events |
nv-perm.security-events |
System Config |
nv-perm.config |
Vulnerability Profile |
nv-perm.vulnerability |
|
This integration supports roles at the Global, Cluster, Project, and Namespace levels. Users must customize and create rules based on their requirements and scope permissions for SSO. |
Definitions and expectations with Global, Cluster, and Project/Namespace roles
-
Cluster resource with
*verb on a Rancher Global role:-
Mapped to the SUSE® Security
fedAdminrole on the SUSE® Security federation master cluster (Users cannot map a Rancher Global role to a SUSE® Securityadminrole when SUSE® Security is deployed on a federation master cluster.) -
Mapped to the SUSE® Security
adminrole on SUSE® Security federation-managed clusters
-
-
Cluster resource with
*verb on Rancher Cluster roles:-
Always mapped to the SUSE® Security
cluster-adminrole
-
-
Namespace resource with
*verb on Rancher Project roles:-
Always mapped to the SUSE® Security
namespace-adminrole
-
Use cases and examples
Use case 1
-
Use a Global role to run runtime scans from a SUSE® Security SSO session on all clusters managed by Rancher Manager except the local cluster. Users must create Cluster roles to propagate the Global role to all downstream clusters.
-
Create a Cluster role template with the following parameters:
Verb: * Resource: RuntimeScan API: permission.neuvector.com -
Create a Project or Namespace role to allow UI access and enable SSO. You must add this role to the project for it to work correctly:
Verb: get, patch, create Resource: services/proxy API: neuvector.com -
Create a Global role to inherit the Cluster role across downstream clusters:
apiVersion: management.cattle.io/v3 kind: GlobalRole displayName: All Downstream NV RT scan metadata: name: all-downstream-nvrtscan inheritedClusterRoles: - rt-gpmbs -
Create a standard user and assign the Global role.
-
Create a Project role binding on all downstream clusters for the project that contains the
cattle-neuvector-systemnamespace. -
Log in to Rancher Manager and launch SUSE® Security from any downstream cluster. The user can perform runtime scan tasks such as container scans, node scans, and browsing vulnerability pages. This also applies to newly joined clusters.
-
Use case 2
-
Create a FedAdmin user. Always log in as a FedAdmin through the federation master cluster. If the environment is not federated, roles are downgraded to Reader or Admin.
-
Create a Global role:
Verb: * Resource: All permissions API: nv-perm.all-permissions -
Create a Project or Namespace role to allow UI access and enable SSO:
Verb: get, patch, create Resource: services/proxy API: neuvector.com -
Create a standard user and assign the Global role.
-
In the Rancher UI, go to Master Cluster → Cluster and Project Members → Project Membership → Add. Add the user and assign the UI proxy project role.
-
Log in to Rancher Manager and launch SUSE® Security from a downstream cluster. SUSE® Security reads the Rancher Global role and assigns the matching permission (FedAdmin).
-
|
To switch between FedAdmin and FedReader, change the verb from |
Use case 3
A user can perform a limited set of read-only tasks and modify a limited set of tasks on a cluster.
Additional considerations
-
Use this documentation and parameters as a reference when creating SSO and RBAC rules.
-
For errors or advanced use cases, contact SUSE Support through SCC.
-
SUSE® Security 5.4 is backward compatible with pre-5.4 SSO role mappings. For the previous structure, see https://github.com/horantj/rancher-nv-rbac.
Starting with SUSE® Security 5.4, full compatibility and integration of SUSE® Security with Rancher RBAC has been included. This offers users the possibility of customizing specific permissions based on the profile of the user or group that should access SUSE® Security.
In the Rancher console, Users & Authentication → Role Templates page, customers can create Global, Cluster, Project, and Namespace roles with specific SUSE® Security Verbs, Resources, and API Groups. When such a Rancher role is assigned to a Rancher user, the user’s SUSE® Security SSO session is assigned different SUSE® Security permissions accordingly. This is to provide SSO users with custom roles (that is, roles other than the reserved admin, reader, fedAdmin, and fedReader roles).