Building on the concepts and implementation that I have been working on for the past few weeks around service chaining in Neutron, this post will now focus on how to onboard the Palo Alto Next Generation Firewall platform onto OpenStack.
Palo Alto Networks has one of the most mature and robust integrations with VMware NSX and we also share many joint customers in production. Together, we have seen tremendous success in the market, and that success can now extend to those prospects wanting to do OpenStack, while augmenting their security strategy with the added visibility and protection that Palo Alto offers.
The basic tenets for this integration between Palo Alto Networks and VMware NSX, in the context of an OpenStack deployment, remain the same:
- The Security/Firewall Team is in complete control of the security lifecycle of the tenant apps.
- Although not mandatory, Provider Networks are preferred in this context over Tenant Networks.
- Tenants use the OpenStack API to consume Compute and Storage Services, while Networking and Security remain under the control of the Cloud Admins or Central IT.
- This model is relatively common in the Enterprise, but not common in the DevOps use case where Tenants control their own network and security workflows.
If the above prerequisites are met, one can safely implement the VMware NSX + Palo Alto integration and overlay OpenStack Neutron on top, offering a complete private Cloud deployment that incorporates advanced security controls for East-West traffic. VMware NetX is the glue holding everything together.
Here is the high level workflow:
- Integrate VMware NSX and Palo Alto Networks following best practices and recommended software versions for NSX, Panorama and the PAN VM Series. The instructions to do this can be found here.
- Deploy VMware Integrated OpenStack 3.0 (if it hasn’t been done already) or any OpenStack distribution compatible with the Mitaka release, using VMware vSphere and VMware NSX as the underlying infrastructure components.
- Identify the Compute clusters that will host your OpenStack workloads and deploy Palo Alto network introspection to those clusters:
- Ensure the Service VMs (local firewalls) are properly registered and licensed in Panorama:
- Create an NSX Security Group with a classification criteria that meets your needs. In this example we are using the proverbial example based on VM Name (Name Contains Web in this case):
- In Panorama, create a Dynamic Address Group for the OpenStack Instances, that corresponds to the NSX Security Group created in the previous step:
- Then, in Panorama, create the Policy you want to apply to the redirected traffic:
- Back on NSX, create a redirection policy, or Partner Security Rule, for the interesting traffic that will be subject to inspection (Network Introspection). In this example we are redirecting inbound HTTP/HTTPS traffic for additional security controls:
Note 1: You will also need to create DFW rules to allow the traffic that will be redirected, as these rules are applied prior to the redirection for outbound traffic (VM >> World) and are applied after redirection for inbound traffic (World >> VM). More details on how these flows move through the Hypervisor can be found on the NSX Design Guide.
Note 2: You may need to use the “ApplyTo” Field in NSX to limit the redirection policy to the specific VMs in question.
- Finally, you can use OpenStack Nova to boot Instances (VMs) that satisfy the membership criteria of the appropriate NSX Security Group. It is extremely important that you DO NOT attach a Neutron Security Group to these Instances. We are bypassing self-service security provisioning in OpenStack and delegating all security controls to the Firewall Team.
Note 3: If you are using Horizon (OpenStack GUI), you may need to detach the default Neutron Security Group after you launch your Instance(s).
Note 4: Another approach, not covered in this document, has to do with the manipulation of the policy.json file for Neutron, in order to restrict Security Group changes or additions by anyone other than the Admin. In this case, launching Instances without a Neutron Security Group attachment is not required, as the Neutron Security Group that is used would only be modified by said Admin.
- Verify your configuration and security policies.
As we can see, the above approach safely integrates value-add security and visibility services into OpenStack today, and showcases the power of NSX as a platform for Private Cloud deployments based on OpenStack.
Follow these links for the previous two articles in our 3-part blog series:
VMware and Palo Alto Networks will be discussing this and many other interesting topics at VMworld Europe 2016 in Barcelona, Spain. Don’t forget to swing by the Palo Alto Networks booth in the Solutions Exchange if you need more information.