Overview

I recently had the opportunity to play with a four host VMware Cloud on AWS (VMC) software-defined data center (SDDC) for a month as part of an extracurricular, open source, VMUG project using HashiCorp Terraform to automate the provision of virtual infrastructure for a VMware-oriented hackathon, but I’ll discuss the project more in depth in an upcoming post. I learned a lot during the trial and am very grateful for the opportunity.

Getting started

If you haven’t read the VMC Getting Started Guide, here are a couple of important items:

1. You’ll need to create a few firewall rules from the VMC portal to access your SDDC. By default, both the Management Gateway’s (MGW) and Compute Gateway’s (CGW) firewall policy default to deny all, so no traffic is permitted to or from either environment until you allow it.
   • MGW: NSX Edge Services Gateway (ESG) that secures the north/south traffic to and from the VMC vCenter Server, ESXi hosts, and NSX Manager.
   • CGW: ESG that secures north/south traffic to and from the VMs that you provision and control in your SDDC.
2. Since this is a managed service, the rules that you can create on the Management Gateway are restricted to specific services for specific endpoints. For example, you cannot create a rule permitting SSH access to the ESXi hosts in the environment, but you can permit ICMP so that you can monitor host availability via ping.

Constraints

Firewall services

One thing that I found interesting is that VMC only permits one service entry per firewall rule, which can be a TCP or UDP port (eg: 80/tcp), an ICMP type (eg: 0 Echo Reply), a range of TCP or UDP ports (eg: 49152-65535/tcp), all TCP, all UDP, or all ICMP, or any, but cannot be configured for multiple, non-contiguous services (eg: 80/tcp, 443/tcp) per the guide. Permitting this connectivity must be written as separate rules in VMC. Implementing a single target service object standard such as this is one way to help design a firewall policy that can be easy to read, troubleshoot, and administer if implemented properly, but I was a little surprised that this was mandated since the firewall functionality of the NSX platform is so robust. This is also a constraint of firewall rules in AWS VPC security groups, but it seems odd in a NSX environment.

Firewall grouping objects

Next, reusable NSX grouping objects, such as IPSets, security groups, custom service objects, and service groups are not yet available in VMC. This made the initial bit of manual firewall policy management to be tedious since I have been spoiled by the convenience of these.

Use case example

To illustrate the challenge posed by the combination of these limitations, imagine provisioning a new Active Directory domain controller in your VMC SDDC for an existing domain residing outside the SDDC and you had a requirement of only permitting the minimum necessary connectivity. You would have to write and manage over 20 separate firewall rules per the guide with the domain controller IP address statically defined in either the source or destination of each rule (as appropriate) to accomplish this because of the single service/service-range constraint.

If you then needed to provision another domain controller for that domain in your SDDC and wanted to permit the same connectivity to & from the original domain controller and also maintain your requirement of permitting the minimum necessary connectivity, you would need to modify the sources and/or destinations of the existing 20+ rules (or add 20+ new rules) because of the lack of reusable firewall grouping objects.

If NSX grouping objects were available, you could consolidate the rules to a small handful with service groups that permitted the same traffic for the first domain controller and maintain the single target service (group) object. To permit the traffic for the second domain controller (assuming that dynamic security groups and security groups with parent infrastructure objects weren’t used for firewall policy to be automatically updated and applied), you would only have to make one change instead of multiple. Examples include adding the new IP address to the IPSet object, creating a new IPSet and adding it to the security group object, and adding the VM object to the security group object.

Distributed firewall

Another challenge to maintaining a strong network security posture is that the VMC SDDC distributed firewall is not yet configurable; however, this feature is currently listed as Planned in the public roadmap. An alternative for controlling east/west traffic in the mean time is to use host-based firewalls.

Conclusion

There are so many neat and effective ways to administer firewall policy with NSX, so this was one area that could use improvement and my only real point of constructive criticism from the trial period. Overall, I was impressed with the excellence in architecture, engineering, and service delivery demonstrated by the VMC platform.

Acknowledgements

Special thanks to Ken Nalbone, Wences Michel, and Brian Graf for this great learning opportunity.

• vmware
• vmware-cloud-on-aws