Hello everyone, and welcome to Part 8 in our Nimble OS 2.1 blog series. Yesterday, Bill Borsari walked us through the new VLAN tagging support. If you've missed his or any of the other previous posts, I highly encourage you to check out all the great content on the main series page.
For those that have been using Nimble Storage for some time (Thank You!) you know that there has always existed only a single user for array access. One of the oft-requested features from our customers has been to expand our security and access options beyond this. I am happy to report that as of Nimble OS 2.1, RBAC support has automatically been added to all systems. If you've logged into a Nimble array prior to 2.1 you'll notice that there's something different about the new login screen. Prior to 2.1 we never prompted for a username as there only existed one: admin. In fact, if you've never logged into the array via CLI you may not have even known what the username was.
Before you can add any more users, you'll need to log in with the original default admin username and password. Once you've successfully logged in, you can access the new user management interface under the Administration --> Security list (see below).
Once you're on the User Management screen you can add, remove, or edit user accounts. Let's take a look at what is needed for a new account.
As you can see, you'll need to fill in the following four attributes in order to create a new user account: Full Name, the role type, the actual username, and of course the password. While the email address and description fields aren't mandatory, it definitely can come in handy in large environments with many users being added to the system. Once you've filled everything in just go ahead and hit the Save button. If any of the fields don't comply with the required parameters you'll get a notification (as with all screens in Nimble) of what the issue is. For example, it turns out that the username must only consist of letter and/or numbers so my original attempt at the above username failed due to an invalid underscore character. Otherwise you'll see a success message if all the fields are acceptable.
I mentioned above that you'll need to select the Role type for your users. So what are the various roles and their abilities/limitations you might ask? Currently, Nimble OS supports the following four Role types: Administrator, Power User, Operator, and Guest. Let's take a look at what each of these user Roles allows you to do. This information can also be found on p.30 of the Nimble OS 2.1.4 User Guide. Also check out p.104 for a list of features and the minimum permission level associated with each.
- Administrator - As you probably guessed by now, the Administrator role allows for full access and administration of everything within the GUI and CLI of your Nimble array.
- Power User - This user type allows for all functions except user management, inactivity timeout, array setup or re-setup.
- Operator - Users of this type have access to all management functions but cannot delete or remove any data. This can be a great user role to use for DBAs or application teams that want to leverage the Zero-Copy clone functionality to quickly spawn new instances of application data without the risk of potentially removing the wrong volume afterward.
- Guest - Guest users are allowed view access only. They are able to see any information within the system but have no ability to make any modifications. This is a great use for audit type accounts.
If you ever need to make modifications to a user account after it's already been created, simply select the user on the left-hand column and click on either of the Edit buttons to change any of the user associated values. You can also select the More Actions drop-down if you need to change the associated password, disable, or remove the account. Notice that there's a search bar in the upper left that allows you to quickly filter large lists of users.
So what happens if a user tries to perform an action not allowed by their specified user role? Well, the Nimble engineers have done it again and made things really simple for us all. If a user isn't allowed a particular function it is either greyed out or simply won't appear in the GUI whereas the CLI will ignore the command and return a Permission denied message. Let's take a closer look at the difference you would see when trying different task with the various user roles.
As we saw in the role type above, a Power User has all the right of a full Administrator except user management. What does that look like? You can see below that everything looks exactly the same except that the Security option doesn't appear anywhere as compared to the screenshot above run as an Administrator user.
Let's now take a look at the difference with an Operator user. As you can see in the screenshots below, the Operator user on the right does not show the option to Delete or Set Offline for the volume due to the restricted role type.
One other interesting aspect of the Operator role is that it also won't allow the download or update of the Nimble OS. In fact, the options aren't even available to those users as seen below.
vCenter Role Based Access Control
Outside of RBAC at the array level, Nimble OS 2.1 also brings RBAC functionality into the vSphere environment. If you haven't done it yet, please take a look at Rich Fenton's excellent writeup on all the functionality in the new vCenter plugin. Once the latest vCenter plugin is installed, a new set of privileges are installed alongside allowing for control of plugin use/actions based on the user's identity, role, and privileges within vCenter. The upside is that this can also be tied into Active Directory. Similar to the native Nimble GUI, if a user does not have the privilege to execute a particular task, it will be either greyed out or will not be shown. A list of the new Nimble associated role options is below.
I hope this blog served as a good primer on the new RBAC capabilities of Nimble OS 2.1. As always, we welcome and encourage questions/feedback. Please check back tomorrow as Ezat Dayeh shows us how to move volumes between pools in a scale-out group.