daz a4053a927d [docs] Revise overview chapter in OSA install guide

1. Tidy up index.rst
2. Move targethosts-network.rst content to overview chapter
3. Move LXC commands section to dev docs
4. Add host layout diagrams
5. Installation workflow section - move Network ranges
subsection to Network Architecture section

Change-Id: Idea40a7d8f4cd9926876a57f7cfb3162c0c7dd82
Implements: blueprint osa-install-guide-overhaul

2016-07-01 03:23:05 +00:00

4.5 KiB

Raw Blame History

Home OpenStack-Ansible Installation Guide

Security

The OpenStack-Ansible project provides several security features for OpenStack deployments. This section of documentation covers those features and how they can benefit deployers.

Security requirements always differ between deployers. If you require additional security measures, refer to the official OpenStack Security Guide for additional resources.

AppArmor

The Linux kernel offers multiple security modules (LSMs) that that set mandatory access controls (MAC) on Linux systems. The OpenStack-Ansible project configures AppArmor. AppArmor is a Linux security module that provides additional security on LXC container hosts. AppArmor allows administrators to set specific limits and policies around what resources a particular application can access. Any activity outside the allowed policies is denied at the kernel level.

AppArmor profiles that are applied in OpenStack-Ansible limit the actions that each LXC container may take on a system. This is done within the lxc_hosts role.

Encrypted communication

Data in transit is encrypted between some OpenStack services in OpenStack-Ansible deployments. For more details on what traffic is encrypted, and how to configure SSL certificates, see Securing services with SSL certificates.

Host security hardening

Security hardening is applied by default to OpenStack infrastructure and compute hosts using the openstack-ansible-security role. The purpose of the role is to apply as many security configurations as possible without disrupting the operation of an OpenStack deployment.

Refer to the documentation on security_hardening for more information on the role and how to enable it in OpenStack-Ansible.

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 talks to 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 to the database(s) that they need to query.

Securing network access to OpenStack services

OpenStack environments expose many service ports and API endpoints to the network.

Note

Deployers must limit access to these resources and expose them only to trusted users and networks.

The resources within an OpenStack environment can be divided into two groups:

Services that users must access directly to consume the OpenStack cloud.
- Aodh
- Cinder
- Ceilometer
- Glance
- Heat
- Horizon
- Keystone (excluding the admin API endpoint)
- Neutron
- Nova
- Swift
Services that are only utilized internally by the OpenStack cloud.
- Keystone (admin API endpoint)
- MariaDB
- RabbitMQ

Configure firewalls to limit network access to all services that users must access directly.

Other services, such as MariaDB and RabbitMQ, must be segmented away from direct user access. Configure a firewall to only allow connectivity to these services within the OpenStack environment itself. This reduces an attacker's ability to query or manipulate data in OpenStack's critical database and queuing services, especially if one of these services has a known vulnerability.

For more details on recommended network policies for OpenStack clouds, refer to the API endpoint process isolation and policy section from the OpenStack Security Guide

4.5 KiB Raw Blame History