Author Archives: hernandezm

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.

Making OpenStack Neutron Better for Everyone

This blog post was created by Scott Lowe, VMware Engineering Architect in the Office of the CTO. Scott is an SDN expert and a published author. You can find more information about him at http://blog.scottlowe.org/

Additional comments and reviews: Xiao Gao, Gary Kotton and Marcos Hernandez.


In any open source project, there’s often a lot of work that has to happen “in the background,” so to speak, out of the view of the users that consume that open source project. This work often involves improvements in the performance, modularity, or supportability of the project without the addition of new features or new functionality. Sometimes this work is intended to help “pay technical debt” that has accumulated over the life of the project. As a result, users of the project may remain blissfully unaware of the significant work involved in such efforts. However, the importance of these “invisible” efforts cannot be understated.

One such effort within the OpenStack community is called neutron-lib (more information is available here). In a nutshell, neutron-lib is about two things:

  1. It aims to build a common networking library that Neutron and all Neutron sub-projects can leverage, with the eventual goal of breaking all dependencies between sub-projects.
  2. Pay down accumulated technical debt in the Neutron project by refactoring and enhancing code as it is moved to this common library.

To a user—using that term in this instance to refer to anyone using the OpenStack Neutron code—this doesn’t result in visible new features or functionality. However, this is high-priority work that benefits the entire OpenStack community, and benefits OpenStack overall by enhancing the supportability and stability of the code base over the long term.

Why do we bring this up? Well, it’s recently come to my attention that people may be questioning VMware’s commitment to the OpenStack projects. Since they don’t see new features and new functionality emerging, users may think that VMware has simply moved away from OpenStack.

Nothing could be further from the truth. VMware is deeply committed to OpenStack, often in ways, like the neutron-lib effort, that are invisible to users of OpenStack. It can be easy at times to overlook a vendor’s contributions to an open source project when those contributions don’t directly result in new features or new functionality. Nevertheless, these contributions are critically important for the long-term success and viability of the project. It’s not glorious work, but it’s important work that benefits the OpenStack community and OpenStack users.

Being a responsible member of an open source community means not only doing the work that garners lots of attention, but also doing the work that needs to be done. Here at VMware, we’re striving to be responsible members of the OpenStack community, tackling efforts, in conjunction and close cooperation with the community, that not only benefit VMware but that benefit the OpenStack community, the ecosystem, and the users.

In a future post, I’ll focus on some of the contributions VMware is making that will result in new functionality or new features. Until then, if you’d like more information, please visit http://www.vmware.com/products/openstack.html or contact us and follow us on Twitter @VMware_OS

Finally, don’t forget to visit our booth at the OpenStack Summit in Boston, May 8-12 2017.

VMware Integrated OpenStack (VIO) and NSX – Free webinar

On November 2nd, at 9 am PST/12 pm EST I will be hosting a free webinar, as part of our Getting More Out Of series, focused on OpenStack Integration with VMware NSX. We will also cover how easy it is to deploy VMware’s OpenStack distribution, VIO, and the Day-2 operational tools in the VMWare SDDC portfolio that make it possible for Cloud admins to properly monitor and optimize their OpenStack deployments.

As I mentioned in my 3-part blog series on Neutron-NSX integration, as more features are added to OpenStack (especially to Neutron), its architecture becomes more complex (a universal perception amongst OpenStack users). NSX mitigates these issues and provides a scalable and robust platform that incorporates Enterprise-grade network services into your OpenStack architecture.

Come and learn more about the benefits and participate in this unapologetically technical webinar, with live Q&A with our expert panel.

 

REGISTER NOW!

screenshot1

Also, don’t forget to visit us at the OpenStack Summit in Barcelona, where we will be talking about this and many other relevant topics.

¡Nos vemos en España!

Marcos

Advanced Security Services with Neutron, NSX and Palo Alto Next Generation Firewall

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:

screenshot1

screenshot2

  • Ensure the Service VMs (local firewalls) are properly registered and licensed in Panorama:

screenshot3

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

screenshot5

screenshot6

  • In Panorama, create a Dynamic Address Group for the OpenStack Instances, that corresponds to the NSX Security Group created in the previous step:

screenshot5-1

  • Then, in Panorama, create the Policy you want to apply to the redirected traffic:

screenshot6-8

  • 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.

  • screenshot7Finally, 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).

screenshot7

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:

Part 1: Next Generation Security Services in OpenStack

Part 2: Advanced Security Services in OpenStack and Fortinet

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.

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