So you've decided to take the big plunge and build your own cloud. Congratulations! Now instead of merely having to build secure images, lock down your instances, and manage your data, you also have to secure the entire infrastructure
Some people like to think running a private cloud resolves the security issues associated with public providers like Amazon and Rackspace. But just because your cloud is behind your firewall doesn't mean the security issues fade away. You might not have to worry as much about multi-tenancy risks (maybe), but you’re now responsible for securing everything down to the physical hardware.
This can be especially difficult when using a younger platform like OpenStack, which is barely a year old and poorly documented. While I'm still learning a lot about OpenStack myself, in this tip I will discuss how to build a private cloud using OpenStack and cover some steps for deploying it securely based on my research and hands-on testing.
OpenStack: How to build a private cloud
The first step is to set up the right hardware and network environment. Although OpenStack allows you to deploy everything on a single flat network, this isn't ideal from a security perspective. Depending on the hypervisor and virtual networking interface you use, this could allow a guest virtual machine to sniff management traffic. I suggest you use at least two networks: one for management traffic, and one for your virtual machines (cloud instances) to talk to each other. This means you need two network cards in all your cloud compute nodes (the ones that run instances) and the network manager. These should run on different IP ranges.
Your network for the compute nodes and instances also needs to support VLAN tagging since that's the mechanism used to isolate traffic between "projects." A project is the equivalent of your Amazon EC2 account, except you can create and assign as many as you want. Each project has its own administrator and users, and all instances in a given project can talk to each other. This is enforced by assigning each project its own VLAN and pool of internal and external IP addresses.
Once you get your hardware and network set up, the next step is to determine where to deploy all the OpenStack components. A typical deployment will have one controller and a series of compute nodes. The controller runs the message server, database and other components to orchestrate the cloud, while the compute nodes run the instances. But you can also break out the individual pieces of the controller to improve performance, such as placing the MySQL server on a different physical box. The key, for security, is to ensure each of these pieces is installed on a secure host and that you only attach them to the network needed to keep the cloud running.
Only two pieces need to be exposed to the outside world (even if that's only your enterprise network): the API server/Web console (if enabled), and the network manager. These servers need to be hardened, and you can even look at using a third network interface to isolate back-end management traffic from user connections.
If you follow the default installation instructions, odds are these pieces aren't as secure as they could be. Here are a few specific changes to make:
* Use a designated user account for the MySQL server, not the root MySQL admin account. This account and password will be exposed on every cloud node even if you use certificate-based authentication, since all nodes need access to the database server.
* In your MySQL configuration file, restrict access to the server and your OpenStack user account to only approved IP addresses.
* Remove any OS components you don't need, and make sure you set the servers to only support key-based logins over SSH.
* By default MySQL and RabbitMQ (the message server) traffic is not encrypted. If you isolate the management network and harden the hosts, this shouldn't be too bad of a risk. If your cloud's network is prone to any sort of sniffing (for example, it shares the network with other servers), then you need to encrypt the traffic. You can use OpenSSL to handle this for MySQL and RabbitMQ. (I haven't personally tested this, so configuration might be a little rough).
Next, remember if you support the Web management console that, by default, it doesn't use SSL. This is more of a problem than with the other management components, since it is usually externally accessible. You will most definitely want to configure it to use Apache and SSL.
These are just a few of the basics to get you started. We've skipped over other issues like configuring CloudPipe (a special VPN developers can use to access their project instances), managing developer credentials, building secure images, or controlling hypervisors, but these steps will help you start your project with a foundation of a secure infrastructure.
About the author:
Rich Mogull has nearly 20 years experience in information security, physical security, and risk management. Prior to founding independent information security consulting firm Securosis, he spent seven years at Gartner Inc., most recently as a vice president, where he advised thousands of clients, authored dozens of reports and was consistently rated as one of Gartner's top international speakers. He is one of the world's premier authorities on data security technologies, including DLP, and has covered issues ranging from vulnerabilities and threats, to risk management frameworks, to major application security.
This was first published in June 2011