Jimmy McCrory 9cd42929c3 Support cidr_networks in L3 network environments

In some environments, a single container, storage, or tunnel network may
not be applicable to every host. Each configured provider_network would
need to be limited to a particular subset of hosts and the host var keys
within the inventory for container_address, storage_address, and
tunnel_address will need to be maintained since they're specifically
required by various playbooks.

Add two new options for configuring provider_networks, 'reference_group'
and 'address_prefix'.

'reference_group' for providing a group name that any host must
be a member of, in addition to any of the groups listed in
'group_binds', for the network to be applied.

'address_prefix' for overriding the name of the key created for each IP
address allocated by a cidr_network. By default, this key is named
'cidr_network'_address, where 'cidr_network' is the given 'ip_from_q'
option for a provider network.

Closes-Bug: 1650356

Change-Id: Ia7f3119f0affc4fb6be97ca788ca3b46096b82a8

2017-07-31 22:14:25 +00:00

7.4 KiB

Raw Blame History

Appendix E: 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 :deploy_guide:Appendix H <app-advanced-config-options.html>.

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 :deploy_guide:Securing services with SSL certificates <app-advanced-config-sslcertificates.html>.

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

7.4 KiB Raw Blame History