Most Netapp environments do not take advantage of multiple user accounts and passwords. On a Netapp filer, only one user at a time is allowed access to a command line prompt, and the number of administrators in the enterprise is usually small. It's also hard to do something destructive, because certain commands will prompt for confirmation, or some bad actions can be reverted back to a safe state. It's safe to say that anyone capable of logging onto a Netapp is likely to be someone that properly knows how to administer it.
With an environment that simple, administrators usually stick to the "root" username and password for authentication. There's nothing wrong with that, if the administrator is the only one that will be running commands. But there are certain jobs non-administrators may want to run on their own. What if the provisioning manager wants to give VMWare the ability to create new volumes? What if the application developer wants to create automatic snapshots of a filesystem during a backup process? The Netapp API allows more remote tools to manipulate a filer, reducing administrative overhead, but increasing the risk of compromised security.
Netapp provides rudimentary role based access controls through the "useradmin" command. The useradmin command lets you add new local user accounts, local groups, and restricted roles that define how a user can log in to the filer, and what commands the user is allowed to run.
If you had a user that needed to manually initiate a snapmirror update process, you could create a role, group, and user account as follows.
filer> useradmin role add mirror_role -a login-ssh,cli-snapmirror-update
filer> useradmin group add mirrorusers -r mirror_role
filer> useradmin user add bob -g mirrorusers
New password: *******
Retype new password: ********
Now the user account "bob" is able to log in through SSH and run the snapmirror update command. Bob cannot tamper with volumes, modify the network interfaces, or alter his own access levels. You could also set up an SSH key for Bob, so you're not forced to rely on password authentication. The RBAC mechanism also provides a logging mechanism for failures if a user sends the wrong command.
Tue Oct 21 13:18:00 CDT [useradmin.unauthorized.user:warning]: User 'bob' denied access - missing required capability: 'cli-vol-options'
User accounts can belong to multiple groups, and a group to contain multiple roles, so you don't have to tie one user to a particular group or set of roles.
The entries "cli-snapmirror-update" and "login-ssh" are capabilities in Netapp nomenclature. All capabilities are broken up by their major command name, functions, and how they are accessed. For example, anyone using the DataOnTap API could not use the "bob" account to perform a snapmirror update because the API is a different access method compared to the command line interface.
It's also possible to grant wide range of access to most commands by using the wildcard character. If I had set Bob's role to "cli-snapmirror-*", instead of "cli-snapmirror-update", then Bob would have the ability to break a mirror, re-initialize it, or set the throttling level.