In a previous post, I described the high level steps a security admin would follow to onboard NetX redirection services onto an existing OpenStack deployment. If your OpenStack implementation is based on Mitaka and you are running VMware NSX, it is possible to launch instances with no Neutron Security Group association, which under normal circumstances would either blackhole all traffic or allow all traffic, depending on the way you configured the default section of the NSX Distributed Firewall. Prior to Mitaka, the same operation is possible by attaching the instance to a pre-existing Neutron port, but this post focuses on the Mitaka capabilities.
The example below assumes that the following conditions are met, which based on customer discussions, apply to a considerable amount of IT organizations looking at OpenStack:
- The security team has relinquished all security control from the Tenant.
- Tenants are not able to provision Neutron Security Groups or modify them (this is possible via policy.json manipulation, but outside of the scope of this article).
- All Firewall/security operations are owned by the security team.
The example below is based on Fortinet’s FortiGate-VMX Next Generation Firewall, a virtual firewall solution built from the ground-up that seamlessly integrates with VMware NSX vSphere.
Step 1: Integrate FortiGate-VMX with NSX vSphere
The instructions on how to do this can be found here. Once the solution is deployed and operational, you will see it under Service Definitions and in the NSX Service Deployments tab:
Step 2: Create an NSX Security Group and select a classification/membership criteria for the OpenStack VMs
Follow the standard process to create Security Groups in NSX. In this example, we created a Security Group called Virtual_DMZ and we are classifying VMs based on VM name which Contains the word Web:
It is important to notice that Security Groups created post-integration will appear on the FortiGate Services Management console, under Addresses and with the exact names defined in NSX. These Address Groups automatically capture the IP addresses of the corresponding VMs. Notice that OpenStack Security Groups are not populated in the Fortinet SVM:
This 2-way communication between the solutions makes it extremely convenient to keep naming conventions and visibility fully synchronized, leading to a consistent security policy.
Step 3: Create a Security Policy with the appropriate redirection rules and apply it to the NSX Security Group for the OpenStack VMs
An NSX Security Policy combines L3/L4 East-West firewall rules enforced by the NSX Firewall and Network Introspection Firewall rules controlled by Fortinet. In this example our redirection policy is redirecting everything to Fortinet’s VMX appliance. In a real life deployment you would see a combination of DFW rules and NGFW rules, where NSX handles the bulk of the traffic using in-kernel protection, while the partner solution would handle high-risk, “interesting” traffic to be inspected at L5-L7:
Step 4: Use the partner management console to manipulate your application-level security policies and deep traffic inspection
Fortinet’s SVM can be used to create and enforce rich security services for the redirected traffic (antivirus policy shown below):
Step 5: Launch the VIO/OpenStack instances without a Neutron Security Group
The OpenStack instances need to satisfy the membership criteria of the NSX Security Group (VM name contains “Web” in this example) and be launched with no Neutron Security Group attachments. This last step is crucial in maintaining the integrity of your security posture:
Step 6: Verify your security policy is working as expected
Take some time to confirm that the redirection rules are punting traffic correctly and that your deep traffic inspection is working as intended.
In a future post we will examine other partner solutions working in concert with NSX and VMware Integrated OpenStack.
The aforementioned approach combines the benefits of the OpenStack framework and its appealing API consumption model, with security services that provide more insight and visibility into the application traffic, using the advanced service integration in NSX. For all of this to work, the security team needs to own all controls of the application security policies, which is a very common Enterprise model.
For more information, you can watch a recorded version of this content (including a demo) co-presented with Fortinet at VMworld 2016 in Las Vegas.
Marcos Hernandez – CCIE #8283, VCIX, VCP-NV