基于角色的访问控制 (RBAC)

基于角色的访问控制 (RBAC) 是一种安全机制，它根据用户被分配的角色来限制授权用户对资源的访问权限。在 SUSE Multi-Linux Manager 中，RBAC 可确保用户仅能执行其获得明确授权的操作以及访问相关资源，从而提升安全性并简化管理流程。

RBAC 的核心原则包括：

最小权限原则：仅授予用户执行其任务所需的必要访问权限。
精细化控制：针对特定功能提供精细的控制能力。
职责分离：防止单个用户对关键流程拥有过多控制权。
可审计性：能够清晰跟踪用户的操作及权限配置。

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

理解以下核心概念对于高效管理 RBAC 至关重要：

Role: A collection of permissions defining a specific set of capabilities within SUSE Multi-Linux Manager.

角色分配给用户后，用户将获得该角色对应的所有聚合权限。
权限：原子级的授权项，允许用户在 SUSE Multi-Linux Manager 中执行特定操作、访问特定网页或调用特定 API 端点。在 SUSE Multi-Linux Manager 中，权限通过名称空间及其访问模式来表示。
用户：与 SUSE Multi-Linux Manager 进行交互的个人帐户。用户可被分配一个或多个角色。
名称空间：粒度化的访问控制单元，以树形结构组织。大多数名称空间均设有独立的“查看”或“修改”模式。

3. User roles in SUSE Multi-Linux Manager

SUSE Multi-Linux Manager 提供了预定义角色，并允许您定义额外的自定义角色，且可选择从多个其他角色的组合继承权限。

3.1. Predefined roles

有关预定义角色及其说明的完整列表，请参见 administration:users.adoc#administrator-roles。

3.2. Defining additional roles

要定义额外角色，您可以执行以下操作：

选择多个现有角色，从中继承权限。
指定额外的名称空间，以授予访问权限。

4. Namespaces for fine-grained access

名称空间提供精细的访问控制，以树形结构组织。对于大多数名称空间，其内部访问权限可通过“查看”和“修改”模式进一步细化。

Table 1. 示例：映像管理相关名称空间和访问模式
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. 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 用户.

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 访问组管理.

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. 通过 API 管理 RBAC

SUSE Multi-Linux Manager API 提供了以编程方式管理角色、权限及用户分配的相关方法。

5.2.1. The `access` API

以下 API 方法用于管理角色及其关联的访问权限：

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

以下 API 方法用于管理用户与角色的分配关系：

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.

有关详细的 API 文档（包括请求和响应格式），请参见 SUSE Multi-Linux Manager API 参考手册。

6. RBAC best practices

遵循以下最佳实践有助于维护安全、高效且易于管理的 RBAC 环境：

最小权限原则：始终仅授予用户完成其职责所需的最低权限，避免授予过于宽泛的权限。
定期审查：定期审查用户分配到的角色和权限，确保其仍然适用且符合当前的安全策略。
记录角色：为您创建的每个自定义角色清晰记录其用途和权限。
职责分离：设计并应用能够强制执行职责分离的角色，防止单个用户对关键流程拥有过多控制权。