I assume you're talking about the vCenter plugin?
The Nimble array requires Admin credentials (note: not THE admin account, just AN admin account) in order to be able to inject itself into vCenter, and give you the ability to create custom access for user roles and groups with different features of the plugin. This is mandatory from VMware's side to for this functionality to work as expected.
You can grant access to be able to create/manage/delete different levels of object within VMware from that point to different user roles/groups, not breaking your security policies.
Good point, yes I was talking about the vCenter plugin. Splitting hairs between THE admin account, (that has the password changed and tucked away safely), and an admin account. Not much difference functionally. No VMware does not require admin level access to setup / manage / delete object. That is why there are all kinds of options when setting up roles in vCenter. Do you have references to backup your assertion that Admin level access required? What are the minimum set of vCenter permissions for the account used with the vCenter plugin?
Sorry it looks like you misunderstood my last message; the Admin account is only required to allow us as a third party provider to inject our plugin and integrate at the right levels within the system. It would also be needed to be able to use vCenter consistent snapshots, as well as VASA integration with VVOLs. The vCenter plugin can then be granted to any other level of administrator within your infrastructure, for different requirements.
Nick - At this point I have to believe you are not understanding my concern. When I say Admin level access I mean the account has full on access to do everything in vSphere land. That is configure hosts, create data centers, setup networking, i.e. what I need as the chief cook and bottle washer. The level of access required by the Nimble vCenter plugin should not require that level of control. Sure it needs all things storage related. It however does not need the administrator level access to patch a host. This is what you are telling me plugin requires to do its job and that makes no sense and is a huge gaping security hole.
Hello sir. I do indeed understand your concern, and I understand what the admin account can do and what it is within vCenter. My thinking is that you cannot inject a 3rd party plugin such as ourselves within vCenter with the required credentials with anything other than an admin account. As i mentioned, you can restrict and assign the plugin (or different parts of) to different, lower level accounts/groups within vCenter once the plugin has been initially registered, and admin rights revoked within vCenter to be able to do anything with the plugin.
Also bear in mind that if you needed into inject in a VASA provider for things such as VVOLs, then you must have an admin account. That's a VMware restriction.
I'd encourage a call to Nimble Support to walk this through in more detail; it seems that we're having crossed wires on a forum.
You clearly do not understand this issue. To inject as a VASA provider you need storage permissions, you do not need full on Admin permissions. I have asked you to escalate this issue and you have chosen not to. You claim this is a VMware restriction, I have also asked you to cite your reference for this claim, you have chosen not to.
Nick did escalate this issue, I'm sorry for the delay in my response. This really wasn't laziness (honestly), it was an oversight on our part with regard to documentation. This lack of documentation has lead to the misconception that administrative rights are required. We're hoping to get this information into the documentation in the next release. Until then, below is the minimum set of privileges needed on an object for each extension.
I hope this helps.
Minimum Privileges for taking vCenter synchronized snapshots (set on a Volume Collection):
Minimum Privileges for using the vCenter Plug-in
These aren't specified in a Role. These are implied when you assign a Role to a User/Group for a subset of the inventory tree (or the whole inventory tree). For example; If I assign the Role named "Virtual machine user (sample)" to the user eric for a specific Virtual Machine, when the eric user logs in he will see that Virtual Machine. The user eric now has "System.Read" and "System.View" privileges on that Virtual Machine, this is why he can see it.
The following kb article covers a case where an Administrator doesn't have System.Read on the root of the inventory tree:
I hope this helps.
Why does Nimble require full on Administrator access to vSphere land? Surely they don't need to provision new ESXi hosts, nor do they have to modify a host's or even a VM's network connection. I can see granting of anything storage related, but why full on Administrator. This goes against every security practice to give out more access than is required. To be fair Nimble is not the only vendor that falls into this lazy bucket, but I have come to expect more from them.