Home > Blogs > OpenStack Blog for VMware


Next Generation Security Services in OpenStack – Part 2

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:

  1. The security team has relinquished all security control from the Tenant.
  2. 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).
  3. 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:

screenshot0

screenshot1

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:

screenshot2

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:

screenshot3

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:

screenshot4

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):

screenshot5

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:

screenshot6

screenshot7

 

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.

Conclusion

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 

Twitter: @netvirt

 

This entry was posted in OpenStack on VMware, Partners, Technical, VMware Integrated OpenStack, VMworld and tagged , on by .
hernandezm

About hernandezm

Marcos Hernandez is a Principal Engineer in the NSX and OpenStack teams at VMware. He is responsible for supporting large Global Enterprise accounts and providing technical guidance around VMware's suite of networking and automation products. Marcos has a background in datacenter networking design and expert knowledge in routing and switching technologies. Marcos holds CCIE certification #8283, VCIX and a Masters Degree in Telecommunications from Universidad Politécnica de Madrid.

One thought on “Next Generation Security Services in OpenStack – Part 2

  1. Pingback: Advanced Security Services with Neutron, NSX and Palo Alto Next Generation Firewall - OpenStack Blog for VMware - VMware Blogs

Leave a Reply

Your email address will not be published. Required fields are marked *

*