Securing OpenStack Hosts with Ansible

Deploying OpenStack can be a challenging process, and securing it can be even more daunting. Fortunately, there's a new project in the OpenStack big tent that wants to make this process easier: openstack-ansible-security.

The STIG is a collection of best practices for securing a host and its services against common attacks. The collection is broken up into multiple sections, called categories. The STIG Viewer service makes these categories easier to review. The categories include:

Cat 1: For highly sensitive systems

Cat 2: For medium sensitivity systems

Cat 3: For low sensitivity systems

These are meant to be stackable, so an extremely sensitive system would require categories 1, 2 and 3. Each STIG item provides a description of what needs to be changed, why it should be changed, how to change it, and how to verify the change.

Enter Ansible

Ansible makes it easier to build consistent environments without agents, daemons, or lots of extra packages. It also simplifies dependencies of roles and tasks. Developers can build fully idempotent playbooks which can be run against multiple servers that may have varying levels of configuration.

OpenStack's openstack-ansible project will deploy a fully functional OpenStack environment on a single host or on several hosts. This project is different than the OpenStack modules provided in Ansible since those modules are intended to be used with an already deployed OpenStack infrastructure.

The openstack-ansible-security role is designed to work alongside the openstack-ansible project, but it can be applied to non-OpenStack systems as well. However, the openstack-ansible-security role is designed to take the RHEL 6 STIG requirements and apply them to Ubuntu 14.04. That's because the openstack-ansible project only supports Ubuntu 14.04 for the Liberty release.

Many of the RHEL 6 STIG requirements translate easily into Ubuntu systems, but some require additional work. Certain tasks must use apt rather than yum or dpkg rather than rpm. Some configuration files end up in different places on an Ubuntu system and those translations are documented within the Ansible task files.

Role Details

The openstack-ansible-security role contains tasks that are broken out per category, per service, and per guideline itself. This allows deployers to consider which changes they want to apply using --tags or --skip-tags. In addition, the defaults/main.yml file contains heavily-documented configuration variables that deployers can use to further fine-tune their security improvements. Most of those have been set to sane defaults that provide the greatest security benefit without causing disruption to a production OpenStack system.

Each change is documented and any exceptions to the STIG's requirements are also documented. Exceptions arise for those changes that could disrupt a running system or other changes which are very difficult to automate.

How Can I Help?

All 264 STIG requirements are currently either in the repository or proposed in OpenStack Gerrit reviews. If you have an OpenStack account and you'd like to help with the reviews, here's the process:

Once the reviews are completed, there are a few tasks left over. For example, some tasks could be consolidated to speed up the deployment and the role will need a solid integration with the openstack-ansible role.

Going to OpenStack Summit?

If you're headed to Tokyo, don't forget to stop by the Rackspace booth and grab yourself a bit of Ansible swag! And mark your schedules to catch some of our speakers -- many of whom will be talking about how we use Ansible with OpenStack. Ansible's "Playbook for OpenStack Summit" blog post can help you find them, so be sure to say hello!

Major Hayden works on OpenStack private clouds, information security, and automation as a Principal Architect at Rackspace. He's a contributor to Ansible, the Fedora Project, and several other open source software projects.