In this NetApp training tutorial, I will cover the Role Based Access Control (RBAC). Scroll down for the video and also text tutorial.
NetApp RBAC Role Based Access Control Video Tutorial
NetApp RBAC Role Based Access Control
ONTAP supports Role Based Access Control where different administrators have different levels of access to the system. The setup is similar with how it’s done on other vendor’s systems, so if you’ve configured RBAC on anything before this should look pretty familiar to you.
Access to commands is granted to different roles, then users are assigned to a role. There are built-in roles included, which would be suited for most needs, but you can also configure your own custom roles.
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.
Cluster and SVM Level Role Based Access Control
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 would have three different administrative domains. Department A administrators could configure the Department A SVM resources. Department B administrators could configured department B. Cluster administrators could configure the entire cluster, including Department A and Department B. Only Cluster Administrators can use the System Manager GUI while the SVM administrators can use the command line or API.
Cluster Scoped Roles
The Cluster-Scoped roles are:
A user with the Admin role has unrestricted rights, they can do anything on the system. They can configure all the cluster level resources and all the SVM level resources.
Autosupport is a special role for (not surprisingly) the auto support account, and Backup is another special role which is for backup software that will be backing up the system at the cluster level.
The Readonly role is pretty self-explanatory. Administrators with this role can view everything at the cluster level but they can’t make any changes.
The last cluster-scoped role is None which has no administrative capabilities.
You can create your own custom roles if the default ones do not meet your needs. When you configure a custom role, the commands and command directories for which you do not specify and access level have the default level of none, and the role has no access to unspecified commands or command directories.
Data SVM Scoped Roles
There are five default Data SVM-scoped roles:
vsadmin is the super user account at the SVM level. Administrators with this role can manage the resources for that SVM but they can’t manage cluster-level resources. Users with the vsadmin role can manage their own user accounts. They can manage volumes, qtrees and LUNs in their SVM. They can configure the NAS and SAN protocols and services such as DNS and monitor the SVM resources.
vsadmin-volume is similar to the vsadmin role, but not quite as powerful. It can’t manage accounts. If an administrator has the vsadmin-volume role, they can manage volumes, qtrees, and LUNs, configure NAS and SAN protocols, configure services, and monitor the SVM.
Administrators with the vsadmin-protocol role can configure services, monitor the SVM and configure NAS and SAN protocols.
vsadmin-readonly role is pretty self-explanatory again. These administrators can monitor the SVM resources, view volumes and LUNs, view services and protocols, but they can’t configure them.
Lastly, the vsadmin-backup role is designed for backup software which accesses the cluster at the SVM level. The cluster-scope backup role can view and backup the cluster as a whole. The SVM scope backup role can only view and backup that particular SVM.
You can also create custom roles at the SVM level.
RBAC will typically use Active Directory for its user database. You don’t want to manage a separate database for your NetApp administrators, it will be more convenient if they can login using their normal AD user name and password. If a cluster already has a data SVM with CIFS configured, then you can use it as an authentication tunnel. If a cluster does not have a data SVM with CIFs already configured, then you can join any data SVM to the domain and use it as the authentication tunnel without the need for a CIFs license.