One key security feature for data management is providing different levels of access to different sets of users. NetApp® ONTAP® data management software supports role-based access control, where different administrators have different levels of access to the system. Access to commands is granted to different roles, then users are assigned to a role. The built-in roles are suited for most needs, but you can also configure your own custom roles.
A privilege defines the access level of the API or command/command directory path. If a privilege tuple refers to a command/command directory path, it can also be associated with an optional query.
Administrators can be authenticated by either the local user database, by an NIS or LDAP server, or by Active Directory. Administrators can be granted the same or different levels of access depending on whether they're connecting to the console, GUI, command line, API (for if you have other software that is integrating with ONTAP), or Service Processor.
With ONTAP 9.11.1, ONTAP REST has major enhancements in configuring Role based access control (RBAC). Previously, customer can leverage traditional roles created through CLI and Rest roles created through API in the respective environment. With 9.11.1, users can leverage the traditional roles created through CLI via API as well.
Cluster administrators can configure the entire cluster, including its storage virtual machines. Each SVM also has a separate administrator authentication domain and can be managed independently by its own administrators.
For example, if we have the Department A SVM and the Department B SVM, we have three different administrative domains:
- Department A administrators can configure the Department A SVM resources.
- Department B administrators can configure the Department B SVM resources.
- Cluster administrators can configure the entire cluster, including Department A and Department B.
Privileges of cluster scoped roles
|Cluster scoped role||Privilege|
|Admin||Unrestricted rights. Administrators with this role can do anything on the system. They can configure all the cluster-level resources and all the SVM-level resources.|
|Autosupport||Special role for the AutoSupport account.|
|Backup||Special role for backup software that backs up the system at the cluster level.|
|Readonly||Administrators with this role can view everything at the cluster level, but they can't make any changes.|
|None||No administrative capabilities.|
Users can create custom roles if the default roles don’t meet their needs. When configuring a custom role, the commands and command directories not specified hold access level as the default level of none. That role has no access to unspecified commands or command directories.
Create rest-role through the CLI
metropolitan::> security login rest-role create -vserver metropolitan -role new_role -api /api/storage/volumes -access read_create_modify
metropolitan::> security login rest-role show -role new_role
Vserver Role Name Access API Level
------------ ------------- ---------------------- ------------------
metropolitan new_role /api/storage/volumes read_create_modify
Create rest-role through ONTAP REST APIs
With ONTAP REST 9.11.1, almost all REST APIs map to one or more CLI commands. When a REST role is created using a POST method request on /api/security/roles, a mapped legacy role is created. This legacy role has the same access levels (as that of the REST API) for the mapped CLI commands. However, if a legacy role with the same name already exists, the POST operation fails and you need to choose a unique name for the REST role. Before REST APIs, the RBAC legacy roles were defined to contain the CLI commands and their access levels. Starting with ONTAP 9.11.1, legacy roles can also be managed using the REST endpoint /api/security/roles and its derivatives.
New access levels for REST roles:
Display legacy and rest-roles
Users can retrieve the configured roles at the cluster and SVM levels. All of the predefined and custom roles or a filtered list of roles (for example by name, predefined, and so on) can be retrieved.
Simplified Role based access
Automatic addition of “vserver web access” entries for “rest”, “sysmgr” and “security” for any new role created. This reduces 1 or 2 configuration steps when a legacy role is used for REST access. Before ONTAP 9.11.1, following commands were required to be able to use legacy role for REST access.
metropolitan::*> vserver services web access create -name rest -role cln_legacy_role -vserver rvijaycluster-1
metropolitan::*> vserver services web access create -name security -role cln_legacy_role -vserver rvijaycluster-1
Also, following command was required to use legacy role for REST access from System Manager (new experience)
metropolitan::*> vserver services web access create -name sysmgr -role cln_legacy_role -vserver rvijaycluster-1
The above steps are not required from ONTAP 9.11.1 onwards (to use legacy role for REST access) since these entries are added automatically.
With ONTAP 9.11.1, A legacy/REST role created through CLI can be managed through REST API as well. Likewise, a REST/legacy role created through REST API can be managed through CLI as well. Also, REST APIs has new filtering fields such as privileges.query, comments.
The mapped legacy role (for the REST API role created) cannot be manipulated using either REST API or the CLI. The reverse case is not true. The creation of a legacy role will not create a mapped role with equivalent REST APIs.
To learn more, visit https://devnet.netapp.com/restapi.php