vCenter and NSX-v Administrators: TBoP (The Battle of Permissions)

Although sometimes it is entertaining but it is quite upsetting but when you get  into a table where people struggle to find a middle ground in terms of who owns what and who gets access to what and so on and so forth.

This blog is not about the technicalities nor about RBAC for both vCenter and NSX platforms. It is more about how to get the best of both worlds while remembering that nothing could be accomplished without collaboration.

For your reference:

1. NSX Users and Permissions by Feature.
2. Register vCenter Server with NSX Manager:The catch here, is to shed light on this line “You must have a vCenter Server user account with the Administrator role to synchronize NSX Manager with the vCenter Server system. If your vCenter password has non-ASCII characters, you must change it before synchronizing the NSX Manager with the vCenter Server sytem.” and as such, when being asked what are the vCenter server permissions required for the integration user it must always have the administrator role :-).

Moving forward with this, when dealing with permissions one should aknowledge two things:

1. They are there to protect the business.
2. They are there to protect you (from you ;-)).

So whenever this topic arises, don’t take things personal and don’t get too much in tension about it and just state what you need to get your tasks done without any delay. So what does an NSX administrator require from the vCenter administrator to get things going?

To simplify, we have to understand that adopting NSX is not about taking the tasks from the network people and give them to the vSphere guys nor it is about giving the network people leverage over the vSphere guys to do whatever they want, it is about balance and it is about everyone doing what they know best using a unified platform with common technology understanding.

Now to delve more into the technicalities, I have listed a table with the configuration items along with “_my_” point of view of whom needs what and with a justification as well.

Task	NSX Administrator Needs	Justification
Access to vCenter Server	Yes	For NSX Administrators it will be read-only.
Configure vDS and Port Groups	Yes	This is a task related to vSphere networking, if we’re following up a methodology of segregating duties and reflecting that back to what used to be done from a physical perspective then this is something that is needed by the NSX administrator. Also thinking of this logically, later on virtual networks will be created via the NSX manager and the vSphere Administrator will only consume these virtual networks.
Configure ESXi VMKernel	No	Tasks related to VMKernel should only be with the vSphere Administrators as the NSX Administrator doesn’t have any tasks that needs to be done directly (VXLAN is configured via the service account that is used when integrating NSX with the vCenter Server.
Root access to ESXi hosts	No	This is debatable because when you look at troubleshooting NSX you will notice that there are commands that are issued directly on the ESXi host, now from my point of view _most_ of what an NSX administrator needs from a CLI perspective could be achieved via the NSX Manager central CLI, and now with 6.4 packet capture is now available via the NSX manager so it is safe to say that this of the NSX administrator needs root access, it could be requested (i.e. for a GSS call).
NSX Manager VM, Edge VMs (DLRs and ESGs), Controller VMs, Guest Introspection VMs, and 3rd party SVMs	Yes	These are deployed for NSX and since the NSX Administrators have only read only therefore no administrative access to the VMs and from my point of view NSX Administrators must be given full permission over these VMs as its their responsibility.
DRS Rules	No	For HA enabled edges this is automatically created, but for ECMP ESGs this needs to be done manually also for the controller cluster VMs. So in this case granularity to give permission to a single rule is not possible and it is only available as a cluster wide permission which will be a big no when being asked from the vCenter Server administrators. When doing a new deployment this can be co-joined so that to have the required configuration and on the other hand you will need to be aware that when deploying new controllers or upgrading the infrastructure (any action that suggests re-deploying the virtual appliances) then the NSX Administrators needs to contact the vCenter Server Administrators to re-add the VMs to the DRS rules that were manually created.

If you know that I have missed anything please do let me know so that to update this blog post and I hope this helps.