Edits to the security-doc
Change-Id: I7f8f04b725378e5ae33a315098a48705a1809648 Implements: blueprint sec-guide-overhaul
This commit is contained in:
Alexandra Settle
parent
c21cdeac76
commit
5ad42487de
|
|
@ -2,17 +2,16 @@
|
|||
Compute
|
||||
=======
|
||||
|
||||
The OpenStack Compute service (nova) is one of the more complex OpenStack
|
||||
services. It runs in many locations throughout the cloud and interacts with a
|
||||
variety of internal services. The OpenStack Compute service offers a variety
|
||||
of configuration options which may be deployment specific. In this chapter
|
||||
we will call out general best practice around Compute security as well as
|
||||
specific known configurations that can lead to security issues. In general,
|
||||
the ``nova.conf`` file and the ``/var/lib/nova`` locations should be
|
||||
secured. Controls like centralized logging, the ``policy.json`` file, and
|
||||
a mandatory access control framework should be implemented. Additionally,
|
||||
there are environmental considerations to keep in mind, depending on what
|
||||
functionality is desired for your cloud.
|
||||
The OpenStack Compute service (nova) runs in many locations throughout
|
||||
the cloud and interacts with a variety of internal services.
|
||||
The OpenStack Compute service offers a variety of configuration options
|
||||
which may be deployment specific.
|
||||
|
||||
In this chapter we will call out general best practice around Compute
|
||||
security as well as specific known configurations that can lead to
|
||||
security issues. The ``nova.conf`` file and the ``/var/lib/nova`` locations
|
||||
should be secured. Controls like centralized logging, the ``policy.json``
|
||||
file, and a mandatory access control framework should be implemented.
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
|
|
|||
|
|
@ -2,20 +2,20 @@
|
|||
Dashboard
|
||||
=========
|
||||
|
||||
Horizon is the OpenStack dashboard that provides users a self-service portal to
|
||||
provision their own resources within the limits set by administrators. These
|
||||
include provisioning users, defining instance flavors, uploading VM images,
|
||||
managing networks, setting up security groups, starting instances, and
|
||||
accessing the instances through a console.
|
||||
The Dashboard (horizon) is the OpenStack dashboard that provides users a
|
||||
self-service portal to provision their own resources within the limits set
|
||||
by administrators. These include provisioning users, defining instance flavors,
|
||||
uploading virtual machine (VM) images, managing networks, setting up security
|
||||
groups, starting instances, and accessing the instances through a console.
|
||||
|
||||
The dashboard is based on the Django web framework, therefore secure deployment
|
||||
practices for Django apply directly to horizon. This guide provides a popular
|
||||
The Dashboard is based on the Django web framework, ensuring secure deployment
|
||||
practices for Django apply directly to horizon. This guide provides a
|
||||
set of Django security recommendations. Further information can be found by
|
||||
reading the `Django documentation <https://docs.djangoproject.com/>`__.
|
||||
reading the `Django documentation <https://docs.djangoproject.com/>`_.
|
||||
|
||||
The dashboard ships with reasonable default security settings, and has good
|
||||
The Dashboard ships with default security settings, and has
|
||||
`deployment and configuration documentation
|
||||
<https://docs.openstack.org/developer/horizon/topics/deployment.html>`__.
|
||||
<https://docs.openstack.org/developer/horizon/topics/deployment.html>`_.
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
|
|
|||
|
|
@ -2,13 +2,13 @@
|
|||
Data processing
|
||||
===============
|
||||
|
||||
The Data processing service for OpenStack (sahara) provides a platform
|
||||
The Data Processing service (sahara) provides a platform
|
||||
for the provisioning and management of instance clusters using processing
|
||||
frameworks such as Hadoop and Spark. Through the OpenStack dashboard
|
||||
or REST API, users will be able to upload and execute framework
|
||||
frameworks such as Hadoop and Spark. Through the OpenStack Dashboard,
|
||||
or REST API, users are able to upload and execute framework
|
||||
applications which may access data in object storage or external
|
||||
providers. The data processing controller uses the Orchestration
|
||||
service to create clusters of instances which may exist as
|
||||
service (heat) to create clusters of instances which may exist as
|
||||
long-running groups that can grow and shrink as requested, or as
|
||||
transient groups created for a single workload.
|
||||
|
||||
|
|
|
|||
|
|
@ -6,10 +6,11 @@ The choice of database server is an important consideration in the
|
|||
security of an OpenStack deployment. Multiple factors should be
|
||||
considered when deciding on a database server, however for the scope of
|
||||
this book only security considerations will be discussed. OpenStack
|
||||
supports a variety of database types (see `OpenStack Administrator
|
||||
Guide <https://docs.openstack.org/admin-guide/>`__ for more
|
||||
information). The Security Guide currently focuses on PostgreSQL and
|
||||
MySQL.
|
||||
supports a variety of database types. See the `OpenStack Administrator
|
||||
Guide <https://docs.openstack.org/admin-guide/>`_ for more
|
||||
information.
|
||||
|
||||
The Security Guide currently focuses on PostgreSQL and MySQL.
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
|
|
|||
|
|
@ -6,11 +6,11 @@ Identity service (keystone) provides identity, token, catalog, and
|
|||
policy services for use specifically by services in the OpenStack
|
||||
family. Identity service is organized as a group of internal services
|
||||
exposed on one or many endpoints. Many of these services are used in a
|
||||
combined fashion by the frontend, for example an authenticate call will
|
||||
validate user/project credentials with the identity service and, upon
|
||||
success, create and return a token with the token service. Further
|
||||
information can be found by reading the `Keystone Developer
|
||||
Documentation <https://docs.openstack.org/developer/keystone/index.html>`__.
|
||||
combined fashion by the front end. For example, an authentication call
|
||||
validates user and project credentials with the identity service.
|
||||
If successful, it will create and return a token with the token service.
|
||||
More information can be found by reading the `keystone Developer
|
||||
Documentation <https://docs.openstack.org/developer/keystone/index.html>`_.
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ that bring improved information assurance for cloud tenants.
|
|||
|
||||
Deployers or users of OpenStack with strong security requirements
|
||||
may want to consider deploying these technologies. Not all are
|
||||
applicable in every situation, indeed in some cases technologies may
|
||||
applicable in every situation. In some cases, technologies may
|
||||
be ruled out for use in a cloud because of prescriptive business
|
||||
requirements. Similarly some technologies inspect instance data such
|
||||
as run state which may be undesirable to the users of the system.
|
||||
|
|
|
|||
|
|
@ -5,8 +5,7 @@ Introduction
|
|||
The OpenStack Security Guide is the result of a five day sprint of
|
||||
collaborative work of many individuals. The purpose of this document is
|
||||
to provide the best practice guidelines for deploying a secure OpenStack
|
||||
cloud. It is a living document that is updated as new changes are merged
|
||||
into the repository, and is meant to reflect the current state of
|
||||
cloud. It is designed to reflect the current state of
|
||||
security within the OpenStack community and provide frameworks for
|
||||
decision making where listing specific security controls are not
|
||||
feasible due to complexity or other environment specific details.
|
||||
|
|
|
|||
|
|
@ -9,13 +9,13 @@ applied, these changes must be made in a secure, but convenient,
|
|||
fashion. These changes are typically solved through configuration
|
||||
management.
|
||||
|
||||
Likewise, it is important to protect the cloud deployment from being
|
||||
It is important to protect the cloud deployment from being
|
||||
configured or manipulated by malicious entities. With many systems in a
|
||||
cloud employing compute and networking virtualization, there are
|
||||
distinct challenges applicable to OpenStack which must be addressed
|
||||
through integrity lifecycle management.
|
||||
|
||||
Finally, administrators must perform command and control over the cloud
|
||||
Administrators must perform command and control over the cloud
|
||||
for various operational functions. It is important these command and
|
||||
control facilities are understood and secured.
|
||||
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@ decentralized pool of queue servers. ZeroMQ provides direct peer-to-peer
|
|||
communication through TCP sockets.
|
||||
|
||||
Message queues effectively facilitate command and control functions
|
||||
across OpenStack deployments. Once access to the queue is permitted no
|
||||
across OpenStack deployments. Once access to the queue is permitted, no
|
||||
further authorization checks are performed. Services accessible through
|
||||
the queue do validate the contexts and tokens within the actual message
|
||||
payload. However, you must note the expiration date of the token because
|
||||
|
|
|
|||
|
|
@ -4,16 +4,15 @@
|
|||
Monitoring and logging
|
||||
======================
|
||||
|
||||
A lot of activity goes on within a cloud environment. It is a mix of hardware,
|
||||
operating systems, virtual machine managers, the OpenStack services, cloud-user
|
||||
activity such as creating instances and attaching storage, the network
|
||||
underlying the whole, and finally end-users using the applications running on
|
||||
the various instances.
|
||||
Within a cloud environment there is a mixture of hardware,
|
||||
operating systems, virtual machine managers, OpenStack services, cloud-user
|
||||
activity (such as creating instances and attaching storage), networking,
|
||||
and end-users using the applications running on the various instances.
|
||||
|
||||
The basics of logging: configuration, setting log level, location of the log
|
||||
files, and how to use and customize logs, as well as how to do centralized
|
||||
collections of logs is well covered in the `OpenStack Operations Guide
|
||||
<https://docs.openstack.org/ops/>`__.
|
||||
<https://docs.openstack.org/ops/>`_.
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
|
|
|||
|
|
@ -2,13 +2,14 @@
|
|||
Networking
|
||||
==========
|
||||
|
||||
OpenStack Networking enables the end-user or tenant to define, utilize, and
|
||||
consume networking resources. OpenStack Networking provides a tenant-facing API
|
||||
for defining network connectivity and IP addressing for instances in the cloud
|
||||
in addition to orchestrating the network configuration. With the transition to
|
||||
an API-centric networking service, cloud architects and administrators should
|
||||
take into consideration best practices to secure physical and virtual network
|
||||
infrastructure and services.
|
||||
The OpenStack Networking service (neutron) enables the end-user or tenant to
|
||||
define, utilize, and consume networking resources. OpenStack Networking
|
||||
provides a tenant-facing API for defining network connectivity and IP
|
||||
addressing for instances in the cloud, in addition to orchestrating the
|
||||
network configuration. With the transition to an API-centric networking
|
||||
service, cloud architects and administrators should take into consideration
|
||||
best practices to secure physical and virtual network infrastructure and
|
||||
services.
|
||||
|
||||
OpenStack Networking was designed with a plug-in architecture that provides
|
||||
extensibility of the API through open source community or third-party services.
|
||||
|
|
@ -19,9 +20,7 @@ supplemental services are required to be implemented in the physical
|
|||
infrastructure.
|
||||
|
||||
This section is a high-level overview of what processes and best practices
|
||||
should be considered when implementing OpenStack Networking. We will talk about
|
||||
the current state of services that are available, what future services will be
|
||||
implemented, and the current limitations in this project.
|
||||
should be considered when implementing OpenStack Networking.
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
|
|
|||
|
|
@ -2,25 +2,25 @@
|
|||
Object Storage
|
||||
==============
|
||||
|
||||
OpenStack Object Storage (swift) is a service that provides software that
|
||||
OpenStack Object Storage (swift) service provides software that
|
||||
stores and retrieves data over HTTP. Objects (blobs of data) are stored in an
|
||||
organizational hierarchy that offers anonymous read-only access, ACL defined
|
||||
access, or even temporary access. Object Store supports multiple token-based
|
||||
access, or even temporary access. Object Storage supports multiple token-based
|
||||
authentication mechanisms implemented via middleware.
|
||||
|
||||
Applications store and retrieve data in Object Store via an industry-standard
|
||||
HTTP RESTful API. Back-end components of Object Storage follow the same RESTful
|
||||
model however some of the APIs for managing durability, for example, are kept
|
||||
private to the cluster. For more details on the API see the `OpenStack Storage
|
||||
documentation
|
||||
<https://docs.openstack.org/api/openstack-object-storage/1.0/content/>`__.
|
||||
Applications store and retrieve data in Object Storage via an
|
||||
industry-standard HTTP RESTful API. Back end components of Object Storage
|
||||
follow the same RESTful model, although some APIs, such as those managing
|
||||
durability, are kept private to the cluster.
|
||||
For more details on the API see the
|
||||
`OpenStack Storage documentation
|
||||
<https://docs.openstack.org/api/openstack-object-storage/1.0/content/>`_.
|
||||
|
||||
For this document the components will be grouped into the following primary
|
||||
groups:
|
||||
The components of Object Storage are grouped into the following primary groups:
|
||||
|
||||
1. Proxy services
|
||||
2. Auth services
|
||||
3. Storage services
|
||||
#. Proxy services
|
||||
#. Auth services
|
||||
#. Storage services
|
||||
|
||||
- Account service
|
||||
- Container service
|
||||
|
|
@ -34,15 +34,15 @@ groups:
|
|||
|
||||
.. note::
|
||||
|
||||
An Object Storage installation does not have to necessarily be on the
|
||||
Internet and could also be a private cloud with the "Public Switch" being
|
||||
part of the organization's internal network infrastructure.
|
||||
An Object Storage installation does not have to be on the
|
||||
Internet and could also be a private cloud with the public switch a
|
||||
part of the organization's internal network infrastructure.
|
||||
|
||||
First thing to secure: the network
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
Network security
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
Securing the Object Storage service begins with securing the networking
|
||||
component. If you skipped the networking chapter, go back to :doc:`networking`.
|
||||
component. If you skipped the networking chapter, return to :doc:`networking`.
|
||||
|
||||
The rsync protocol is used between storage service nodes to replicate data for
|
||||
high availability. In addition, the proxy service communicates with the storage
|
||||
|
|
@ -52,21 +52,21 @@ cloud environment.
|
|||
.. caution::
|
||||
|
||||
Object Storage does not employ encryption or authentication with inter-node
|
||||
communications. This is why you see a "Private Switch" or private network
|
||||
communications. This is why you see a private switch or private network
|
||||
([V]LAN) in the architecture diagrams. This data domain should be separate
|
||||
from other OpenStack data networks as well. For further discussion on
|
||||
security domains please see :doc:`introduction/security-boundaries-and-threats`.
|
||||
|
||||
.. tip::
|
||||
|
||||
*Rule:* Use a private (V)LAN network segment for your storage nodes in the
|
||||
Use a private (V)LAN network segment for your storage nodes in the
|
||||
data domain.
|
||||
|
||||
This necessitates that the proxy nodes have dual interfaces (physical or
|
||||
virtual):
|
||||
|
||||
1. One as a "public" interface for consumers to reach
|
||||
2. Another as a "private" interface with access to the storage nodes
|
||||
#. One as a public interface for consumers to reach.
|
||||
#. Another as a private interface with access to the storage nodes.
|
||||
|
||||
The following figure demonstrates one possible network architecture.
|
||||
|
||||
|
|
@ -75,20 +75,24 @@ The following figure demonstrates one possible network architecture.
|
|||
|
||||
Object Storage network architecture with a management node (OSAM)
|
||||
|
||||
Securing services: general
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
General service security
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Run services as non-root user
|
||||
-----------------------------
|
||||
|
||||
It is recommended that you configure each Object Storage service to run under a
|
||||
non-root (UID 0) service account. One recommendation is the user name "swift"
|
||||
with the primary group "swift." Object Storage services include, for example,
|
||||
'proxy-server', 'container-server', 'account-server'. Detailed steps for setup
|
||||
and configuration can be found in the `Add Object Storage chapter
|
||||
<https://docs.openstack.org/project-install-guide/object-storage/ocata/>`__
|
||||
We recommend that you configure the Object Storage service to run under a
|
||||
non-root (UID 0) service account. One recommendation is the user name ``swift``
|
||||
with the primary group ``swift``. Object Storage services include, for example,
|
||||
``proxy-server``, ``container-server``, ``account-server``. Detailed steps
|
||||
for setup and configuration can be found in the `Add Object Storage chapter
|
||||
<https://docs.openstack.org/project-install-guide/object-storage/ocata/>`_
|
||||
of the Installation Guide in the `OpenStack Documentation index
|
||||
<https://docs.openstack.org>`__. (The link defaults to the Ubuntu version.)
|
||||
<https://docs.openstack.org>`_.
|
||||
|
||||
.. note::
|
||||
|
||||
The above link defaults to the Ubuntu version.
|
||||
|
||||
File permissions
|
||||
----------------
|
||||
|
|
@ -104,7 +108,7 @@ and environment configuration. The following permissions are recommended:
|
|||
|
||||
This restricts only root to be able to modify configuration files while
|
||||
allowing the services to read them through their group membership in the
|
||||
'swift' group.
|
||||
``swift`` group.
|
||||
|
||||
Securing storage services
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
|
@ -132,20 +136,21 @@ The following are the default listening ports for the various storage services:
|
|||
- TCP
|
||||
|
||||
.. [1]
|
||||
If ssync is used instead of rsync, the Object service port is used for
|
||||
If ssync is used instead of rsync, the object service port is used for
|
||||
maintaining durability.
|
||||
|
||||
.. important::
|
||||
|
||||
Authentication does not take place at the storage nodes. If someone was able to
|
||||
connect to a storage node on one of these ports they could access or modify
|
||||
data without authentication. In order to secure against this issue you should
|
||||
follow the recommendations given previously about using a private storage
|
||||
network.
|
||||
Authentication does not take place at the storage nodes. If you are able to
|
||||
connect to a storage node on one of these ports, you can access or modify
|
||||
data without authentication. In order to secure against this issue you should
|
||||
follow the recommendations given previously about using a private storage
|
||||
network.
|
||||
|
||||
Object Storage "account" terminology
|
||||
------------------------------------
|
||||
Object Storage account terminology
|
||||
----------------------------------
|
||||
|
||||
An Object Storage "account" is not a user account or credential. The following
|
||||
An Object Storage account is not a user account or credential. The following
|
||||
explains the relations:
|
||||
|
||||
.. list-table::
|
||||
|
|
@ -164,17 +169,10 @@ explains the relations:
|
|||
- The actual data objects. ACLs at the object level are also possible
|
||||
with metadata and are dependent on the authentication system used.
|
||||
|
||||
.. tip::
|
||||
|
||||
Another way of thinking about the above would be: A single shelf (account)
|
||||
holds zero or more buckets (containers) which each hold zero or more
|
||||
objects. A garage (Object Storage cluster) may have multiple shelves
|
||||
(accounts) with each shelf belonging to zero or more users.
|
||||
|
||||
At each level you may have ACLs that dictate who has what type of access. ACLs
|
||||
At each level, you have ACLs that dictate who has what type of access. ACLs
|
||||
are interpreted based on what authentication system is in use. The two most
|
||||
common types of authentication providers used are Identity service (keystone)
|
||||
and TempAuth. Custom authentication providers are also possible. Please see
|
||||
and TempAuth. Custom authentication providers are also possible. See
|
||||
:ref:`object_storage_authentication` for more information.
|
||||
|
||||
Securing proxy services
|
||||
|
|
@ -184,7 +182,7 @@ A proxy node should have at least two interfaces (physical or virtual): one
|
|||
public and one private. Firewalls or service binding might protect the public
|
||||
interface. The public facing service is an HTTP web server that processes
|
||||
end-point client requests, authenticates them, and performs the appropriate
|
||||
action. The private interface does not require any listening services but is
|
||||
action. The private interface does not require any listening services, but is
|
||||
instead used to establish outgoing connections to storage nodes on the private
|
||||
storage network.
|
||||
|
||||
|
|
@ -192,34 +190,33 @@ HTTP listening port
|
|||
-------------------
|
||||
|
||||
You should configure your web service as a non-root (no UID 0) user such as
|
||||
"swift" mentioned before. The use of a port greater than 1024 is required to
|
||||
make this easy and avoid running any part of the web container as root. Doing
|
||||
so is not a burden as end-point clients are not typically going to type in the
|
||||
URL manually into a web browser to browse around in the object storage.
|
||||
Additionally, for clients using the HTTP REST API and performing authentication
|
||||
they will normally automatically grab the full REST API URL they are to use as
|
||||
provided by the authentication response. OpenStack's REST API allows for a
|
||||
client to authenticate to one URL and then be told to use a completely
|
||||
different URL for the actual service. Example: Client authenticates to
|
||||
https://identity.cloud.example.org:55443/v1/auth and gets a response with their
|
||||
authentication key and Storage URL (the URL of the proxy nodes or load
|
||||
``swift`` mentioned before. The use of a port greater than 1024 is required to
|
||||
make this easy and avoid running any part of the web container as root.
|
||||
Normally, clients using the HTTP REST API and performing authentication
|
||||
automatically retrieve the full REST API URL they require from the
|
||||
authentication response. OpenStack's
|
||||
REST API allows for a client to authenticate to one URL and then be told to
|
||||
use a completely different URL for the actual service. For example, a Client
|
||||
authenticates to
|
||||
https://identity.cloud.example.org:55443/v1/auth and gets a response with
|
||||
their authentication key and Storage URL (the URL of the proxy nodes or load
|
||||
balancer) of https://swift.cloud.example.org:44443/v1/AUTH_8980.
|
||||
|
||||
The method for configuring your web server to start and run as a non-root user
|
||||
varies by web server and OS.
|
||||
varies by web server and operating system.
|
||||
|
||||
Load balancer
|
||||
-------------
|
||||
|
||||
If the option of using Apache is not feasible or for performance you wish to
|
||||
offload your TLS work you may employ a dedicated network device load balancer.
|
||||
This is also the common way to provide redundancy and load balancing when using
|
||||
If the option of using Apache is not feasible, or for performance you wish to
|
||||
offload your TLS work, you may employ a dedicated network device load balancer.
|
||||
This is a common way to provide redundancy and load balancing when using
|
||||
multiple proxy nodes.
|
||||
|
||||
If you choose to offload your TLS, ensure that the network link between the
|
||||
load balancer and your proxy nodes are on a private (V)LAN segment such that
|
||||
other nodes on the network (possibly compromised) cannot wiretap (sniff) the
|
||||
unencrypted traffic. If such a breach were to occur the attacker could gain
|
||||
unencrypted traffic. If such a breach were to occur, the attacker could gain
|
||||
access to end-point client or cloud administrator credentials and access the
|
||||
cloud data.
|
||||
|
||||
|
|
@ -234,9 +231,9 @@ Object Storage authentication
|
|||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Object Storage uses a WSGI model to provide for a middleware capability that
|
||||
not only provides general extensibility but is also used for authentication of
|
||||
not only provides general extensibility, but is also used for authentication of
|
||||
end-point clients. The authentication provider defines what roles and user
|
||||
types exist. Some use traditional user name and password credentials while
|
||||
types exist. Some use traditional user name and password credentials, while
|
||||
others may leverage API key tokens or even client-side x.509 certificates.
|
||||
Custom providers can be integrated in using custom middleware.
|
||||
|
||||
|
|
@ -248,9 +245,9 @@ TempAuth
|
|||
--------
|
||||
|
||||
TempAuth is the default authentication for Object Storage. In contrast to
|
||||
Identity it stores the user accounts, credentials, and metadata in object
|
||||
Identity, it stores the user accounts, credentials, and metadata in object
|
||||
storage itself. More information can be found in the section `The Auth System
|
||||
<https://docs.openstack.org/developer/swift/overview_auth.html>`__ of the Object
|
||||
<https://docs.openstack.org/developer/swift/overview_auth.html>`_ of the Object
|
||||
Storage (swift) documentation.
|
||||
|
||||
Keystone
|
||||
|
|
@ -263,7 +260,7 @@ already provided in :doc:`identity`.
|
|||
Other notable items
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
In ``/etc/swift`` on every node there is a ``swift_hash_path_prefix``
|
||||
In ``/etc/swift``, on every node, there is a ``swift_hash_path_prefix``
|
||||
setting and a ``swift_hash_path_suffix`` setting. These are provided to reduce
|
||||
the chance of hash collisions for objects being stored and avert one user
|
||||
overwriting the data of another user.
|
||||
|
|
|
|||
|
|
@ -2,8 +2,8 @@
|
|||
Secure communication
|
||||
====================
|
||||
|
||||
Inter-device communication is an issue still plaguing security
|
||||
researchers. Between large project errors such as Heartbleed or more
|
||||
Inter-device communication is a serious security concern.
|
||||
Between large project errors, such as Heartbleed, or more
|
||||
advanced attacks such as BEAST and CRIME, secure methods of
|
||||
communication over a network are becoming more important. It should
|
||||
be remembered, however that encryption should be applied as one part
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
===============
|
||||
Security Review
|
||||
Security review
|
||||
===============
|
||||
|
||||
The goal of security review in the OpenStack community is to identify
|
||||
|
|
@ -23,7 +23,7 @@ A common reason to perform a security review on an OpenStack project is to
|
|||
enable that project to achieve the *vulnerability:managed* governance tag. The
|
||||
OpenStack Vulnerability Management Team (VMT) applies the
|
||||
`vulnerability:managed tag
|
||||
<https://governance.openstack.org/reference/tags/vulnerability_managed.html>`__
|
||||
<https://governance.openstack.org/reference/tags/vulnerability_managed.html>`_
|
||||
to projects where the report reception and disclosure of vulnerabilities is
|
||||
managed by the VMT. One of the requirements for gaining the tag is that
|
||||
some form of security review, audit or threat analysis has been performed on
|
||||
|
|
@ -34,7 +34,7 @@ architectural review of the best practice deployment for a project is an
|
|||
appropriate form of security review, balancing the need for review with the
|
||||
resource requirements for a project of the scale of OpenStack. Security
|
||||
architecture review is also often referred to as *threat analysis*, *security
|
||||
analysis* or *threat modeling*, in the context of OpenStack security review
|
||||
analysis* or *threat modeling*. In the context of OpenStack security review,
|
||||
these terms are synonymous for an architectural security review which may
|
||||
identify defects in the design of a project or reference architecture, and may
|
||||
lead to further investigative work to verify parts of the implementation.
|
||||
|
|
|
|||
|
|
@ -4,10 +4,10 @@ Shared File Systems
|
|||
|
||||
The Shared File Systems service (manila) provides a set of services for
|
||||
management of shared file systems in a multi-tenant cloud environment. It is
|
||||
done similar to how OpenStack provides block-based storage management through
|
||||
the OpenStack Block Storage service project. With the Shared File Systems
|
||||
service, you can create a shared file system and manage its properties such as
|
||||
visibility, accessibility and usage quotas.
|
||||
similar to how OpenStack provides block-based storage management through
|
||||
the OpenStack Block Storage service (cinder) project. With the Shared File
|
||||
Systems service, you can create a shared file system and manage its
|
||||
properties, such as visibility, accessibility and usage quotas.
|
||||
|
||||
The Shared File Systems service works with various storage providers that use
|
||||
the following shared file system protocols:
|
||||
|
|
|
|||
|
|
@ -3,9 +3,9 @@ Tenant data privacy
|
|||
===================
|
||||
|
||||
OpenStack is designed to support multitenancy and those tenants will
|
||||
most probably have different data requirements. As a cloud builder and
|
||||
operator you need to ensure your OpenStack environment can address
|
||||
various data privacy concerns and regulations. In this chapter we will
|
||||
most probably have different data requirements. As a cloud builder or operator,
|
||||
you must ensure your OpenStack environment addresses data privacy concerns
|
||||
and regulations. In this chapter we will
|
||||
address data residency and disposal as it pertains to OpenStack
|
||||
implementations.
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue