openstack-ansible/deploy-guide/source/app-security.rst

Appendix D: Security

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 appendix provides a detailed overview of the most important security enhancements.

For more information about configuring security, see Appendix F.

Note

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.

Encrypted communication

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 least-access-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 security 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 configuring the role in OpenStack-Ansible, see security_hardening.

Isolation

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 root user 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 virtual machine.

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 in auditd and are available at /var/log/audit/audit.log.

Least privilege

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