Secure VMs

The measures described so far are intended to minimize the attack surface of an OpenStack cloud and to mitigate the potential damage the attacker can cause if an attack succeeds. Virtualization in OpenStack also offers a starting point for boosting security.

The available tools depend on the kind of hypervisor you use. The security manual for OpenStack [1] states that KVM is the hypervisor that supports the largest number of external security mechanisms. This list includes sVirt, which is the SELinux virtualization solution, as well as AppArmor, Intel's Trusted Execution Technology (TXT), cgroups, and Mandatory Access Controls (MAC) at the Linux level.

Intel's TXT feature plays a special role, allowing only certain code to run on servers. OpenStack adopts this the feature in the form of trusted compute pools.

You can use these compute pools to group servers that support TXT. If customers then choose a trusted compute Pool (Figure 5) for their VMs, they can be sure that their VMs will only run on servers with TXT functionality. This setup is documented in the Admin Guide for OpenStack [2]. Even if you do not rely on TXT, you can still achieve good basic security using sVirt or AppArmor, which are both enabled out of the box on Ubuntu.

Figure 5: Trusted compute pools (based on Intel's TXT technology) let you define constraints for programs that run on cloud servers.

Sadly, many clouds run on Ubuntu systems on which AppArmor is explicitly disabled, because it does not harmonize well with the implemented storage solution in the default configuration and because the overhead involved with finding the appropriate configuration appears to be too troublesome. This approach is not useful, of course.

Something's Not Right

The last thing to consider is security monitoring. Even in conventional network settings, it is a challenge for admins to detect something going wrong. The problem is significantly greater in OpenStack: Customers can define access to the cloud and then do whatever they want in their VMs. Usually, the provider will adopt a policy of benign neglect.

But what happens if a project in the cloud affects the overall performance of the installation or interferes with other customers? The provider has to be proactive: It is important to monitor the cloud such that irregularities can be detected in a timely manner and then to take countermeasures.

Classic Nagios-style incident monitoring is not enough. A provider will want to detect pronounced changes in the volume of incoming or outbound traffic without any apparent reason. Graphing systems and time-series databases, such as open TSDB or Prometheus, offer a useful option for admins. These utilities draw various performance data on a timeline and also let you define thresholds. If the values for incoming and outbound traffic move outside these limits, the system alerts the admin to the potential problem.

Conclusions

When it comes to OpenStack, it is not the exciting, specialized technologies that help admins get a better night's sleep. Instead, ensuring good standards through system deployment and administration has a more positive effect.

The Author

Martin Gerhard Loschwitz is Head of Cloud with iNNOVO Cloud, where he focuses on HA, distributed storage, and OpenStack.