Author Archives: hernandezm

hernandezm

About hernandezm

Marcos Hernandez is VMware’s Network and Security Chief Technologist. He joined VMware (Nicira) and the Network and Security Business Unit (NSBU) in early 2013. He is responsible for supporting large Global Enterprise accounts and providing technical guidance around VMware's suite of networking products, including NSX. As a Chief Technologist, Marcos also participates in M&A due diligence panels, support of New Product Introductions (NPI) and partnering opportunities to help augment VMware’s relevance in the network and security space. Marcos has a background in datacenter networking design and expert knowledge in routing and switching technologies. Marcos holds CCIE certification #8283 and a Master’s Degree in Telecommunications from Universidad Politécnica de Madrid.

The Future For Network Engineers: Where We Are Today

A little over 7 years ago, shortly after joining VMware as a Network Virtualization Engineer, I published a blog post where I speculated on the possible evolution of the Network and Security Engineer roles, both key positions within IT staffs around the world tasked with designing, deploying and maintaining datacenter networks and firewalls.

 

The post generated some lighthearted controversy, as evidenced by the passionate comments you can read below that article. As a side note, you should know that I am super friendly with most of the folks who opined on my thoughts, as we keep meeting in the field, for various reasons.

 

Given that a lot has happened since that post, I thought it would be a good idea to reflect on the statements I made back then, check if they were right, or not, and take a guess again in terms of what the future holds. Let’s start with the concept of Network Virtualization itself and then explore some of the other predictions:

 

Is Network Virtualization a reality today?

 

Network Virtualization, this notion that one can simulate a network topology different from the physical one in order to provision connectivity for applications a lot faster, WAS a reality even at the time of my post. For years, networking vendors had been providing solutions that leveraged various encapsulation techniques, in order to propagate L2 or L3 traffic over trusted or untrusted transit networks (think “datacenter” vs. “the Internet”). IPsec, MPLS, VXLAN, Nicira’s Stateless TCP Transport (STT), etc., were all means used to achieve this goal, covering a wide array of use cases and justifications.

 

What we did at VMware was different though, and very revolutionary. We decided to decouple these encapsulation techniques from the network hardware and offer a virtual fabric that would work on top of literally any physical fabric, irrespective of the vendor who provided it. It is because of this decision that today you can use NSX to extend consistent application connectivity across clouds (private, hybrid and public), form factors (VMs running on multiple hypervisors, bare metal, containers and cloud native) and locations (datacenter, remote office or edge). The industry momentum behind SD-WAN, with VMware as one of the leaders in this space, is also proof that Network Virtualization goes beyond the datacenter.

 

What about security? What is the current state of affairs?

 

In my post, I imagined a world in which a particular security posture, let’s call it “a micro-segmentation policy”, could be defined and applied to target workloads regardless of cloud, location or format. Has that promised materialized itself in 2020?

 

Fortunately, the answer is yes.

 

Today, you can use NSX to define a security policy that is aligned with your business intent or compliance requirements, and then enforce it without worrying about where the application lives. I routinely demonstrate this multi-cloud support by showing a top-level security ruleset that looks and works the same for on-prem, AWS, Azure and some of the other public cloud offerings. What is more important, we now see technology that leverages the power of Machine Learning (ML) and Artificial Intelligence (AI) to help automate the creation and dissemination of such policies, while providing additional capabilities like malware and anomaly detection, next-gen antivirus and compliance attestation. Examples of these offerings are: vRealize Network Insight (holistic network and security visibility), NSX Intelligence (distributed analytics for providing granular network security policy recommendations), VMware Carbon Black Cloud (cloud-based analytics for providing endpoint security and protection) and VMware Secure State (cloud-native compliance engine).

 

Even more significant is the fact that this security is intrinsic. This means security is built-in and not bolted-on. These policies are embedded in the infrastructure (they are agentless), and they live, evolve and are decommissioned following the same lifecycle of the application. If an application is created, so is its security posture. If the application changes, or moves, so does its security posture. And finally, when an app is destroyed, the policy is automatically removed. From an operations perspective, this model has proven to be more efficient, less error-prone and obviously, more consistent than the alternatives.

 

What about the role of the Network Engineer itself? How has that changed?

 

In terms of how the role of a Network Engineer has evolved, I am going to go ahead and say that I was spot-on. This might sound like a boast, but bear with me.

 

Network Engineers, in particular Network Virtualization Engineers, have adopted operational models aligned with the core principles of DevOps and have acquired skills that leverage modern instrumentation, which allows them to create, manage and troubleshoot connectivity, security and elasticity policies in a consistent and repeatable manner. Current Network Engineers understand the application geometry and treat the network infrastructure that supports it as code. Furthermore, the rapid adoption of microservices has catapulted the importance of the Network Engineer role. The distributed nature of a microservices architecture means that a network is required to efficiently connect all these disparate services. Who better than an expert in networking to help design and operate the fabric that ties them all together?

 

VMware has open source and commercial solutions for all of the above: providers for the most popular DevOps frameworks (Terraform, Ansible, PowerShell, vRealize Automation, OpenStack Neutron, Public Cloud IaaS, Kubernetes and several others), and Service Mesh solutions, like Tanzu Service Mesh for automatic service discovery, service-to-service encryption, multi-cloud federation, observability and Service Level Objective (SLO) tracking, all leveraging the revolutionary concept of Global Namespaces.

 

So, was I right? If so, what’s next?

 

I think that my predictions were pretty accurate. The reason is very simple: my predictions were not mine alone. I rely on a fantastic team of thought leaders, amazing engineers and sales staffs that have all helped forge our own path. When you have access to this talent and this passion for an industry, you hard work pays off. This is why I believe that we have influenced our own destiny. This outcome is, in a way, a self-fulfilling prophecy.

 

In terms of what’s next, I will leave you with a teaser. Come join me and Dr. Bruce Davie, at VMworld 2020. For several years now, I have helped build and present the demos that accompany his daring predictions and thoughts with regards to our industry. The name of the breakout is, very apropos, “The Future of Networking with VMware NSX” and you can find it on the VMworld 2020 Content Catalog.

 

So maybe in another 7 years I will be checking in with you again to see if what we anticipated today becomes a reality then. In the meantime, keep investing in your network expertise, and keep innovating.

 

Marcos Hernandez

Chief Technologist, Network and Security

VMware

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