If you weren’t able to make it, don’t fret! This post will cover some of the main points of the talk and link to the video and slides.
I’ve recently updated this blog and icanhazip.com to enable HTTP/2! This probably won’t have much of an effect on users who query icanhazip.com with automated tools, but it should deliver the content on this blog a little faster. If you’re using an older, non-HTTP/2 client — don’t worry. All of the sites will continue working for you as they always have.
Head on over to Wikipedia to learn more about HTTP/2 and its benefits.
Also, I’ve revised the list of allowed TLS ciphers so that stronger ciphers are required. If you’re having issues with a particular client, please let me know.
If you want to learn more about load balancers and security hardening in OpenStack clouds, join me on Thursday for the Rackspace Office Hours podcast! Walter Bentley, Kenneth Hui and I will be talking about some of the new features available in the 12.2 release of Rackspace Private Cloud powered by OpenStack.
The release has a tech preview of OpenStack’s Load Balancer as a Service project. The new LBaaSv2 API is stable and makes it easy to create load balancers, add pools, and add members. Health monitors can watch over servers and remove those servers from the load balancers if they don’t respond properly.
I talked about the security hardening feature extensively at this year’s OpenStack Summit in Austin and it is now available in the 12.2 release of RPC.
The new Ansible role and its tasks apply over 200 security hardening configurations to OpenStack hosts (control plane and hypervisors) and it comes with extensive auditor-friendly documentation. The documentation also allows deployers to fine-tune many of the configurations and disable the ones they don’t want. Deployers also have the option to tighten some configurations depending on their industry requirements.
Join us this Thursday, July 21st, at 1:00 PM CDT (check your time zone) to talk more about these new features and OpenStack in general.
With the upcoming Red Hat Summit 2016 in San Francisco almost upon us, I decided to update the old SELinux shirts with two new designs:
You can buy these now over at Spreadshirt! There are styles there for men and women and I’ve priced them as low as the store will allow.
Spreadshirt is also running a sale for 15% off T-shirts until June 21st with the code
TSHIRT16. Let’s make SELinux enforcing again!
Lots of work has gone into the openstack-ansible-security Ansible role since I delivered a talk about it last month at the OpenStack Summit in Austin. Attendees asked for quite a few new features and I’ve seen quite a few bug reports (and that’s a good thing).
Here’s a list of the newest additions since the Summit:
Ubuntu 16.04 LTS (Xenial) support
The role now works with Ubuntu 16.04 and its newest features, including systemd. You can use the same variables as you used with Ubuntu 14.04 and it should take the same actions. Documentation updates are mostly merged with a few straggling reviews in the queue.
CentOS 7 support
With all of the work going into the role to support Ubuntu 16.04 and systemd, CentOS 7 wasn’t a huge stretch. Many of the package names and file locations were a little different, but those are now moved out into variables files to reduce the repetition of tasks. Some of the Linux Security Module tasks needed adjustments since SELinux is a different beast than AppArmor.
Following the STIG more closely
One of the common questions I had at the summit was: “Can I use this thing on my non-OpenStack environments?” You definitely can, but many of the configurations were tweaked to avoid causing problems with OpenStack environments. Some users asked if the configurations could be made more generic so that they followed the STIG more closely. This would reduce some compliance headaches and allow more people to use the role.
So far, I’ve been making some of these adjustments to fix more things rather than simply checking them. That should make it easier to get closer to the STIG’s requirements.
Another proposed idea is to create vars files that meet different criteria. For example, one vars file might be the ultra-secure, follow-the-STIG-to-the-letter configuration. This would be good for users that already know they want to apply the STIG’s requirements fully. There could be another vars file that would apply most of the STIG’s requirements, but it would steer clear of changing anything that could disrupt a production OpenStack environment.
Here are a subset of the future plans and ideas:
- Better reporting for users who need to feed data into vulnerability management applications or SIEMs for compliance checks
- Better testing, possibly with customized OpenSCAP XCCDF files
- Cross-referenced controls to other hardening guides, such as CIS Benchmarks
If you have any other ideas, feel free to stop by
#openstack-security on Freenode. You can find me there as mhayden and I would really enjoy hearing about your use cases!
Photo credit: Mikecogh