How To Secure An OpenStack Cloud

Security is a key concern across all sectors of modern IT and is often noted as a primary barrier to adoption for cloud computing. Security was a key focus of many sessions at the OpenStack Summit, which ran from May 18 to May 22 in Vancouver, B.C. Several sessions covered how to properly deploy and configure OpenStack clouds securely. Security is also being baked into the development of OpenStack itself though a number of different initiatives.

OpenStack is now used in production deployments by some of the largest companies in the United States, including Walmart, Comcast, BestBuy, Time Warner Cable, AT&T and eBay. Recent exploits like VENOM, a virtual machine (VM) breakout, and Heartbleed, an SSL-related flaw, have affected OpenStack.

Robert Clark, lead security architect for HP’s Helion cloud and project technical lead (PTL) of the OpenStack Security Group, spoke in several sessions at the latest summit, and explained that many different technologies can be used on host operating systems and within OpenStack to provide security.

Best practices

Clark has been actively contributing to OpenStack to help improve security for several years. At the OpenStack Summit in Portland, Ore., in 2013, Clark discussed how the OpenStack Security Group (OSSG) was working on best practices and guidance for OpenStack deployment.

Clark explained that the OSSG recently incorporated the Vulnerability Management Team (VMT) within OpenStack, and it is now an official OpenStack project.

“The OpenStack Security project is responsible for providing a number of different services to OpenStack,” Clark said.

VMT is an autonomous group within the OpenStack Security Project, with the responsibly for responding quickly and confidentially to potential new security exploits. The VMT is the group that issues OpenStack security advisories while the larger OpenStack Security project will release security notes. The difference between an advisory and a note is that an advisory is for an immediate security issue that can be fixed. In contrast, a security note provides guidance and recommendations on best practices for deployment to reduce security risk.

The Security Project also produces the OpenStack Security Guide, an effort to provide a comprehensive set of guidelines for secure deployment of OpenStack. The group also performs threat analysis for OpenStack projects.

OpenStack Security Project manages a pair of tools to help developers make sure that OpenStack code is secure: The Anchor tool is an ephemeral public key infrastructure (PKI), and Bandit is a python security tool looking for coding errors.

“The Anchor project has a passive revocation system, which means that provisioning certificates is a lot safer,” Clark explained.

Best Practices

For Clark, best practices for OpenStack cloud deployment begin with hardware. He suggests that it’s important for an organization to be able to trust the hardware a cloud is running in order to be able to verify that it hasn’t been tampered with or modified.

A flat network where everyone has equal access is not a good idea for a cloud. Clark recommends that there be at least four domains in an organization that is deploying an OpenStack cloud: public, guest, management and data networks. The public and guest networks are largely untrusted while the management and data networks are trusted nodes.

Providing security in OpenStack is not as easy as simply deploying a firewall and enabling antivirus; many additional controls need to be deployed, Clark said. He advocates the use of defense in depth—multiple layers and combinations of tools and techniques.

“In all of our threat analysis and designs, at least at HP, we assume that all the virtual machines want to hurt us,” Clark said. “We assume that everything is completely hostile.”

Reducing the attack surface throughout the stack is very important. To that end, one key recommendation from Clark is to deploy only the applications needed on OpenStack nodes to deliver a specific service, rather than a full Linux distribution.

VENOM

Looking specifically at VM breakouts, like the recent VENOM exploit, Clark provided a number of recommendations on technologies and configurations that can be used to minimize risk.

“VM breakouts aren’t unicorns; they actually happen fairly regularly in the wild,” Clark said.

Since VM breakouts happen, there is a need to have VM containment strategies in place. One way to handle VM containment is with mandatory access controls, including Security Enhanced Linux (SELinux) and AppArmor. Mandatory access controls define how a process should behave and can block rogue processes and alert administrators when a process attempts to step outside of policy.

Looking beyond SELinux and AppArmor, Clark discussed the benefits of Secure Computing Mode (SECCOMP), which provides application sandboxing within Linux.

Linux also has an isolation technology, known as namespaces. Clark explained that with Linux namespace isolation, a defined namespace within Linux can be isolated from other namespaces. Linux Control Groups (CGroups) also can be used to limit and isolate resource use for a given Linux process.

Even with security controls in place to limit the risk of potential vulnerabilities, the ability to also update and patch a server is also important, Clark said. “Controls don’t fix things like VENOM. They just buy you time to react without breaking your business,” he said.

While multiple sets of controls and policies can be used to help secure an OpenStack cloud, “don’t use the default passwords,” Clark said.

Sean Michael Kerner is a senior editor at eWEEK and InternetNews.com. Follow him on Twitter @TechJournalist.