NSX and Securing Multi-tenancy Policy

Discussing security and multi-tenant cloud environments both public and private consumes so much of my time. This time though let’s get into how micro-segmentation and the coolness that is VMware’s NSX. At least it’s a different angle so I don’t get bored writing about it J.

From an Operations perspective I want my environment to be as simple as possible, and consistently deployed. As I add tenants to my infrastructure this becomes even more imperative, right? Think about it this way if you are a car mechanic you can be a mechanic at a dealership and see similar vehicles all day let’s say Audi for example. Or you can work at a boutique shop and see every kind of vehicle. The benefit of the dealership is they can roll through more cars per day on average than a boutique shop because all of the cars are roughly the same lay out and use the same size nuts and bolts etc. Essentially the mechanic has the blueprints for the cars they are servicing.

In Operations if we have the same management stack across everything we have the blueprint and it’s simple. Enter the security team …

In security simple is also important, BUT, we also need to have gates and gate keepers. In a multi-tenant environment regardless of the M&O be it vRA or XStream we need to ensure that one tenant’s data can not corrupt another’s. Equally important we have to make sure that if\when a tenant is compromised (get your head out of the gutter) that compromise doesn’t trickle to my core infrastructure or to other tenants.

“Obvi Mike!”

Yeah I get it but that’s not as obvious to everyone, because think about what this means. First it means you need separate attack surfaces. In VMware terms this means two vCenters, one to manage the core infrastructure and another to manage the tenant infrastructure. This ensures that in the event that you get attacked and your tenants get PWND you still have a layer between the tenants and the core infrastructure that manages it all. It also means you have a stretched network for management. This creates a vulnerability in and of itself because it stretches across the core infrastructure and tenant architectures. However, we do not provide access to this management network from tenants directly rather we create jump servers or dual homed transitional boxes.

In NSX terms: We have controllers spanned across the environment, each tenant has it’s own NSX Edge and it’s own set of VXLANs. The Management network is linked off of whatever the M&O service is and provides visibility into the tenant for management but does not allow tenant traffic to jump across to other tenants. This is done by creating a distributed Firewall with ACLs for specific traffic on one of the M&O VM’s vNICs. It would be possible to also NAT this traffic across the Edge Gateway from tenant to management for the necessary monitoring and orchestration traffic.

If that all sounds good, then your next question is how does this work? Rather than reinventing the wheel I would recommend you read Matt Berry & Anthony Burke’s post on zero trust solution architecture with NSX. I think it best captures the right way to segment environments for security.

What do you think? Is this a little to security crazy or is this the way you would architect your multi-tenant environments?