Authors – Sridhar Subramanian and Geoff Wilmington

VMware NSX Data Center was built with the goal of consistent networking and security services independent of changing application frameworks or physical infrastructure. In the last couple of years, NSX Data Center has focused on delivering network and security abstractions for applications on any compute platform. In our journey, we have handled virtual machines (VMs), containers, cloud, and now we are also looking to help our customers with scenarios where they need a unified experience for bare-metal workloads.  The goal being to maintain a consistent security experience regardless of location or platform the workload is running on.

This experience means being able to take any workload, add it to an NSX Data Center Security Group and through the NSX Data Center Distributed Firewall have a consistent policy applied regardless of location and workload type.  This consistent approach leverages the NSX DFW capabilities with stateful firewalling for the workloads.  This is accomplished outside of using native OS capabilities like IP Tables or Windows Firewall so security admins only need to understand how to apply security through NSX DFW, and not have to understand the myriad of native OS approaches and complexity.  By centralizing policy in the NSX DFW, this simplifies and unifies the security experience.

Bare-metal Security Works Well With Today’s Approach

Bare-metal native workloads are typically static and as a result the most practical method in use has been to apply stateless access control lists (ACLs) in the Top-of-the-Rack (ToR) switch connecting the bare-metal workloads. Sophisticated operational environments that require stateful security policies deploy virtualized firewall appliances – within the rack or use dedicated physical firewall appliances at the Edge (North-South traffic flow boundary). This approach – of setting the security policy once using ACL or dedicated firewall and then leaving it largely untouched operationally – is still a very reliable model.

Securing Virtual with NSX Helps Protect Bare-metal

While NSX Data Center micro-segmentation was originally introduced to secure virtual workloads, there are inherent benefits of the same approach that can be applied for securing bare-metal. The security rule enforcement can be done at the ingress and egress layers within the spectrum of virtual network infrastructure, which interconnects virtual and physical workloads.

For example, bellow illustration shows a way to protect bare-metal by securing at both the source and destination virtual workload.

Similarly, for north to south traffic flows, the below illustration shows a way to protect bare-metal by securing at NSX Edge Firewall

Partner Firewalls Can Leverage NSX Group Information to Protect Bare-metal

While Virtual to Physical workload communication security can be enabled by enforcing rules across the spectrum of the Virtual network, there are operational environments managed by SecOps groups which administer L4-L7 security enforcement as close as possible outside the Trust boundary of the bare-metal workload. For addressing such use cases, VMware partners with a number of security vendors (e.g. Fortinet, Palo Alto Networks, Checkpoint, etc. who offer comprehensive L4-L7 security appliances with high performance) and the exchange of NSX security group information, to the Partner Firewall manager, effectively enables physical Firewalls to use NSX Data Center groups in their tables to create a rule to the effect that says web group cannot talk to database workloads sitting on a physical VLAN, thus giving a common policy model.  For more information take a look at the Security Services section on our partner page.

NSX Benefits Now Extensible Into the Trust Boundary of Bare-metal Workloads

Database servers, including ‘crown jewel’ bare-metal workloads are coming under increasing regulatory surveillance to ensure security enforcement across and within the trust boundary of the workload. NSX Data Center is now getting ready to extend the full Networking and Security benefits – i.e. what is already available for Virtual workloads – all the way in to the Trust boundary of the bare-metal workload.

As illustrated with the use cases shown above, traffic flows can be regulated both across and inside subnets for Virtual to Physical as well as Physical to Physical communication, using stateful L4 DFW rules configurable from NSX.

NSX Data Center provides these same capabilities for bare-metal workloads by leveraging the Open vSwitch (OVS) architecture to combine open vSwitch kernel datapath performance with security enforcement using NSX DFW rules similar to how NSX Data Center provides micro-segmentation for KVM-based hypervisor virtual machine workloads.  By doing so, security admins can now provision security policies through the NSX DFW, and the policies are pushed to the bare-metal machines similarly to virtual workloads.  All while providing the same security methodology to each workload.  The security admin no longer needs to use IP Tables or Windows Firewall to apply security policy within the bare-metal workload.

Check out the bare-metal Tech preview demo of NSX Security for two bare-metal workloads running RHEL 7.3 and RHEL 7.4, respectively.  Stay tuned for the part two of this blog series as we discuss the inner-workings with OVS and how NSX can provide this consistent security policy for bare-metal machines.