This post was authored by Jason Burns, Staff Solutions Architect at Nutanix
Previously in this series, we’ve shown how network visualization and automation can simplify the life of the Nutanix administrator. But it’s not enough to just provide connectivity and a way to visualize the app— we also have to protect it from both external and internal network attacks.
The best way to provide security is through a layered approach. One of these layers, microsegmentation, is the subject of this post, and we’ll explore the second layer, network function chains, in the next post. We expect the microsegmentation feature to be available in a future release.
This blog series highlights the AHV features announced at Nutanix .NEXT that can help you build a one-click network.
By using a policy-based approach that allows you to state your desired outcome, or your intent, Nutanix AHV microsegmentation helps you focus on protecting your application rather than worrying about the implementation details of the network. This approach differs profoundly from the traditional rules-based firewall, which maintains lists of traffic that is allowed or denied based on IP addresses and ports.
When we abstract our firewall rules into a policy, I can simply say, for example, “The HR production environment should never talk to the HR development environment.” To make such straightforward commands effective, AHV allows administrators to assign flexible, text-based tags called categories to VMs, such as "Environment: Production" and "Department: HR." You can assign a single VM to multiple user-defined categories. The categories assigned to a VM determine which policies apply to that VM.
By using categories to define a policy, I don’t have to worry about what network addresses this communication happens on. With the old rules-based approach, I would have to manually specify the addresses of the production and development environments and put them in a physical firewall somewhere. If the addresses changed, I’d have to update the firewall. Worse, I would be applying these rules at the network level, between physical servers. With virtualization, I also need a way to protect one VM from another VM on the same host.
Microsegmentation combines the policy-based approach above with a VM NIC-level distributed firewall implemented in the virtual switch of the AHV host. All VM traffic must flow through the firewall, allowing you to segment the network at an extremely granular level—hence, “microsegmentation.”
The distributed firewall derives its rules from your application-level policy. A statement as straightforward as, “HR in San Jose should be allowed to reach my Exchange Edge Transport tier,” can then immediately be implemented as layer 2 through 4 firewall rules on every virtual server in your AHV cluster, with no worrying about what IP or MAC addresses are assigned to HR and what addresses are assigned to Exchange and no need to carefully configure the traffic path to make sure you go through the firewall. AHV simply evaluates and implements your desired application policy, and the AHV firewall inspects traffic between VMs even if these VMs are on the same host, or if their network addresses change. Importantly, this means the policies can't be subverted by just changing the IP or MAC address of a VM, because each change is handled by the system.
Nutanix AHV microsegmentation builds these application policies in two phases. The first phase monitors the rules and does not enforce them. Violations are logged and shown to the administrator but ultimately permitted. This iterative approach allows you to build a policy that accurately reflects your app profile. When you’re satisfied that your policy accounts for the real behavior of your application, you can hit Apply to start the second phase: enforcing the policy. Violations of the policy are now logged and dropped.
Now that we have a tool to create a policy based on the real-world behavior of our application for layer 2 through layer 4, our next post will cover integration with virtual services at layer 4 and above.
Continue the conversation and connect with peers in our online forums.
Forward-Looking Statements Disclaimer
This blog includes forward-looking statements concerning our plans and expectations relating to the availability of new technology and product features. These forward-looking statements are not historical facts, and instead are based on our current expectations, estimates, opinions and beliefs. This information is for informational purposes only, and the development, release, and timing of any features or functionality described remains at our sole discretion. The information provided is not a commitment, promise or legal obligation to deliver any features or functionality and it should not be relied on in making a purchasing decision. The accuracy of such forward-looking statements depends upon future events, and involves risks, uncertainties and other factors beyond our control that may cause these statements to be inaccurate and cause our actual results, performance or achievements to differ materially and adversely from those anticipated or implied by such statements, including, among others: failure to develop, or unexpected difficulties or delays in developing, new product features or technology on a timely or cost-effective basis; the introduction, or acceleration of adoption of, competing solutions, including public cloud infrastructure; a shift in industry or competitive dynamics or customer demand; adoption of new, or changes to existing, international laws and regulations; and other risks detailed in our quarterly report on Form 10-Q for the fiscal quarter ended April 30, 2017, filed with the Securities and Exchange Commission. These forward-looking statements speak only as of the date of this press release and, except as required by law, we assume no obligation to update forward-looking statements to reflect actual results or subsequent events or circumstances.