Securing the Network in OpenStack Private Clouds

OpenStack has already begun to deliver on its promise of an open source community driven cloud orchestration tool with the flexibility that many large enterprises, service providers, and telecommunications companies desire. One needs only to look at the ballooning attendance of bi-annual OpenStack summit events and the user survey that they generate to see this.

There are some trends here that are pretty apparent. Many organizations want to build private, on the premises, clouds to satisfy their needs for flexible computing, storage, and networking resources. They appreciate having sovereignty over critical workloads and are willing to take responsibility for them, the associated compliance and regulatory requirements, and general security in exchange for the piece of mind that comes with being in control of their critical data, applications, and infrastructure, even in the face of ever sophisticated cyber attackers.

The responsibility for operating a highly available, high performance, secure OpenStack private cloud begs the question…If security is a motivating factor for building a private cloud, how do you secure the private cloud that you have built? A look at recent high profile data breaches highlights the obvious fact that valuable data lies within an organizations data center or private cloud. Additionally, studies on data center traffic patterns have shown that the bulk of traffic within these private clouds does not leave the perimeter with 80% not leaving the rack[1]. These two points highlight the gaping hole in data center security that is East West traffic.

The name of the game in OpenStack is scale out. Workloads and applications are designed with horizontal scaling in mind. Demand went up for an app? No problem, launch another instance and balance the load across. Demand for the app decreased? No problem, tear down that last instance. The hardware centric methods of manually wiring servers through IPS or other security devices, whether those wires and appliances are physical or virtual, do not translate will into this elastic dynamic world.

Perimeter defenses have their place no doubt. After all, you wouldn’t not install locks on the doors to your house just because some skilled burglars can pick locks would you? However, the requirements for securing any type of computing

environment have grown to include and emphasize detection and remediation of threats, attacks, and exploits in addition to defensive protection. The mandate to detect and remediate threats and attacks throughout the network must be extended into the OpenStack data center.

Thinking about the purposes and realities of the next generation private cloud type data center epitomized by an OpenStack deployment can lead us to understand the types of challenges that a proper network security solution for such an environment must address. We have already shed some light on the elephant in the room, East West traffic. Other factors in securing the OpenStack private cloud are: migration of workloads from one host to another, the constant addition and removal of new workload instances, and the variety of the security requirements of the workloads that may be encountered in an organization.

We can begin to draw some inferences from these challenges to help construct a solution. If a few physical appliances at the perimeter are unable to give us visibility into the East West traffic then we need a presence inside the data center that is distributed and scalable in its own right. If workloads are constantly migrating across physical hosts, then we need a way to logically group workloads by their security needs so that they continue to be covered by a security policy wherever they may land. If new VMs are powered up that are subject to security policy then we need a way to ensure that they are instantly protected. Last but obviously not least, we need a way to intelligently map security policies to the VMs that require them and we need a way to redirect network traffic from designated workload VMs (members of the logical groups) to security appliances that are capable of enforcing the proper policies.

Each of the above pieces plays a vital role in meeting the unique technical challenges of securing network traffic and thereby workloads within an OpenStack cloud that is buzzing with activity. We have the basic sketch of a solution; a distribution of network security appliances that are aware of groups of VMs and are able to enforce policy specific to those groups. However, we have introduced another issue; one of management and orchestration. How do we orchestrate, deploy, manage, group, bind policy, and ensure proper traffic routing for this distributed system? How do we efficiently use the compute network and storage resources of the environment?

Some virtualization platforms like VMware NSX have much of this functionality built into their offering. McAfee already provides a tightly integrated intrusion prevention offering for software-defined data centers using VMware NSX. However, for OpenStack clouds these capabilities are not included with a distribution.

This type of management and orchestration functionality is an important part of any scheme for network function virtualization. Nevertheless, security is a special type of virtualized network function that requires more regular interaction and management of deployed appliances. These appliance instances, in addition to the basic inspection and blocking functionality, provide critical alerting and messaging back to a security operations center. The security appliance need not know what the network topology is, and the network need not know how the security function works.  A middleware platform to abstract each from the other is a valuable tool that can be leveraged to cover various virtual infrastructure types and their management interfaces or to add more security services on top of the virtual infrastructure, like IPS or DLP for example.

The McAfee Security Controller is just such a platform. It has been designed and built to fulfill the orchestration and management needs of distributed software defined security for the next generation OpenStack data center. It presents clear value to organizations looking to cut down on error prone time consuming manual configurations, fills gaping holes in private cloud security posture (East West traffic inspection), supports heterogeneous private cloud infrastructures allowing for a uniform security policy application and enforcement, and enables major value adds for managed services and managed hosting types of environments.

The McAfee Security Controller is an open platform for the orchestration of security VNFs into OpenStack environments. It’s management and orchestration APIs are open and fully documented. It has a modular interface for interoperability with a variety of SDN controllers to translate the security intent into traffic flows in a variety of infrastructures. It is also open to the integration of any security VNF vendor who wishes to take advantage of its orchestration capabilities in the OpenStack world via SDKs for the relevant modules necessary to take a virtual appliance and turn it into an intelligent virtual appliance.

If you will be attending the OpenStack summit in Tokyo this October, attend the session “Inserting Advanced Network Security in OpenStack Clouds” to learn more.

 

 

[1] Benson, Theophilus, Aditya Akella, and David A. Maltz. “Network traffic characteristics of data centers in the wild.” Proceedings of the 10th ACM SIGCOMM conference on Internet measurement. ACM, 2010.

Leave a Comment

5 × four =