Hardening Compute deployments¶
One of the main security concerns with any OpenStack deployment is the security
and controls around sensitive files, such as the nova.conf file.
Normally contained in the /etc directory, this configuration file
contains many sensitive options including configuration details and service
passwords. All such sensitive files should be given strict file level
permissions, and monitored for changes through file integrity monitoring (FIM)
tools such as iNotify or Samhain. These utilities will take a hash of the
target file in a known good state, and then periodically take a new hash of the
file and compare it to the known good hash. An alert can be created if it was
found to have been modified unexpectedly.
The permissions of a file can be examined my moving into the directory the file is contained in and running the ls -lh command. This will show the permissions, owner, and group that have access to the file, as well as other information such as the last time the file was modified and when it was created.
The /var/lib/nova directory is used to hold details about the instances
on a given compute host. This directory should be considered sensitive as well,
with strictly enforced file permissions. Additionally, it should be backed up
regularly as it contains information and metadata for the instances associated
with that host.
If your deployment does not require full virtual machine backups, we recommend
excluding the /var/lib/nova/instances directory as it will be as large
as the combined space of each vm running on that node. If your deployment does
require full VM backups, you will need to ensure this directory is backed up
successfully.
Monitoring is a critical component of IT infrastructure, we recommend the Compute logfiles be monitored and analyzed so that meaningful alerts can be created.
OpenStack vulnerability management team¶
We recommend keeping up to date on security issues and advisories as they are published. The OpenStack Security Portal is the central portal where advisories, notices, meetings, and processes can be coordinated. Additionally, the OpenStack Vulnerability Management Team (VMT) portal coordinates remediation within the OpenStack project, as well as the process of investigating reported bugs which are responsibly disclosed (privately) to the VMT, by marking the bug as ‘This bug is a security vulnerability’. Further detail is outlined in the VMT process page and results in an OpenStack Security Advisory (OSSA). This OSSA outlines the issue and the fix, as well as linking to both the original bug, and the location where the where the patch is hosted.
OpenStack security notes¶
Reported security bugs that are found to be the result of a misconfiguration, or are not strictly part of OpenStack are drafted into OpenStack Security Notes (OSSNs). These include configuration issues such as ensuring Identity provider mappings as well as non-OpenStack but critical issues such as the Bashbug/Ghost or Venom vulnerabilities that affect the platform OpenStack utilizes. The current set of OSSNs is in the Security Note wiki.
OpenStack-dev mailinglist¶
All bugs, OSSAs and OSSNs are publicly disseminated through the openstack-discuss mailinglist with the [security] topic in the subject line. We recommend subscribing to this list as well as mail filtering rules that ensure OSSNs, OSSAs, and other important advisories are not missed. The openstack-discuss mailinglist is managed through OpenStack Development Mailing List. The openstack-discuss uses tags as defined in the Project Team Guide.
Hypervisor mailinglists¶
When implementing OpenStack, one of the core decisions is which hypervisor to utilize. We recommend being informed of advisories pertaining to the hypervisor(s) you have chosen. Several common hypervisor security lists are below:
- Xen:
- VMWare:
- Others (KVM, and more):
