The goal of this spec is to apply hardening standards to openstack-ansible so that users can build environments that meet the requirements of various compliance programs, such as the Payment Card Industry Data Security Standard (PCI-DSS). These changes won’t make a particular environment PCI compliant, but they should bring the environment in compliance with Requirement 2.2 from PCI-DSS. That requirement states that deployments must follow an industry-accepted hardening standard.
Compliance programs, such as PCI-DSS, often have a requirement for using industry-accepted hardening standards for all deployments. At the moment, deployments done on Ubuntu 14.04 with openstack-ansible meet many, but not all, security hardening standards that are approved within PCI-DSS.
PCI-DSS 3.1 Requirement 2.2 states that deployments that handle credit card data must be secured with industry-accepted hardening standards. The test of the requirement is as follows:
2.2 Develop configuration standards for all system components. Assure that these standards address all known security vulnerabilities and are consistent with industry-accepted system hardening standards.
The United States Defense Information Systems Agency (DISA) publishes sets of security hardening guides called Security Technical Implementation Guides (STIGs). They’re comprehensive and they provide mechanisms for checking secured systems for compliance with the standards. In addition, they are in the public domain.
The proposed changes include:
Here are several examples of security improvements recommended by the RHEL 6 STIG which apply well to Ubuntu:
No known alternatives.
Depending on the nature of the change and the usefulness to deployers, the changes may be applied directly to existing roles in openstack-ansible or they may be applied to security hardening role that is optionally pulled in during openstack-ansible deployments
Any changes which could affect the performance, stability, or functionality of a production deployment would be disabled by default and heavily documented. Deployers could then make an educated decision on whether or not they want that security hardening standard enabled.
If security features are added via feature flags and disabled by default, the effect on upgrades would be very minimal if they’re even noticed at all. All configuration changes should be examined individually to determine if they will have an impact on upgrades.
The entire goal of this spec is to have a positive security impact without becoming an operational burden.
It’s possible that some security changes could impact the performance of a running OpenStack system. As noted in Upgrade impact above, these configuration changes would need to be examined individually to determine the balance between security and performance impacts.
End users shouldn’t notice the majority of the security changes. They will still interact with API endpoints and virtual machines as they do today. There’s a chance that some security improvements could impact an end user, but deployers will have full control of how those improvements are applied.
Deployers could potentially be able to build OpenStack systems that are more secure by default. However, if these security features are disabled by default, we need solid documentation that tells users how to enable these features and what the impact of enabling those features might be.
Deployers would need to explicitly include the security hardening role within their openstack-ansible deployments.
Developers would need to include the security hardening role within their deployments if they wanted to test openstack-ansible with additional security enhancements.
This spec has no dependencies.
Who is leading the writing of the code? Or is this a blueprint where you’re throwing it out there to see who picks it up?
If more than one person is working on the implementation, please designate the primary author and contact.
The security hardening role should be in a separate repository titled openstack-ansible-security. Once the role has content and is well-tested against openstack-ansible, it could be added as an optional dependency within openstack-ansible. Documentation for the new role could be added into the existing openstack-ansible documentation to make it easier for openstack-ansible users to reference it.
The other work items are in the Proposed change section above in a numbered list. Each configuration change should come with documentation about the change.
The usual gate checks can be used for these changes. Also, each individual commit can be tested individually.
Documentation is a critical piece of this spec, and it’s the first step in the process. It would be helpful to get the documentation team to weigh in on some of the documentation changes to ensure it makes sense for deployers.
Mailing list thread: