Role-based access control

Role-based access control (RBAC) is a security feature that allows a security administrator to grant granular permissions to a user. A user can be allowed or denied permission to run operations at the resource level. For example, a user can be granted permission to operate only on a specific file system or fileset. It is enabled when the IBM Storage Scale native REST API feature is deployed.

IBM Storage Scale includes one predefined user, root, and one predefined role, SecurityAdmin. By default, only the root user can run the initial scalectl commands to configure node identities and create the cluster. To allow a non-privileged user to perform the initial setup, run the /usr/lpp/mmfs/bin/scaleuseraddrbac script to allow the user to create the node identities and create the cluster. This script grants the specified user the SecurityAdmin role, which allows full access to all API endpoints. The script must be run before the cluster is created. The assigned user retains SecurityAdmin privileges unless explicitly removed.

Domains provide logical groupings of memberships, permissions, and resources that are required for IBM Storage Scale components to function correctly. If needed, you can assign additional users to the predefined SecurityAdmin role that is included with IBM Storage Scale. If no domain is specified in scalectl --domain or the REST header X-StorageScaleDomain, the StorageScaleDomain is used by default. The default StorageScaleDomain cannot be deleted.

The following core components implement RBAC:
Domain

A logical grouping of resources, users or roles, and actions. No built-in restrictions on which resources can be included in a domain.

Resources
A resource is represented as a URL endpoint. A resource can be a file system, fileset, disk, or NSD. A wildcard (*) is used to match any resource. For example, /scalemgmt/v3/filesystems/fs0/filesets/* matches any filesets in the fs0 file system for the specified action.
Actions

Actions are the various operations that can be done on a resource. Not all actions apply to every resource. Supported actions are create, delete, get, list, update, link, unlink, mount, unmount, and cani or impersonate.

User
The person who makes the request.
Effect
Defines whether access is allowed or denied. The rule evaluation follows these conditions:
  • By default, set to Deny.
  • The system checks for an allow rule that matches the request.
  • If an explicit deny rule exists, it overrides an allow rule.
  • To grant permission, there must be an explicit allow rule without a conflicting deny rule.
  • Deny rules are useful when using wildcards (*) to allow all actions except those explicitly denied.
Membership
The relationship between a user and their role within a domain.
Permission
The relationship between a role, action, effect, and resource within a domain.

Domain filtering in the RBAC

RBAC uses the domain specified in a request to determine whether a user has permission to access a resource. If a user has permission in a domain, they can create resources in that domain. No additional domain checks occur during creation. After a resource is created, only users with permission in the same domain can perform actions such as get, list, update, or delete on the resources. This behavior is known as domain filtering.

For example,
  • If a user has delete permissions for wildcard Delete /scalemgmt/v3/filesystems/* resources in domain1, they can delete only the file system in domain1 and not in domain2. To delete a file system in domain2, the user must have explicit delete permissions for /scalemgmt/v3/filesystems/* in domain2.

When a user creates a resource, that resource is associated with the domain in which the user was authorized. To perform actions such as get, list, update, or delete, the user must have permission for the endpoint in the same domain as the resource.

When a user lists resources, they see only those associated with their domain. If an administrator grants a user wildcard GET /scalemgmt/v3/filesystems permissions, the user can view only the file systems in their domain. This filtering enforcement allows administrators to grant broad permissions while restricting access to resources from other domains. This also applies when creating sub-resources that depend on others.

For example,
  • If userA in domainA creates NSDs, those NSDs belong to domainA. If userB in domainB tries to create a file system using those NSDs, they appear as non-existent because they are filtered from view. Similarly, if userB lists NSDs, they see only the NSDs in domainB.
The following operations are exception to this domain filtering:
Creation of fileset
If a user has permission to create a fileset in a specific file system, the creation is allowed, even if the file system belongs to another domain. This exception is allowed because the fileset creation is a common and requiring a filesystem per domain is often impractical.
Clear ID of NSDs
If a user has permission to clear ID of NSDS ( DELETE /scalemgmt/v3/troubleshooting/nsds/clearId), they can affect all devices. This operation is highly privileged, intended for recovery scenarios only. Use this resources only if the NSD was successfully deleted but failed to clear the ID from the disk. Since the NSD no longer exists, domain filtering is skipped. The administration daemon ensures that the NSD does not exist before allowing this command, so it cannot be run against defined NSDs.

You can manage domains and policy rules by using the scalectl command or REST API. The default policy file allows basic RBAC rules. If the user has permission for an endpoint, they can run the scalectl authorization commands or use authorization API endpoints to create or manage the domains. For more information, see scalectl authorization command or Authorization endpoints.