openstack
/
openstack-ansible
Code Issues Proposed changes

[DOCS] Applies edits to the OSA install guide appendix D 

Change-Id: I7a1a9e4bfabce38f8cfce48e1872542868db5dcb
Partial-bug: #1629798
(cherry picked from commit 7305644b2c)
This commit is contained in:
Ianeta Hutchinson 2016-10-05 14:25:01 -05:00 committed by Jesse Pretorius (odyssey4me)
parent a4f5e84d6c
commit 786b31ed59
1 changed files with 60 additions and 58 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

118
doc/source/install-guide/app-security.rst
View File

@ -2,25 +2,30 @@
Appendix D: Security
=====================
Security is one of the top priorities within OpenStack-Ansible and many
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 serves as a detailed overview of the most important
security improvements.
default. This appendix provides a detailed overview of the most important
security enhancements.
Every deployer will have different security requirements based on their
business needs, regulatory requirements, or end user demands. The official
`OpenStack Security Guide`_ has plenty of instructions and advice on how to
operate and consume an OpenStack cloud via the most secure methods.
For more information about configuring security, see `Appendix F`_.
.. _Appendix F: http://docs.openstack.org/developer/openstack-ansible/install-guide/app-advanced-config-options.html
.. note::
Every deployer has different security requirements based on
`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 will have sensitive information transmitted between
services. This information includes user credentials, service credentials or
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 may not be trusted.
*(Review the :ref:`least-access-openstack-services` section below for more
details on securing the network.)*
in environments where the network cannot be trusted. (For more information
about securing the network, see the :ref:`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
@ -28,34 +33,32 @@ 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, review the `Securing services with SSL certificates`_
documentation section.
communications, see `Securing services with SSL certificates`_.
.. _Securing services with SSL certificates: app-advanced-config-sslcertificates.html
.. _Securing services with SSL certificates: http://docs.openstack.org/developer/openstack-ansible/install-guide/app-advanced-config-options.html
Host security hardening
~~~~~~~~~~~~~~~~~~~~~~~
OpenStack-Ansible offers a comprehensive `security hardening role`_ that
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 uses and are
distributed in the public domain by the United States Government.
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) *(see Requirement 2.2)*.
DSS) (Requirement 2.2).
OpenStack-Ansible automatically applies the security hardening role to all
deployments by default, but this can be disabled via an Ansible variable. The
role has been carefully designed to:
By default, OpenStack-Ansible automatically applies the security hardening role
to all deployments. The role has been carefully designed to perform as follows:
* Apply non-disruptively to a production OpenStack environment
* Apply nondisruptively to a production OpenStack environment
* Balance security with OpenStack performance and functionality
* Run as quickly as possible
Refer to the documentation on :ref:`security_hardening` for more information
on the role in OpenStack-Ansible.
For more information about configuring the role in OpenStack-Ansible, see
:ref:`security_hardening`.
.. _security hardening role: http://docs.openstack.org/developer/openstack-ansible-security/
.. _Security Technical Implementation Guide: https://en.wikipedia.org/wiki/Security_Technical_Implementation_Guide
@ -65,29 +68,29 @@ on the role in OpenStack-Ansible.
Isolation
~~~~~~~~~
OpenStack-Ansible provides isolation by default between the containers that run
the OpenStack control plane services and also between the virtual machines that
end users spawn within the deployment. This isolation is critical since it can
prevent container or virtual machine breakouts, or at least reduce the damage
that they may cause.
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. This is different than
`mandatory access controls`_ (MAC) on a Linux system. MAC is different than
`discretionary access controls`_ (DAC) because the kernel enforces strict
policies that cannot be bypassed by any user. Although a user may be able to
change a DAC (such as ``chown bob secret.txt``), they cannot alter a MAC
policy. This privilege is reserved for the ``root`` user.
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 control
plane servers as well as hypervisors. The AppArmor configuration sets the
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 will be denied access to the resource. All denials are logged
within ``auditd`` and are available at ``/var/log/audit/audit.log``.
violates a policy is denied access to the resource. All denials are logged
in ``auditd`` and are available at ``/var/log/audit/audit.log``.
.. _Linux Security Modules: https://en.wikipedia.org/wiki/Linux_Security_Modules
.. _mandatory access controls: https://en.wikipedia.org/wiki/Mandatory_access_control
@ -103,10 +106,10 @@ 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
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 to the
database(s) that they need to query.
messages. The MariaDB users for each service are only granted access only to
the databases that they need to query.
.. _principle of least privilege: https://en.wikipedia.org/wiki/Principle_of_least_privilege
@ -115,28 +118,27 @@ database(s) that they need to query.
Securing network access to OpenStack services
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
OpenStack clouds offer many services to end users which allow them to build
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 clouds should be exposed to
all end users while others should only be available to administrators or
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.
OpenStack services fit into one of two criteria:
* Services that *all end users* can access
* Services that **all end users** can access
* This includes services such as nova, swift, neutron, and glance.
* These should be offered on a sufficiently restricted network that still
allows all end users to access the services.
* 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
* Services that *only administrators or operators* can access
* This includes services such as MariaDB, memcached, RabbitMQ and the admin
API endpoint for keystone.
* These services **must** be offered on a highly restricted network that is
* 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.
@ -147,14 +149,14 @@ Limiting access to these networks has several benefits:
* Reduces the chance of credential theft
* Reduces damage from unknown or unpatched service vulnerabilities
OpenStack-Ansible deploys HAProxy backends for each service and restricts
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
backends are configured securely and that firewalls prevent traffic from
back ends are configured securely and that firewalls prevent traffic from
crossing between networks.
For more details on recommended network policies for OpenStack clouds, refer
to the `API endpoint process isolation and policy`_ section from the
For more information about recommended network policies for OpenStack clouds,
see the `API endpoint process isolation and policy`_ section of the
`OpenStack Security Guide`_
.. _API endpoint process isolation and policy: http://docs.openstack.org/security-guide/api-endpoints/api-endpoint-configuration-recommendations.html#network-policy