Merge "Add docs for limiting access to services"
This commit is contained in:
commit
3c539cfe1c
@ -8,12 +8,18 @@ OpenStack-Ansible. The default HAProxy configuration provides highly-available
|
|||||||
load balancing services via keepalived if there are more than one hosts in the
|
load balancing services via keepalived if there are more than one hosts in the
|
||||||
``haproxy_hosts`` group.
|
``haproxy_hosts`` group.
|
||||||
|
|
||||||
|
.. note::
|
||||||
|
|
||||||
|
Deployers must review the services exposed by HAProxy and **must limit access
|
||||||
|
to these services to trusted users and networks only**. For more details,
|
||||||
|
refer to the :ref:`least-access-openstack-services` section.
|
||||||
|
|
||||||
.. note::
|
.. note::
|
||||||
|
|
||||||
A load balancer is required for a successful installation. Deployers may
|
A load balancer is required for a successful installation. Deployers may
|
||||||
prefer to make use of hardware load balancers instead of haproxy. If hardware
|
prefer to make use of hardware load balancers instead of haproxy. If hardware
|
||||||
load balancers are used then the load balancing configuration for services must
|
load balancers are used then the load balancing configuration for services
|
||||||
be implemented prior to executing the deployment.
|
must be implemented prior to executing the deployment.
|
||||||
|
|
||||||
To deploy HAProxy within your OpenStack-Ansible environment, define target
|
To deploy HAProxy within your OpenStack-Ansible environment, define target
|
||||||
hosts which should run HAProxy:
|
hosts which should run HAProxy:
|
||||||
|
@ -11,8 +11,6 @@ Security requirements will always differ between deployers. For deployers
|
|||||||
that need additional security measures in place, please refer to the official
|
that need additional security measures in place, please refer to the official
|
||||||
`OpenStack Security Guide`_ for additional resources.
|
`OpenStack Security Guide`_ for additional resources.
|
||||||
|
|
||||||
.. _OpenStack Security Guide: http://docs.openstack.org/sec/
|
|
||||||
|
|
||||||
AppArmor
|
AppArmor
|
||||||
~~~~~~~~
|
~~~~~~~~
|
||||||
|
|
||||||
@ -70,6 +68,55 @@ database(s) that they need to query.
|
|||||||
|
|
||||||
.. _principle of least privilege: https://en.wikipedia.org/wiki/Principle_of_least_privilege
|
.. _principle of least privilege: https://en.wikipedia.org/wiki/Principle_of_least_privilege
|
||||||
|
|
||||||
|
.. _least-access-openstack-services:
|
||||||
|
|
||||||
|
Securing network access to OpenStack services
|
||||||
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
OpenStack environments expose many service ports and API endpoints to the
|
||||||
|
network. **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:
|
||||||
|
|
||||||
|
1. 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
|
||||||
|
|
||||||
|
2. Services that are only utilized internally by the OpenStack cloud.
|
||||||
|
|
||||||
|
* Keystone (admin API endpoint)
|
||||||
|
* MariaDB
|
||||||
|
* RabbitMQ
|
||||||
|
|
||||||
|
Users must be able to access certain public API endpoints, such as the Nova or
|
||||||
|
Neutron API, to manage instances. Deployers should configure firewalls to allow
|
||||||
|
access to these services, but that access should be limited to the fewest
|
||||||
|
networks possible.
|
||||||
|
|
||||||
|
Other services, such as MariaDB and RabbitMQ, **must be segmented away from
|
||||||
|
direct user access**. Deployers must 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`_
|
||||||
|
|
||||||
|
.. _API endpoint process isolation and policy: http://docs.openstack.org/security-guide/api-endpoints/api-endpoint-configuration-recommendations.html#network-policy
|
||||||
|
.. _OpenStack Security Guide: http://docs.openstack.org/security-guide
|
||||||
|
|
||||||
--------------
|
--------------
|
||||||
|
|
||||||
.. include:: navigation.txt
|
.. include:: navigation.txt
|
||||||
|
Loading…
x
Reference in New Issue
Block a user