An OpenStack security primer

Like other large software development efforts, OpenStack is divided into project teams. There is a marketing team, engineering which is in turn composed of sub-teams, leadership, systems engineering, event coordination and so on.

One critical area, particularly in light of recent news and industry trends is security, which is provided in OpenStack by the Security project team. The purpose of this article is to introduce the Security project and the resources we provide, give pointers for further reference and hopefully convince a few of you to join us!

Let’s get started.

Officially the OpenStack Security project has well over 200 members, but in reality, at any given time we’re about 25 strong. Of those, four are dedicated to the Vulnerability Management Team (VMT) — aka the firefighters of OpenStack. We’ll come back to the VMT shortly. The remaining members collaborate on tools, documentation, consulting and initiatives aimed at making OpenStack the most secure cloud technology.

Let’s start with a brief security warm-up. Here are two pretty similar lines of Python code:

z9ibqqlfxi7pxc9mdiak

Know the difference? The first executes code (with user input) directly on a shell, is very dangerous, and may lead to you and those around you having a very bad day. Bandit (developed by the Security project, and available on PyPI and GitHub) is a tool that scans Python source code for security mistakes, and is designed to help the busy developer pick the right choice and skip the bad day. It is open source (Apache License 2.0), easy to use, and runs fairly quickly against even large codebases. It’s configurable, tests for dozens of pitfalls like the one above, and includes documentation describing each test. It won’t write secure code for you but should be in every Python developer’s arsenal.

At this point, you might be thinking: “Interesting, I didn’t know that about Popen. I’d like to know more but I’m pretty busy and don’t want to spend a chunk of my day becoming a ‘subprocess’ expert.” You’re not alone! Developers should be free to create cool things and not get bogged down in security details.

In the spirit of enabling developers, we’ve created a set of Secure Development Guidelines to quickly answer: “What’s the deal?”, “what should I avoid doing?”, “what should I do instead”, and “what might happen if I do it the wrong way?” Think of it as the security Cliffs Notes for the busy developer.

Our newest project, Syntribos, is an open source API-fuzzing tool (available on PyPI and coming soon to OpenStack GitHub). Most OpenStack services are REST API based and Syntribos was created to detect new input sanitization, denial of service, and other interesting attack vectors. Though still in the early development stages, we’re expecting cool things from this tool.

Beyond the cool tools, our most important goal is to help our users, the cloud deployers make their own OpenStack deployments secure. The first stop for both new and existing deployers interested in security should be the OpenStack Security Guide. Here you’ll find the latest advice on topics including deploying TLS, selecting a hypervisor and locking down database instances. It’s frequently updated and aims to provide concise guidance and even security checklists.

Deployers should also consider our Security Notes which describe common configuration issues, problems with third-party components, issues in older versions without a backported fix (you ARE running the bleeding edge, aren’t you?), and other general issues that a patch isn’t available for. The notes are categorized so you can quickly find notes which pertain to a component, for example Keystone. To date we have published 60 notes and counting.

Switching gears for a moment, you know what’s pretty broken? Certificate revocation. In fact, a common mechanism for revocation, certificate revocation lists, are so broken most browsers don’t even bother to download them, and if it did try an attacker might just block the connection.

This brings us to Anchor, an innovative approach to the certificate revocation problem. Anchor advocates, and implements, an ephemeral PKI system for your cloud which means that even if an attacker does gain one of the certificates for your critical infrastructure his access will automatically die in a short period of time. It is particularly good for securing environments like OpenStack where the ability to have TLS everywhere is highly desirable. Anchor is an open-source project and is available on PyPI and Github.

Last but not least, let’s mention the Vulnerability Management Team (VMT). When new security issues are discovered the VMT handles the whole process, from initial disclosure to embargoed release, and finally public disclosure when an adequate fix has been developed and tested. The process is well tested and described in detail here: https://security.openstack.org/vmt-process.html. They issue advisories to registered stakeholders so that our customers can stay one step ahead of the bad guys. Next time you see them at a Summit consider buying a beverage for them – I know I will!

These are the projects that we’re currently working on and maintaining, but we’re always looking for cool new ideas and new members.

If you’d like to get involved in one of these projects or have an idea of your own to make OpenStack more secure come visit us in #openstack-security on FreeNode IRC or join one of our weekly meetings (1700 UTC in #openstack-meeting-alt). Alternatively, drop an email on the OpenStack Developers mailing list (use the tag [security]) and introduce yourself and what you’re interested in.

We hope to see you soon.

This post was contributed by Travis McPeak, security architect at Hewlett-Packard Helion, and the OpenStack security team. Superuser is always interested in how-tos and other contributions, please get in touch: [email protected]

Cover Photo by Clement127 // CC BY NC