NSX DFW & Multi Tenancy

[mrstorey303]

In our org we run a centralised vcenter model, with delegated admin access to different business divisions via datacenter folders.  Aside from a few quirks, this pretty much provides a multi-tenanted vcenter design.

However unless I’m missing something, there doesn’t appear a way to provide delegated access to the NSX Distributed Firewall feature for multiple tenants in a single vcenter.  The RBAC in NSX seems pretty weak - ie, there’s only one role for the DFW (Security Administrator), and there’s no way to limit the scope of where a firewall rule would apply to - it’s just ‘Distributed Firewall’.  Instead, I'd like a user to pick a cluster from a list of clusters which they had permissions over.

Without this, it suggests that a user would inherently be able to push disruptive rules to hosts and clusters which they didn’t have administrative access over?

Ideally we don’t want to break out these ‘tenants’ into their own vcenters - but wondering if we will be forced to if NSX doesn’t provide any kind of scoping around their RBAC / permissions system.

Any ideas?

[larsonm]

I would suggest submitting a feature request.

In the meantime, HyTrust has a nice tool to help fill in the RBAC gaps not currently native to NSX.

[mrstorey303]

Thanks, yep - HyTrust was suggested to us - I took a look at the architecture guide and felt that it would introduce a fair bit of unwanted complexity - ie shoving something in the way of your vcenters / admin tools, and either messing with your firewall rules to cut off direct access or change your routing tables to force connections via the appliances....it didn't seem very pleasant, but admittedly I've had no hands on with it.

Will submit feature request - maybe it'll end up in NSX-T.....but perhaps unlikely in place for when we need it!   Thanks for your reply.

[sk84]

If you need a multi-tenant design, why don't you use vCloud Director or at least vRealize Automation? vSphere itself (and NSX) was never built from scratch for such isolation. For this, there are self-service portals available from VMware that provide multi-tenant capability and the necessary isolation for private clouds or cloud services for different customers.

[mrstorey303]

Thanks - it's something we've approached our account teams about - whether their private cloud products are required to address this.

I didn't actually think that vCloud Director wasn't actually available for sale to new customers?  They're only supporting it for existing users, and vRA replaces this for the most part?

I guess it's time to look at vRA again now that 7.5 is out.

[sk84]

No. That was the information a few years ago. But it seems that VMware has now taken a step back and vCD is being further developed (after a long standstill). This year the vCD versions 9.1 and 9.5 were released. vRA and vCD will thus coexist. Whereby vRA is rather intended for internal IT or cloud services and vCD is oriented towards private clouds in the cloud provider environment.

However, I am not sure whether vCD is accessible to all customers or only for service or cloud providers. But here you can ask your VMware sales representative.

[DaveRoessler]

Well... my first advice is that absolutely nobody, except trusted vSphere infrastructure admins, should be allowed access to the vCenter management plane! What you are allowing is bad practice and exposes various types of information/capabilities to users that really don't need it.

HyTrust is perfect for multi tenant RBAC. Its used in numerous SDDC environments w/ multi tenancy and there are valid use cases available to research.

Also, vRealize Automation should be used, with vRO and the required NSX plug-ins. vRA will allow for multi tenant access, without exposing your infrastructure management planes to tenants (which is very bad practice).

[mrstorey303]

Only trusted admins have access to vCenter - they are trusted to, and are required to, look after their own VMware assets below their datacenters objects using a least-priviledge / cut down administrator role.  They are not granted top level access to vcenter or the SSO domain etc - it's just local IT teams needing to manage / build / deploy their own vSphere infrastructure in their region using a centralised vCenter service.  I call them 'tenants', but perhaps that term can be taken too literally - these guys are in our team, just in different divisions.

FWIW, we've been advised that NSX-T could be an option for us - ie deploy seperate NSX managers for each tenant, and prepare just the hosts and clusters to which they are administrators of (ie don't hook the managers into a central vcenter.)

So far it's good / is working.  But the architectural differences in T require a more involved deployment and will have an impact on how you manage vsphere networking going forward - just need to weigh it up.  It does seem like a strategic product for VMware though - ie the long term future of NSX, so will give it some time.

I played around a little with vRA - obviously a large / comprehensive product, but from what I saw it's really geared toward self service / deployment of ephemeral workloads.  Need to familiarise myself more . Definitely will be evaluated for private cloud initiatives, but not sure whether we should deploy something so complex to overcome some simple and apparent limitations of vcenter / nsx-v.

[larsonm]

I came across another solution that seems to handle NSX multi-tenancy quite well - for both NSX-v and NSX-T.  ReSTNSX allows you to delegate specific sections in the DFW to a specific tenant.  Might be something worth digging into.