One of the announcements of VMworld 2014 was a new version of NSX, which has been given a minor update to 6.1 from 6.0. I will delve into the nitty-gritty of what this release offers in a later post, but for now I’d like to draw your attention to a bit of marketese that VMware came up: “micro-segmentation.”
Meat and Two Veg Time: What Exactly Is Micro-Segmentation?
Micro-segmentation is the feature that seems to be the basis of NSX’s core USP; this is allegedly the feature that sells NSX. A regular data center has a single firewall (more likely two physical firewalls, but only one logical entity) per security zone, and these protect the entire zone from unauthorised ingress beyond the perimeter (see diagram below). The issue is that traditional perimeter-centric network security has proven insufficient.
What perimeter-centric network security does not do is protect the interior from unauthorised access once you are in. If you access from within the network, you are free to roam within that zone until you try to leave. Micro-segmentation (or to cut the marketese, per-VM firewalls) is now technically possible without overhead on the guest. In other words, NSX presents a machine-level firewall. Hurrah!
Hang on a minute there—isn’t this just vShield App? Well, yes, very similar. It built upon the processes in vCNS to provide granular, per-machine protection. However, this protection, rather than being built into a per-host virtual machine, is built into the host at the vmkernel level as part of the distributed logical plane (DLP) or NSX. The DLP is an L2/3 switching router with a built-in firewall, distributed across all nodes in the NSX sphere of influence. This is not technically correct, as each function is a separate VIB. However, what this approach brings to the game is that it allows a VM-centric, rather than a VLAN-centric, security policy.
OK, sounds good. So, what benefit does it give me? When a machine is migrated, either manually or automatically via DRS, that machine’s policy follows it to the new machine. This allows very fine granular security groups based on individual servers and services. Even better, when a server is finally decommissioned, the policy assigned to that machine dies with it. What this allows is a situation similar to the one in the below image: separation based on zones of influence rather than VLAN. Yes, we could do this with VLANs, but as shown below, it would be a lot messier from a network viewpoint.
In the first diagram, the location of VMs is constrained by the network and the systems they need to access. Communication within VLANs is uncontrolled, and VM commission is slowed by silo boundaries. In the second graphic, the introduction of NSX enables machines to be grouped more logically, with no changes to the underlying topology. This means that policy is aligned to function rather than VLAN. This is because the firewall acts at layer 4 or 7, not layer 3 like traditional firewalls.
This magic is achieved with the use of policy that is built up through the identification of service workflows and known or identified use attributes based on the servers or services used to create the necessary security groups; it is to these security groups that policy is applied.
What Does All This Mean?
To sum up, it is another arrow in the quiver of the SDDC. Micro-segmentation, though policy, moves logic up the stack. It does not remove the need for logic, layer 2, and layer 3, but it hides it. Technology like equal-cost multipath routing support allows the NSX controllers to learn the shortest paths, thereby cutting down north/south traffic and optimizing east/west traffic. How exactly does it do this magic? Every VM is registered with vCenter, and it knows the MAC Address of each and every VM. This is fed to the NSX controllers. It is the controllers that manage the policy and direct the paths.
What micro-segmentation brings to the party is the ability to secure your multi-tenanted environment in your SDDC. In the second diagram, I indicated that you could separate your environment up into security groups based on department. With a multi-tenant SDDC, you could easily nest your policies to provide a top level per tenant, and then in subsequent tiers granularize your tenants’ traffic into departments, etc.