We have recently published how to enable role based access (RBAC) with the VSC for customers who want to use accounts other than root as the VSC’s ‘service account’. This is the account used to communicate with the Data ONTAP APIs.
I would suggest that RBAC be implemented in environments that have separate administration teams for storage and the Virtual Infrastructure.
In today’s post I’ll cover how to implement RBAC with the VSC. This content is also being added (along with a number of updates) to the next release of TR-3749: vSphere on NetApp storage best practices. The goal of version 1.1 is to be to reduce the size of the document from its current size of 94 to around 60. We believe the release of the VSC, RCU, and NSM demonstrates the simplicity of deploying VMware on any array powered by Data ONTAP with any storage protocol. Maybe page count is a poor metric; maybe I should list the reduction in word count (as I may replace a large amounts of text with images).
There’s no need to wait for TR-3749 v1.1 to be released because we’re going to cover this process below. If you’d like additional details around implementing RBAC head over to NOW and check out knowledge base article kb54084.
Array Side Configuration
The first part of enabling RBAC is to create a new user, group, and role where the group contains the user and has the role assigned to it. In order to complete this process you will need to execute the following steps via the ONTAP command line interface (SSH, Console connection, or telnet).
Step 1: Create the new role defining the rights required for the VSC
Enter the following command on each the storage controller. You will need to create a name for this role.
useradmin role add “role_name” -a login-http-admin,api-aggr-list-info,api-cf-get-partner,api-cf-status,api-disk-list-info,api-ems-autosupport-log,api-fcp-adapter-list-info,api-fcp-get-cfmode,api-license-list-info,api-lun-get-vdisk-attributes,api-lun-list-info,api-lun-map-list-info,api-nfs-exportfs-list-rules,api-qtree-list,api-snmp-get,api-snmp-get-next,api-system-get-info,api-system-get-version,api-volume-autosize-get,api-volume-list-info,api-volume-options-list-info
Step 2: Create a user group and assign the role to the group
Enter the following command on each the storage controller. You will need to create a name for this group and reference the role name created in the previous step.
useradmin group add “group_name” -r “role_name”
Step 3: Create a user account in the group that will be used by the VSC
Enter the following command on each the storage controller. You will need to create a name and password for this user account and reference the group name created in the previous step.
useradmin user add “user_name” -g “group_name”
(note you will be prompted to create the account password)
Step 4: Verify your work
Enter the following command on each the storage controller. You will need to reference the user account created in the previous step.
useradmin user list “user_name”
The user and group information will be displayed and should match the entries in the previous three steps.
That’s it, you now have a restricted ‘service account’ to use with the VSC. Cheers!
Question, Vaughn: with this new configuration, are all connections to the controllers still proxied as this service account? How do you provide different levels of access to the controllers based on a user’s role within vCenter Server?
Scott,
Thanks for asking this question. The role based access (RBAC) established in this post is configured on the storage side. I have reached out to the VSC engineering team to obtain the vCenter RBAC settings. Once IreceiveI will share.
Just to clarify, connections are not ‘proxied’. The VSC configures I/O settings outside of the I/O path.
Hope this helps.
I have just confirmed that the VSC version 1.0 does not have the capability for delegated user access in vCenter; however, version 2.0 will add this functionality.
Vaughn – Can you use the same account on the storage for SMVI during configuration or should you configure another account for SMVI as well according to SMVI best practice?
It would be nice to only create one account on the storage instead of two.
Thank you!
Just takeing a look at the SMVI 2.0 manual and it looks like if you added the following to the role above you could maybe combine the roles and then only have to create one account:
useradmin role add api-access -a api-*,login-http-admin,cli-ifconfig
Vaughn, do you know if any other products will require access like this? I haven’t played with most of the others yet so I haven’t had a chance to check.
Thoughts?
I am planning to post the RBAC for SRM, RCU, and SMVI. Maybe I’ll take your lead and create a single user acct for all. Thanks for the suggestion!
No problem at all! I would be VERY interested in such a post. My only concern is that by bleeding all the RBAC’s together it might lead to a security hole in one of the products.
I would love to see more documentation on how the NetApp virtualization products co-exist.
Thank you!
Hey Vaughn – Just installing this today and I have a suggestion for you. Can you change the “role-name” part in to be actual roles like the SMVI manual? It is VERY helpful for cutting and pasting into a Putty session on the filer. I just did it and now I have a “role-name” role on my filer 🙂
The same goes for username.
Thanks!!
Aaron – I’ll ping you offline as I have some questions for you.
Vaughn,
IS there a read only account for VSC?
Hello.
There is actually an error in spelling in Netapp TR-3749 and you blog is correct 🙂
Here is the result if I follow the TR-3795 instruction on our Netapp.
netapp-i> useradmin role add “vcenter” -a login-http-admin,api-aggr-list-info,api-cf-get-partner,api-cfstatus,api-disk-list-info,api-ems-autosupport-log,api-fcp-adapter-list-info,api-fcp-get-cfmode,apilicense-list-info,api-lun-get-vdisk-attributes,api-lun-list-info,api-lun-map-list-info,api-nfs-exportfslist-rules,api-qtree-list,api-snmp-get,api-snmp-get-next,api-system-get-info,api-system-getversion,api-volume-autosize-get,api-volume-list-info,api-volume-options-list-info
Invalid capabilities: api-cfstatus,apilicense-list-info,api-nfs-exportfslist-rules,api-system-getversion
Could not add role . Error: Invalid capability
I’m actualy equaly nervous about letting VSC loose on our production system. I would like to know that it is limited to just reading info and not changing anything (except when allowed).