Written By: Colby Reed, Systems Architect, Nutanix
With all of the benefits brought forth by virtualization over the last decade and a half including consolidation, better ROI, higher availability - the threat landscape has expanded. Virtualization was not designed with security at the forefront. As we see progression towards application mobility and hybrid clouds it's imperative that security is part of every design, enforcing policy for applications at the most granular levels. (Forrester Research's Zero Trust Model
In addition to the inherent security hardening and self-remediation capabilities of the Nutanix AHV hypervisor, customers can now easily implement more granular policies leveraging isolated networks and the world class security that Palo Alto Networks Virtualized Next-Generation Firewall delivers to secure dynamic cloud environments.
Use case: L2 isolated networks for Process and Control Networks - SCADA
Rather than building traffic steering rules, AHV leverages Palo Alto Networks’ vWire technology, implementing the virtual firewalls transparently at layer 1, in addition to OVS bridges, to create logical isolation within traditional VLANs.
Leveraging Palo Alto Networks Virtualized Next-Generation Firewall on every host, in addition to automation scripts in AHV, building out complex virtual networks with fine-grained isolation through security policies becomes nearly as simple as paint-by-numbers.
Let’s look at isolated networks in a Process and Control deployment, e.g. SCADA. We’ll start with the AHV default network configuration.
By default, AHV has two OVS bridges - virbr0 and br0. Vribr0 is used for storage I/O and has no connectivity to the outside world, while br0 is used to connect user VM’s, as well as the external interface of the Nutanix Controller VM (CVM), to the physical NICs and the outside world. With the desire to implement security policy between VMs on the same L2 domain, effectively isolating networks Process and Control VM’s, we’ll want the end state to look something like this.
So how do we get there? With Nutanix and AHV, simply run a few scripts and the entire infrastructure is configured securely within minutes.
In this example, we’re going to isolate the Process and Control VLANs of a SCADA deployment, ensuring that all traffic between the isolated networks is enforced by the Palo Alto Network Next-Generation Virtual Firewall. First we’ll create the isolated networks using OVS bridges, second we’ll create network profiles grouping network settings for the isolated networks and third we’ll attach the network profiles to the VM’s. You can run the scripts on any of the Nutanix Controller VM’s (CVM’s), and the configuration will be replicated to all nodes within the cluster.
First, let’s configure the OVS bridges. SSH into any of the Nutanix Controller VM’s (CVM’s) in the cluster, and run the ‘allssh’ command specifying the names of the desired OVS bridges.
Here we’re creating two isolated networks for the Process and Control VLANs, so we’ll need two internal OVS bridges - Process A & Process B; Control A & Control B, respectively.
Second, let’s create the network profiles that will group network settings, such as VLAN and bridge ID, for the isolated networks. On the same CVM, run the network_profile.py script to create a network profile for each isolated network. Here we’ll create four network profiles, effectively creating internal and external policies for Process and Control.
Third, we’ll attach the network profiles to the guest VMs. On the same CVM, run vm_profile.py to attach the network profiles to the guest VM’s.
Last but not least, run the allssh script on the same CVM to add the appropriate VLAN tags to all trunks across the cluster, configure the security policy on the Palo Alto Networks Virtualized Next-Generation Firewall and start testing! Here we’re using an external Palo Alto Networks Virtualized Next-Generation Firewall as the default-gateway in Layer3 mode, and we’ve pruned the trunks to allow only the Process and Control VLANs -100 and 200, respectively - while the management traffic passes untagged.
allssh ‘ssh firstname.lastname@example.org /usr/bin/ovs-vsctl set port bond0 vlan_mode=native-untagged && echo success'
allssh ‘ssh email@example.com /usr/bin/ovs-vsctl set port bond0 trunks=100,200 && echo success'
Once the trunks are configured, validate the guest VM’s and their network associations from the Acropolis command line (acli).
Now that the guest VM’s and network-profiles have been validated, our final configuration looks like this:
Leveraging the scripting capabilities of AHV and application-layer inspection (App-ID) of the Palo Alto Networks Next-Generation Virtual Firewall, customers can easily and quickly deploy granular application policies for east-west traffic.
For more information, download the Palo Alto Networks and Nutanix Solution Brief
or visit http://www.nutanix.com/products/acropolis/