Role-Based Access Control (RBAC)

Role-Based Access Control (RBAC) is a security method that restricts resources access to authorized users based on their assigned roles. In SUSE Multi-Linux Manager, RBAC ensures that users can only perform actions and access resources for which they have explicit authorization, enhancing security and simplifying administration.

The core principles of RBAC include:

Principle of Least Privilege: Granting only the necessary access rights for users to perform their tasks.
Granular Control: Providing fine-grained control over specific functionalities.
Separation of Duties: Preventing a single user from having too much control over critical processes.
Auditability: Allowing for clear tracking of user actions and permissions.

1. Architectural scope

In SUSE Multi-Linux Manager, RBAC controls only the Web UI and the SUSE Multi-Linux Manager API (XML-RPC and JSON-RPC) layers. The RBAC engine controls access to these interfaces.

RBAC does not control the native authentication of the Salt API (salt-api or eauth) for external users. The Salt API is an internal service. The system permits access to the Salt API port (port 9080) only from the internal loopback interface of the SUSE Multi-Linux Manager Server. Only Tomcat and Taskomatic services on the server can use the Salt API. External users cannot log in to the Salt API directly. Instead, SUSE Multi-Linux Manager authenticates the user, checks their RBAC permissions, and then runs Salt commands on behalf of the user. For more information about native Salt authentication and command-line access controls, see Salt Access Control.

2. Key RBAC concepts

Understanding the following core concepts is crucial for effective RBAC management:

Role: A collection of permissions defining a specific set of capabilities within SUSE Multi-Linux Manager. Roles are assigned to users, granting the user aggregated permissions.

Roles are assigned to users, granting the user aggregated permissions.
Permission: An atomic authorization to perform a specific action, access a specific web page or call a specific API endpoint within SUSE Multi-Linux Manager. In SUSE Multi-Linux Manager, permissions are represented by namespaces and their access modes.
User: An individual account that interacts with SUSE Multi-Linux Manager. Users are assigned one or more roles.
Namespace: A granular unit of access control organized in a tree-like structure. Most namespaces have distinct "View" or "Modify" modes.

3. User roles in SUSE Multi-Linux Manager

SUSE Multi-Linux Manager provides predefined roles and allows for the definition of additional custom roles, optionally inheriting from a combination of other roles.

3.1. Predefined roles

Refer to administration:users.adoc#administrator-roles for a complete list of predefined roles and their descriptions.

3.2. Defining additional roles

To define additional roles, you can:

Select a number of existing roles to inherit permissions from.
Specify additional namespaces to grant access to.

4. Namespaces for fine-grained access

Namespaces provide fine-grained access control, organized in a tree-like structure. For most namespaces, access within a namespace is further granularized by "View" and "Modify" modes.

Table 1. Example: Image Management namespaces and access modes
Namespace	Access Mode	Description
`cm.build`	Modify	Build container or Kiwi images
`cm.image.import`	Modify	Import container images from a registered image store
`cm.image.list`	View	List all images
`cm.image.list`	Modify	Delete images
`cm.image.overview`	View	View image details, patches, packages, build log and cluster information
`cm.image.overview`	Modify	Inspect, rebuild, delete images
`cm.profile.details`	View	View details of an image profile
`cm.profile.details`	Modify	Create image profiles, edit profile details
`cm.profile.list`	View	List all image profiles
`cm.profile.list`	Modify	Delete image profiles
`cm.store.details`	View	View details of an image store
`cm.store.details`	Modify	Create image stores, edit store details
`cm.store.list`	View	List all image stores
`cm.store.list`	Modify	Delete image stores

Table 2. Example: Salt namespaces and access modes
Namespace	Access Mode	Description
`salt.remote_commands`	Modify	Execute remote commands on systems through the Web UI (Salt Remote Commands)
`salt.keys`	View	View Salt client keys (Salt Keys)
`salt.keys`	Modify	Accept, reject, or delete Salt client keys
`salt.formulas`	View	View formula catalog and formula configuration data (Salt Formula Catalog)
`api.ansible.fetch_playbook_contents`	Modify	Fetch playbook content from the control node using a synchronous Salt call
`api.configchannel.sync_salt_files_on_disk`	Modify	Synchronize all files on disk to the current state of the database
`api.proxy.bootstrap_proxy`	Modify	Deploy a proxy container on a given Salt client
`api.saltkey.accept`	Modify	Accept a Salt client key through the API
`api.saltkey.accepted_list`	View	List accepted Salt keys through the API
`api.saltkey.delete`	Modify	Delete a Salt client key through the API
`api.saltkey.denied_list`	View	List denied Salt keys through the API
`api.saltkey.pending_list`	View	List pending Salt keys through the API
`api.saltkey.reject`	Modify	Reject a Salt client key through the API
`api.saltkey.rejected_list`	View	List rejected Salt keys through the API
`api.system.bootstrap`	Modify	Bootstrap a client system for Salt or Salt SSH management
`api.system.bootstrap_with_private_ssh_key`	Modify	Bootstrap a system for Salt or Salt SSH management using a private SSH key
`api.system.get_minion_id_map`	View	Retrieve a mapping between Salt minion identifiers and system identifiers

A comprehensive list of namespaces and their descriptions can be retrieved by making a call to the access.listNamespaces API method. Refer to SUSE Multi-Linux Manager API documentation for detailed information, including request and response formats.

5. Managing RBAC

Managing RBAC roles and permissions is possible either through the API or through the Web UI. To assign roles to users via the Web UI, refer to Users.

5.1. Managing RBAC via Web UI

In the Web UI, you can manage custom RBAC roles and assign permissions by navigating to Admin Access Control. From there, you can click Create Access Group to define a new role and configure its permissions. For more information about configuring access groups, see Access Group Management.

Predefined roles cannot be seen or managed via the Web UI. Only custom roles created within your organization are visible in the Admin Access Control section.

5.2. Managing RBAC via API

The SUSE Multi-Linux Manager API provides methods for programmaticaly managing roles, permissions and user assignments.

5.2.1. The `access` API

These API methods manage roles and their associated access:

listNamespaces: Lists available namespaces, access modes and their descriptions in SUSE Multi-Linux Manager.
listPermissions: Lists permitted namespaces of a role.
listRoles: Lists existing roles in SUSE Multi-Linux Manager.
createRole: Creates a new role, optionally copying permissions from existing roles.
deleteRole: Deletes a role.
grantAccess: Grants access to namespaces.
revokeAccess: Revokes access to namespaces.

5.2.2. The `user` API

These API methods manage user-role assignments:

listPermissions: Lists effective permissions of a user.
listRoles: Lists a user’s assigned roles.
addRole: Assigns a role to a user.
removeRole: Removes a role from a user.

For detailed API documentation, including request and response formats, refer to SUSE Multi-Linux Manager API reference.

6. RBAC best practices

Adhering to these best practices will help maintain a secure, efficient, and manageable RBAC environment:

Principle of least privilege: Always grant users the minimum permissions necessary to perform their duties. Avoid overly broad permissions.
Regular review: Periodically review assigned roles and permissions for users to ensure they are still appropriate and comply with current security policies.
Document roles: Clearly document the purpose and permissions of each custom role you create.
Separate duties: Implement roles that enforce separation of duties to prevent a single user from having too much control over critical processes.