[ English | русский | Deutsch | Indonesia | español | English (United Kingdom) ]
Security is one of the top priorities within OpenStack-Ansible (OSA), and many security enhancements for OpenStack clouds are available in deployments by default. This section provides a detailed overview of the most important security enhancements.
Every deployer has different security requirements. The OpenStack Security Guide has instructions and advice on how to operate and consume an OpenStack cloud by using the most secure methods.
Any OpenStack cloud has sensitive information transmitted between services, including user credentials, service credentials or information about resources being created. Encrypting this traffic is critical in environments where the network cannot be trusted. (For more information about securing the network, see the Securing network access to OpenStack services section.)
Many of the services deployed with OpenStack-Ansible are encrypted by default or offer encryption as an option. The playbooks generate self-signed certificates by default, but deployers have the option to use their existing certificates, keys, and CA certificates.
To learn more about how to customize the deployment of encrypted communications, see Securing services with SSL certificates.
Host security hardening¶
OpenStack-Ansible provides a comprehensive security hardening role that applies over 200 security configurations as recommended by the Security Technical Implementation Guide (STIG) provided by the Defense Information Systems Agency (DISA). These security configurations are widely used and are distributed in the public domain by the United States government.
Host security hardening is required by several compliance and regulatory programs, such as the Payment Card Industry Data Security Standard (PCI DSS) (Requirement 2.2).
By default, OpenStack-Ansible automatically applies the ansible-hardening role to all deployments. The role has been carefully designed to perform as follows:
Apply nondisruptively to a production OpenStack environment
Balance security with OpenStack performance and functionality
Run as quickly as possible
For more information about the security configurations, see the security hardening role documentation.
By default, OpenStack-Ansible provides isolation by default between the containers that run the OpenStack infrastructure (control plane) services and also between the virtual machines that end users spawn within the deployment. This isolation is critical because it can prevent container or virtual machine breakouts, or at least reduce the damage that breakouts might cause.
The Linux Security Modules (LSM) framework allows administrators to set
mandatory access controls (MAC) on a Linux system. MAC is different than
discretionary access controls (DAC) because the kernel enforces strict
policies that no user can bypass. Although any user might be able to
change a DAC policy (such as
chown bob secret.txt), only the
can alter a MAC policy.
OpenStack-Ansible currently uses AppArmor to provide MAC policies on
infrastructure servers and hypervisors. The AppArmor configuration sets the
access policies to prevent one container from accessing the data of another
container. For virtual machines,
libvirtd uses the sVirt extensions to
ensure that one virtual machine cannot access the data or devices from another
These policies are applied and governed at the kernel level. Any process that
violates a policy is denied access to the resource. All denials are logged
auditd and are available at
The principle of least privilege is used throughout OpenStack-Ansible to limit the damage that could be caused if an attacker gains access to any credentials.
OpenStack-Ansible configures unique username and password combinations for each service that interacts with RabbitMQ and Galera/MariaDB. Each service that connects to RabbitMQ uses a separate virtual host for publishing and consuming messages. The MariaDB users for each service are only granted access only to the databases that they need to query.
Securing network access to OpenStack services¶
OpenStack clouds provide many services to end users, that enable them to build instances, provision storage, and create networks. Each of these services exposes one or more service ports and API endpoints to the network.
However, some of the services within an OpenStack cloud are accessible to all end users, while others are accessible only to administrators or operators on a secured network.
Services that all end users can access
These services include Compute (nova), Object Storage (swift), Networking (neutron), and Image (glance).
These services should be offered on a sufficiently restricted network that still allows all end users to access the services.
A firewall must be used to restrict access to the network.
Services that only administrators or operators can access
These services include MariaDB, Memcached, RabbitMQ, and the admin API endpoint for the Identity (keystone) service.
These services must be offered on a highly restricted network that is available only to administrative users.
A firewall must be used to restrict access to the network.
Limiting access to these networks has several benefits:
Allows for network monitoring and alerting
Prevents unauthorized network surveillance
Reduces the chance of credential theft
Reduces damage from unknown or unpatched service vulnerabilities
OpenStack-Ansible deploys HAProxy back ends for each service and restricts access for highly sensitive services by making them available only on the management network. Deployers with external load balancers must ensure that the back ends are configured securely and that firewalls prevent traffic from crossing between networks.
For more information about recommended network policies for OpenStack clouds, see the API endpoint process isolation and policy section of the OpenStack Security Guide