openstack
/
security-doc
Code Issues Proposed changes

Added a Security Guide for the Shared File Systems service 

Added a security guide for Shared File Systems service.

Change-Id: I99eee1ac641a31bf39d2f9fd8669e2002d146697
Closes-Bug: #1503334
This commit is contained in:
Jane Zadorozhna 2015-10-06 18:13:33 +03:00 committed by Ievgeniia Zadorozhna
parent 400393b368
commit 4c956b3e75
11 changed files with 1122 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

BIN
security-guide/source/figures/manila-intro.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 76 KiB

1
security-guide/source/index.rst
View File

@ -26,6 +26,7 @@ Contents
dashboard.rst
compute.rst
block-storage.rst
shared-file-systems.rst
networking.rst
object-storage.rst
messaging.rst

10
security-guide/source/introduction/introduction-to-openstack.rst
View File

@ -151,6 +151,16 @@ instances, to their release.
Security considerations for block storage are similar to that of object
storage.
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, similar
to how OpenStack provides for block-based storage management through the
OpenStack Block Storage service project. With the Shared File Systems service,
you can create a remote file system, mount the file system on your instances,
and then read and write data from your instances to and from your file system.
Networking
----------

29
security-guide/source/shared-file-systems.rst Normal file
View File

@ -0,0 +1,29 @@
===================
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, similar
to how OpenStack provides for block-based storage management through the
OpenStack Block Storage service project. With the Shared File Systems service,
you can create a remote file system, mount the file system on your instances,
and then read and write data from your instances to and from your file system.
A large amount of existing software is designed around file-based storage. The
Shared File Systems service provides the management of file shares and works
with various storage providers that use following shared file system protocols:
NFS, CIFS, GlusterFS, and HDFS.
The Shared File Systems serves the same purpose as the Amazon Elastic File
System (EFS) offering does.
.. toctree::
:maxdepth: 2
shared-file-systems/intro.rst
shared-file-systems/network-and-security-models.rst
shared-file-systems/security-services.rst
shared-file-systems/share-acl.rst
shared-file-systems/share-type-acl.rst
shared-file-systems/policies.rst
shared-file-systems/checklist.rst

185
security-guide/source/shared-file-systems/checklist.rst Normal file
View File

@ -0,0 +1,185 @@
.. _shared_fs_checklist:
=========
Checklist
=========
.. _check_shared_fs_01:
Check-Shared-01: Is user/group ownership of config files set to root/manila?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Configuration files contain critical parameters and information required
for smooth functioning of the component. If an unprivileged user, either
intentionally or accidentally, modifies or deletes any of the parameters or
the file itself then it would cause severe availability issues resulting in a
denial of service to the other end users. Thus user ownership of such critical
configuration files must be set to root and group ownership must be set to
manila.
Run the following commands:
.. code:: console
$ stat -L -c "%U %G" /etc/manila/manila.conf | egrep "root manila"
$ stat -L -c "%U %G" /etc/manila/api-paste.ini | egrep "root manila"
$ stat -L -c "%U %G" /etc/manila/policy.json | egrep "root manila"
$ stat -L -c "%U %G" /etc/manila/rootwrap.conf | egrep "root manila"
**Pass:** If user and group ownership of all these config files is set
to root and manila respectively. The above commands show output of root manila.
**Fail:** If the above commands does not return any output as the user
and group ownership might have set to any user other than root or any group
other than manila.
.. _check_shared_fs_02:
Check-Shared-02: Are strict permissions set for configuration files?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Similar to the previous check, it is recommended to set strict access
permissions for such configuration files.
Run the following commands:
.. code:: console
$ stat -L -c "%a" /etc/manila/manila.conf
$ stat -L -c "%a" /etc/manila/api-paste.ini
$ stat -L -c "%a" /etc/manila/policy.json
$ stat -L -c "%a" /etc/manila/rootwrap.conf
**Pass:** If permissions are set to 640 or stricter. The permissions of 640
translates into owner r/w, group r, and no rights to others i.e. "u=rw,g=r,o=".
Note that with :ref:`check_shared_fs_01` and permissions set to 640, root has
read/write access and manila has read access to these configuration files. The
access rights can also be validated using the following command. This command
will only be available on your system if it supports ACLs.
.. code:: console
$ getfacl --tabular -a /etc/manila/manila.conf
getfacl: Removing leading '/' from absolute path names
# file: etc/manila/manila.conf
USER root rw-
GROUP manila r--
mask r--
other ---
**Fail:** If permissions are not set to at least 640.
.. _check_shared_fs_03:
Check-Shared-03: Is OpenStack Identity used for authentication?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
OpenStack supports various authentication strategies like noauth and keystone.
If the '``noauth``' strategy is used then the users could interact with
OpenStack services without any authentication. This could be a potential risk
since an attacker might gain unauthorized access to the OpenStack components.
Thus it is strongly recommended that all services must be authenticated with
keystone using their service accounts.
**Pass:** If value of parameter ``auth_strategy`` under ``[DEFAULT]`` section
in :file:`manila.conf` is set to ``keystone``.
**Fail:** If value of parameter ``auth_strategy`` under ``[DEFAULT]`` section
is set to ``noauth``.
.. _check_shared_fs_04:
Check-Shared-04: Is TLS enabled for authentication?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
OpenStack components communicate with each other using various protocols and
the communication might involve sensitive or confidential data. An attacker may
try to eavesdrop on the channel in order to get access to sensitive
information. Thus all the components must communicate with each other using a
secured communication protocol.
**Pass:** If value of parameter ``auth_protocol`` under
``[keystone_authtoken]`` section in :file:`manila.conf` is set to
``https``, or if value of parameter ``identity_uri`` under
``[keystone_authtoken]`` section in :file:`manila.conf` is set to
Identity API endpoint starting with ``https://`` and value of parameter
``insecure`` under the same ``[keystone_authtoken]`` section in the same
:file:`manila.conf` is set to ``False``.
**Fail:** If value of parameter ``auth_protocol`` under
``[keystone_authtoken]`` section in :file:`manila.conf` is set to
``http``, or if value of parameter ``identity_uri`` under
``[keystone_authtoken]`` section in :file:`manila.conf` is not set
to Identity API endpoint starting with ``https://`` or value of parameter
``insecure`` under the same ``[keystone_authtoken]`` section in the same
:file:`manila.conf` is set to ``True``.
.. _check_shared_fs_05:
Check-Shared-05: Does Shared File Systems contact with Compute over TLS?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
OpenStack components communicate with each other using various protocols and
the communication might involve sensitive or confidential data. An attacker may
try to eavesdrop on the channel in order to get access to sensitive
information. Thus all the components must communicate with each other using a
secured communication protocol.
**Pass:** If value of parameter ``nova_api_insecure`` under ``[DEFAULT]``
section in :file:`manila.conf` is set to ``False``.
**Fail:** If value of parameter ``nova_api_insecure`` under ``[DEFAULT]``
section in :file:`manila.conf` is set to ``True``.
.. _check_shared_fs_06:
Check-Shared-06: Does Shared File Systems contact with Networking over TLS?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Similar to previous check (:ref:`check_shared_fs_05`), it is recommended
all the components must communicate with each other using a secured
communication protocol.
**Pass:** If value of parameter ``neutron_api_insecure`` under ``[DEFAULT]``
section in :file:`manila.conf` is set to ``False``.
**Fail:** If value of parameter ``neutron_api_insecure`` under ``[DEFAULT]``
section in :file:`manila.conf` is set to ``True``.
.. _check_shared_fs_07:
Check-Shared-07: Does Shared File Systems contact with Block Storage over TLS?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Similar to previous check (:ref:`check_shared_fs_05`), it is recommended
all the components must communicate with each other using a secured
communication protocol.
**Pass:** If value of parameter ``cinder_api_insecure`` under ``[DEFAULT]``
section in :file:`manila.conf` is set to ``False``.
**Fail:** If value of parameter ``cinder_api_insecure`` under ``[DEFAULT]``
section in :file:`manila.conf` is set to ``True``.
.. _check_shared_fs_08:
Check-Shared-08: Is max size for the request body set to default (114688)?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If the maximum body size per request is not defined, the attacker can craft an
arbitrary OSAPI request of large size causing the service to crash and finally
resulting in Denial Of Service attack. Assigning the maximum value ensures that
any malicious oversized request gets blocked ensuring continued availability of
the service.
**Pass:** If value of parameter ``max_request_body_size`` under
``[oslo_middleware]`` section in :file:`manila.conf` is set to ``114688``, or
if value of parameter ``osapi_max_request_body_size`` under ``[DEFAULT]``
section in :file:`manila.conf` is set to ``114688``. The parameter
``osapi_max_request_body_size`` under ``[DEFAULT]`` is deprecated and it is
better to use [oslo_middleware]/``max_request_body_size``.
**Fail:** If value of parameter ``max_request_body_size`` under
``[oslo_middleware]`` section in :file:`manila.conf` is not set to ``114688``,
or if value of parameter ``osapi_max_request_body_size`` under ``[DEFAULT]``
section in :file:`manila.conf` is not set to ``114688``.

188
security-guide/source/shared-file-systems/intro.rst Normal file
View File

@ -0,0 +1,188 @@
.. _shared_fs_intro:
Introduction
------------
The Shared File Systems service (manila) is intended to be ran on a single-node
or across multiple nodes. The Shared File Systems service consists of three
main services, which are similar to those of the Block Storage service:
- ``manila-api``
- ``manila-scheduler``
- ``manila-share``
The Shared File Systems service uses a SQL-based central database that is
shared by all Shared File Systems services in the system. The amount and depth
of the data fits into a SQL database quite well. The Shared File Systems
service can use all SQL dialects supported by ORM SQLALchemy, but is tested
only with MySQL and PostgreSQL data bases.
Using SQL, the Shared File Systems service is similar to other OpenStack
services and can be used with any OpenStack deployment. For more details on
the API, see the `OpenStack Shared File Systems API <http://developer.
openstack.org/api-ref-share-v2.html>`_ description. For mode details of the CLI
using and configuring, see `Shared File Systems Cloud Administrative Guide
<http://docs.openstack.org/admin-guide-cloud/shared_file_systems.html>`_.
Below is an explanation of the different components.
.. image:: ../figures/manila-intro.png
``manila-api``
The service that provides a stable RESTful API. The service
authenticates and routes requests throughout the Shared Filesystem
service. There is python-manilaclient to interact with the API.
For more details on the Shared File Systems API, see the `OpenStack
Shared File Systems API <http://developer.openstack.org/api-ref-share-
v2.html>`_.
``manila-share``
Responsible for managing Shared File Service devices, specifically the
back-end devices.
``manila-scheduler``
Responsible for scheduling and routing requests to the appropriate
``manila-share`` service. It does that by picking one back-end while
filtering all except one back-end.
python-manilaclient
Command line interface to interact with the Shared File Systems service
via ``manila-api`` and also a Python module to interact programmatically
with the Shared File Systems service.
Storage controller
Typically a metal box with spinning disks, ethernet ports, and some
kind of software that allows network clients to read and write files on
the disks. There are also software-only storage controllers that run on
arbitrary hardware, clustered controllers which may run allow a
multiple physical devices to appear as a single storage controller, or
purely virtual storage controllers.
A share is a remote, mountable file system. You can mount a share to and access
a share from several hosts by several users at a time.
The Shared File Systems service can work with different network types, which
can be flat, VLAN, VXLAN, or GRE, and supports segmented networking. There are
also different :ref:`network plug-ins <shared_fs_network_plugins>` that provide
a variety of integration approaches with the network services that are
available with OpenStack.
There are a large number of share drivers created by different vendors. Each
share driver is a Python class that can be set for the back end and run in the
back end to manage the share operations, some of which are vendor-specific.
The back end is an instance of the manila-share service. For example, the
service can be configured to use NetApp Clustered Data ONTAP (cDOT), Huawei NAS
Driver, GlusterFS Native driver, and so on.
The configuration information for clients for authentication and authorization
can be stored by :ref:`security services <shared_fs_security_services>`.
This means that such protocols as LDAP and Kerberos, or with Microsoft Active
directory authentication service can be configured and used.
Unless it is not modified in the ``policy.json``, either an administrator or
the tenant that owns a share always is able to manage the :ref:`access to the
shares <shared_fs_share_acl>` by means of creating access rules with
authentication though IP address, user, group, or TLS certificates. The
authentication methods depend on which share driver and security service you
configure and use.
.. note::
Different access features are supported by different share drivers with
taking into consideration the shared file system protocol. The supported
shared file system protocols are NFS, CIFS, GlusterFS, or HDFS. As the
example, the Generic (Block Storage as a back end) driver does not support
user and certificate authentication methods. It also does not support any
of the security services, such as LDAP, Kerberos, or Active Directory. For
details of supporting of features by different drivers, see `Manila share
features support mapping <http://docs.openstack.org/developer/manila/
devref/share_back_ends_feature_support_mapping.html>`_.
As administrator, you can create the share types that enable the scheduler to
filter the back ends before you create a share. The share types have the extra
specifications you can set in the type for scheduler to filter and weigh back
ends so that an appropriate one is selected for the user that requests the
share creation. An administrator can add
:ref:`access to the private share types <shared_fs_share_types_acl>` for
definite users or tenants in the Identity service. Thus the users which you
granted access can see available share types and create shares using them.
The shares and share types can be created as public or private. This level of
visibility defines whether other tenants are able to see these objects and
operate with them, or not.
The permissions of API calls for different users and their roles are determined
by :ref:`policies <shared_fs_policies>` as well as other OpenStack services.
The Identity service with different back ends, for example, LDAP, Active
Directory, can be used for the authentication in the Shared File Systems. See
details of the identity service security in :doc:`../identity` section.
General security information
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Similar to other OpenStack projects, the Shared File Systems service is
registered with the Identity service, so you can find the API endpoints of the
share service v1 and v2 using **manila endpoints** command:
.. code:: console
+-------------+-----------------------------------------+
| manila | Value |
+-------------+-----------------------------------------+
| adminURL | http://172.18.198.55:8786/v1/20787a7b...|
| region | RegionOne |
| publicURL | http://172.18.198.55:8786/v1/20787a7b...|
| internalURL | http://172.18.198.55:8786/v1/20787a7b...|
| id | 82cc5535aa444632b64585f138cb9b61 |
+-------------+-----------------------------------------+
+-------------+-----------------------------------------+
| manilav2 | Value |
+-------------+-----------------------------------------+
| adminURL | http://172.18.198.55:8786/v2/20787a7b...|
| region | RegionOne |
| publicURL | http://172.18.198.55:8786/v2/20787a7b...|
| internalURL | http://172.18.198.55:8786/v2/20787a7b...|
| id | 2e8591bfcac4405fa7e5dc3fd61a2b85 |
+-------------+-----------------------------------------+
By default, the Shared File Systems API service listens only on the port
``8786`` with ``tcp6`` type that supports both IPv4 and IPv6.
.. note::
The port ``8786`` is the default port for the Shared File Systems service.
It may be changed to any other port, but this change should also be made
in the configuration file using option ``osapi_share_listen_port`` which
defaults to ``8786``.
In ``/etc/manila/`` directory you can find the environment configuration files:
.. code:: console
api-paste.ini
manila.conf
policy.json
rootwrap.conf
rootwrap.d
./rootwrap.d:
share.filters
It is recommended that you configure the Shared File Systems service to run
under a non-root service account, for example, ``manila`` and change file
permissions for only ``root`` to be able to modify the configuration files. The
Shared File Systems service expects that only the administrator can write to
the configuration files and the services can only read them through their group
membership in the ``manila`` group. Others must not be able to read these files
because the files contain admin passwords of different services.
Thus, for the configuration files it is recommended to set ownership to
``root/manila`` and access permissions to ``640`` allowing only root to write
to the configuration files, and other users in the ``manila`` group to read
them. For details, see :ref:`check_shared_fs_01` and :ref:`check_shared_fs_02`
in a checklist.
.. note::
The configuration for manila-rootwrap in file ``rootwrap.conf`` and the
manila-rootwrap command filters for share nodes in file
``rootwrap.d/share.filters`` should be owned by, and only-writeable by, the
root user.
.. tip::
Manila configuration file ``manila.conf`` may be used from different places.
The path ``/etc/manila/manila.conf`` is one of expected paths by default.

210
security-guide/source/shared-file-systems/network-and-security-models.rst Normal file
View File

@ -0,0 +1,210 @@
.. _shared_fs_network&security_models:
===========================
Network and security models
===========================
The share driver in the Shared File Systems service is a Python class that can
be set for the back end and run in it to manage the share operations, some of
which are vendor-specific. The back end is an instance of the manila-share
service. There are big number of the share drivers created by different vendors
in the Shared File Systems service. Each share driver supports one or more back
end modes: *share servers* and *no share servers*, but the administrator
chooses which mode is used by specifying it in the configuration file
:file:`manila.conf`.
The *share servers* mode can be configured with flat network, or with segmented
network. This depends on the network provider.
It is possible to have separate drivers for different modes on the same
hardware, if you want to have different configurations. Depending on which mode
is chosen, the administrator needs to provide additional details in the
configuration file as well.
.. _share-servers-vs-no-share-servers:
Share back ends modes
---------------------
Each share driver supports one or two of possible driver modes to configure the
back ends. Initially there are two driver modes for the back ends:
* **share servers mode**
* **no share servers mode**
The configuration option in the :file:`manila.conf` file that set the share
servers mode or no share servers mode is the ``driver_handles_share_servers``
option, that defines the driver mode for share storage life cycle management:
.. list-table::
:header-rows: 1
:widths: 20 40 60
* - Mode
- Config option
- Description
* - share servers
- driver_handles_share_servers = True
- The share driver creates the share server and manages, or handles, the
share server life cycle.
* - no share servers
- driver_handles_share_servers = False
- An administrator rather than a share driver manages the bare metal
storage with some net interface insteadof the presence of the share
servers.
This is the share types which have the extra specifications that help scheduler
to filter back ends and choose the appropriate back end for the user that
requested to create a share. For details of managing the share types and
configuration the back ends, see `Share types <http://docs.openstack.org/admin-
guide-cloud/shared_file_systems_share_types.html>`_ and `Multi-storage
configuration <http://docs.openstack.org/admin-guide-cloud/shared_file_systems_
multi_backend.html>`_ documentation.
No share servers mode
In this mode, drivers have basically no network requirements whatsoever.
It's assumed that the actual storage controller(s) being managed by the
driver has all of the network interfaces it's going to need. The Shared
File Systems service will expect the driver to provision shares directly
without creating any share server beforehand. This mode corresponds to
what some existing drivers are already doing, but it makes explicit the
choice for the administrator. In this mode, the share networks are not
needed at share creation time and must not be provided.
.. note::
In *no share servers mode* the Shared File Systems service will assume that
the network interfaces through which any shares are exported are already
reachable by all tenants.
In the *no share servers* mode the share driver does not handle the storage
life cycle. The administrator is expected to handle the storage, network
interfaces, and other host configurations. In this mode an administrator can
have the storage(s) as a host which exports the shares. The main characteristic
of this mode is that the storage is not handled by the Shared File Systems
service. The users in tenants share the common network(s), host, processor, and
network pipe. The users can hinder each other if there is no correct balancing
adjustment on the storage configured by admin or proxy before it. In the
public clouds it is possible that all the network pipe is used by one client,
so the administrator should handle this case not to happen. The balancing
adjustment can be configured by any means, not only OpenStack tools.
Share servers mode
In this mode, the driver is able to create share servers and join them to
an existing network. When providing a new share server, the drivers expect
an IP address and subnet from the Shared File Systems service.
Unlike the no share servers mode, in the *share servers* mode the users have
the share network and the share server that is created for each share network.
Thus all users have separate CPU, amount of CPU time, network, capacity and
throughput.
You also can configure the
:ref:`security services <shared_fs_security_services>` in both *share servers*
and *no share servers* back-end modes. But with *no share servers* back-end
mode, an administrator should set the desired authentication services manually
on the host. And in the *share servers* mode of the back end The Shared File
Systems service can be configured automatically with any of existing security
services supported by the share driver.
Flat vs segmented networking
----------------------------
The Shared File Systems service allows to work with different types of a
network:
* ``flat``
* ``GRE``
* ``VLAN``
* ``VXLAN``
.. note::
The Shared File Systems service is just keeping the information about the
networks in the database, and the real networks are available due to the
network provider. In OpenStack it can be Legacy networking (nova-network)
or Networking (neutron) services, but actually the Shared File Systems
service can work even out of OpenStack. That is due to the
``StandaloneNetworkPlugin`` that can be used with any network platform and
does not require some specific network services in OpenStack like
Networking or Legacy networking services. You can set the network
parameters in its configuration file.
In the :ref:`share servers <share-servers-vs-no-share-servers>` back-end mode
the share driver creates and manages the share server for each share network.
This mode can be divided on two variations:
* Flat network in *share servers* back-end mode
* Segmented network in *share servers* back-end mode
Initially, while creating the share network, you can set up either a network
and subnet of the OpenStack Networking (neutron) or a network of Legacy
networking (nova-network) services. The third approach is to configure the
networking without Legacy networking and Networking services. The
``StandaloneNetworkPlugin`` can be used with any network platform. You can set
the network parameters in its configuration file.
.. tip::
All the share drivers that use the OpenStack Compute service do not use the
network plug-ins. In Liberty release it is Windows and Generic drivers, so
these share drives have other options and use different approach.
After the share network is created, the Shared File Systems service retrieves
the network information determined by the network provider, for example, the
network type, the segmentation identifier if the network uses segmentation, the
IP block in Classless Inter-Domain Routing (CIDR) notation from which to
allocate the network.
Below you can see the comparison of the flat network with segmented
network in *share servers* back-end mode.
**Flat network in share servers back-end mode**
In this mode, some storage controllers can create share servers but due to
various limitations of the physical or logical network all of the share servers
have to be on a flat network. In this mode, the share driver needs something to
provision IP addresses for the share servers, but the IPs all come out of the
same subnet and that subnet itself is assumed to be reachable by all tenants.
In this mode, the :ref:`security service part <shared_fs_security_services>` of
the share networks is important because it allows tenants to specify security
requirements such as AD or LDAP domains or a Kerberos realm. The Shared File
Systems service assumes that any hosts referred to in the security service are
reachable from the subnet where the share server is created, which limits the
situations where this mode makes sense.
**Segmented network in share servers back-end mode**
In this mode, the share driver is able to create share servers and join them to
an existing segmented network. The share drivers expect the Shared File systems
to provide for every new share server a subnet definition including a
segmentation type which is VLAN, VXLAN, or GRE, segmentation ID, and any other
info relevant to the segmentation type.
The security aspects of the configured networks depends on the configuration
itself and the network provider.
.. note::
The share drivers may not support every type of segmentation, for details
see the specification for each driver.
.. _shared_fs_network_plugins:
Network plug-ins
----------------
The Shared File Systems service architecture defines an abstraction layer for
network resource provisioning and allowing administrators to choose from a
different options for how network resources are assigned to their tenants’
networked storage. There are a set of network plug-ins that provide a variety
of integration approaches with the network services that are available with
OpenStack.
The network plug-ins allow to use any functions, configurations of the
OpenStack Networking and Legacy networking services, for example, you can use
any network segmentation that the Networking service supports, you can use
flat networks or VLAN-segmented networks of the Legacy networking
(nova-network) service, or you can use the plug-in for specifying networks
independently from OpenStack networking services. For more information of how
to use different network plug-ins, see `Shared File Systems service Network
plug-ins <http://docs.openstack.org/admin-guide-cloud/shared_file_systems_
network_plugins.html#network-plug-ins>`_. The security in using different
network plug-ins depends on the specific network configuration.

79
security-guide/source/shared-file-systems/policies.rst Normal file
View File

@ -0,0 +1,79 @@
.. _shared_fs_policies:
========
Policies
========
Shared File Systems service has its own role-based access policies. They
determine which user can access which objects in which way, and are defined in
the service's :file:`policy.json` file.
.. tip::
The configuration file ``policy.json`` may be used from different places.
The path ``/etc/manila/policy.json`` is one of expected paths by default.
Whenever an API call to the Shared File Systems service is made, the policy
engine uses the appropriate policy definitions to determine if the call can be
accepted.
The policy rule determines under which circumstances the API call is permitted.
The :file:`/etc/manila/policy.json` file has rules where action is always
permitted, when the rule is an empty string: ``""``; the rules based on the
user role or rules; rules with boolean expressions. Below is a snippet of the
:file:`policy.json` file for the Shared File Systems service. From one
OpenStack release to another it can be changed.
.. code-block:: javascript
{
"context_is_admin": "role:admin",
"admin_or_owner": "is_admin:True or project_id:%(project_id)s",
"default": "rule:admin_or_owner",
"admin_api": "is_admin:True",
"share:create": "",
"share:delete": "rule:default",
"share:get": "rule:default",
"share:get_all": "rule:default",
"share:list_by_share_server_id": "rule:admin_api",
"share:update": "rule:default",
"share:snapshot_update": "rule:default",
"share:create_snapshot": "rule:default",
"share:delete_snapshot": "rule:default",
"share:get_snapshot": "rule:default",
"share:get_all_snapshots": "rule:default",
"share:access_get": "rule:default",
"share:access_get_all": "rule:default",
"share:allow_access": "rule:default",
"share:deny_access": "rule:default",
"share:extend": "rule:default",
"share:shrink": "rule:default",
"share:get_share_metadata": "rule:default",
"share:delete_share_metadata": "rule:default",
"share:update_share_metadata": "rule:default",
"share:migrate": "rule:admin_api",
"share_type:index": "rule:default",
"share_type:show": "rule:default",
"share_type:default": "rule:default",
"share_instance:index": "rule:admin_api",
"share_instance:show": "rule:admin_api",
"share_extension:quotas:show": "",
"share_extension:quotas:update": "rule:admin_api",
"share_extension:quotas:delete": "rule:admin_api",
"share_extension:quota_classes": "",
...
}
Note that your users must be assigned to groups and roles that you refer to in
your policies.
.. note::
Any changes to :file:`/etc/manila/policy.json` are effective immediately,
which allows new policies to be implemented while the Shared File Systems
service is running. Modifying the policy can have unexpected side effects
and is not encouraged. For details, see `The policy.json file <http://docs.
openstack.org/trunk/config-reference/content/policy-json-file.html>`_.

142
security-guide/source/shared-file-systems/security-services.rst Normal file
View File

@ -0,0 +1,142 @@
.. _shared_fs_security_services:
=================
Security services
=================
For authentication and authorization of the clients, the Shared File Systems
Storage service can optionally be configured with different network
authentication protocols. Supported authentication protocols are LDAP,
Kerberos, or Microsoft Active directory authentication service.
Introduction to security services
---------------------------------
After creating the share and getting its export location users have no
permissions to mount it and operate with files. The Shared File System service
allows to grant or deny access to the shares.
The configuration information for clients for authentication and authorization
(AuthN/AuthZ) can be stored by ``security services``. This means that such
protocols as LDAP and Kerberos, or with Microsoft Active directory
authentication service can be used by the Shared File Systems service if they
exist and are supported by the drivers and back ends. These authentication
services also can be configured without the Shared File Systems service.
.. note::
In some cases, it is required to add one of the security services. For
example, NetApp, EMC and Windows drivers require Active Directory for the
creation of shares with CIFS protocol.
Security services management
----------------------------
A *security service* is the Shared File Systems service (manila) term that
means a set of options that defines a security domain for a particular shared
file system protocol, such as an Active Directory domain or a Kerberos domain.
The security service contains all of the information necessary for the Shared
File Systems to create a server that joins the given domain.
Using the API users can create, update, view, delete a security service.
The security services are realized in the Shared File Systems API with such
key concepts:
* Tenants provide the details for the security service.
* Administrators care about security services: they configure the server side
of such security services.
* Inside The Shared File Systems API, a ``security_service`` is associated with
the ``share_networks``.
* The share drivers use the information in the security service to configure
newly created share servers.
While creating a security service, you can select one of these authentication
services:
.. list-table::
:header-rows: 1
:widths: 20 70
* - Authentication service
- Description
* - LDAP
- The Lightweight Directory Access Protocol. An application protocol for
accessing and maintaining distributed directory information services
over an IP network.
* - Kerberos
- The network authentication protocol which works on the basis of tickets
to allow nodes communicating over a non-secure network to prove their
identity to one another in a secure manner.
* - Active Directory
- A directory service that Microsoft developed for Windows domain
networks. Uses LDAP, Microsoft's version of Kerberos, and DNS.
The Shared File Systems allows you to configure a security service with these
options:
* A DNS IP address that is used inside the tenant network.
* An IP address or host name of a security service.
* A domain of a security service.
* A user or group name that is used by the tenant.
* The password for the user, if you specify a user name.
An existing security service entity can be associated with the share network
entities that inform the Shared File Systems service about the security and
network configuration for a group of shares. You can also see the list of all
security services for a specified share network and disassociate them from
a share network.
For details of managing the security services via API, see the `Security
services API <http://developer.openstack.org/api-ref-share-v2.html#share-security-
services>`_. You also can manage the security services via python-manilaclient,
see `Security services CLI managing <http://docs.openstack.org/admin-guide-
cloud/shared_file_systems_security_services.html>`_.
An administrator and the users as share owners can manage the
:ref:`access to the shares <shared_fs_share_acl>` by means of creating access
rules with authentication though ip address, user or group, or TLS
certificates. The authentication methods depend on which share driver and
security service you configure and use.
Thus as an administrator you can configure the backend to use the definite
authentication service via network and it will store the users. The
authentication service can operate with clients without the Shared File System
and the Identity service.
.. note::
Different authentication services are supported by different share drivers.
For details of supporting of features by different drivers, see
`Manila share features support mapping <http://docs.openstack.org/developer
/manila/devref/share_back_ends_feature_support_mapping.html>`_.
The support of definite authentication service by the driver also doesn't
mean that it can be configured with any shared file system protocol.
Supported shared file systems protocols are NFS, CIFS, GlusterFS, and HDFS.
See the driver vendor's documentation for the specific driver and its
configuration for the security services.
Some drivers support the security services and other drivers do not support any
of the hereinabove security services.
The Generic Driver with NFS or CIFS shared file system protocol supports only
authentication method through the IP address.
.. tip::
* Those drivers that support CIFS shared file system protocol in most
cases can be configured to use Active Directory and manage access through
user authentication.
* Drivers that support GlusterFS protocol can be used with authentication
via TLS certificates.
* With drivers that support NFS protocol the authentication via IP address
is the only supported.
* Since the HDFS shared file system protocol uses NFS access it also can be
configured to authenticate via IP address.
The authentication via IP is the most weak.
The recommended configuration for the Shared File Systems service real usage
is to create a share with CIFS share protocol and add to it the Microsoft
Active Directory directory service. In this configuration you'll get the
centralized data base and the service that unites Kerberos and LDAP approaches.
This is a real use case that is convenient for the real production shared file
systems.

157
security-guide/source/shared-file-systems/share-acl.rst Normal file
View File

@ -0,0 +1,157 @@
.. _shared_fs_share_acl:
====================
Share access control
====================
The Shared File Systems service allows to grant or deny access to different
entities of the service for other clients.
Having a share as remote mountable instance of a file system, you can manage
access to a specified share, and list the permissions for a specified share.
The share can be *public* and *private*. This is a level of visibility for the
share that defines whether other tenants can or cannot see the share. By
default, the shares are created as private. While creating a share, use a key
``--public`` to make your share public for other tenants to see it in a list
of shares and see its detailed information.
According to a :ref:`policy.json <shared_fs_policies>` file, an administrator
and the users as share owners can manage the access to the shares by means of
creating access rules. Using **manila access-allow**, **manila access-deny**
and **manila access-list** commands, you can grant, deny and list access to a
specified share correspondingly.
.. tip::
By default, when a share is created and has its export location, the Shared
File Systems service expects that nobody can access the share by mounting
it. Pay attention that the share driver you use can change this
configuration, or it can be directly changed on the share storage. To
ensure the access to the share, check the mounting config for the export
protocol.
When the share is just created there are no created access rules and expected
permission to mount a share. This is obtained by the mounting config for the
certain export protocol. For example, for the NFS protocol there is
``exportfs`` command or ``/etc/exports`` file on the storage which controls
each remote share and the hosts that can access it. It is empty if nobody can
mount a share. For the remote CIFS server there is ``net conf list`` command
which shows the configuration. The parameter ``hosts deny`` should be set by
the share driver to ``0.0.0.0/0`` which means that that hosts are denied to
mount the share.
Using the Shared File Systems service, you can grant or deny access to a share
by specifying one of these supported share access levels:
- **rw**. Read and write (RW) access. This is the default value.
- **ro**. Read-only (RO) access.
.. tip::
The RO access level can be helpful in the public shares when the
administrator gives read and write (RW) access for some certain editors or
contributors and gives read-only (RO) access for the rest of users
(viewers).
You must also specify one of these supported authentication methods:
* **ip**. Authenticates an instance through its IP address. A valid format is
XX.XX.XX.XX or XX.XX.XX.XX/XX. For example 0.0.0.0/0.
* **cert**. Authenticates an instance through a TLS certificate. Specify the
TLS identity as the IDENTKEY. A valid value is any string up to 64 characters
long in the common name (CN) of the certificate.
* **user**. Authenticates by a specified user or group name. A valid value is
an alphanumeric string that can contain some special characters and is from 4
to 32 characters long.
.. note::
The supported authentication methods depend on which share driver, security
service and shared file system protocol you configure and use. Supported
shared file system protocols are NFS, CIFS, GlusterFS, and HDFS. Supported
security services are LDAP, Kerberos protocols, or Microsoft Active
Directory service. For details of supporting of features by different
drivers, see `Manila share features support mapping <http://docs.openstack.
org/developer/manila/devref/share_back_ends_feature_support_
mapping.html>`_.
To verify that the access rules (ACL) were configured correctly for a share,
you can list permissions for a share.
.. tip::
You also can choose and add the :ref:`security service
<shared_fs_security_services>` that is supported by the share driver to
create access rules with authentication methods for clients that are
appropriate for your share. The supported security services are LDAP,
Kerberos and Microsoft Active Directory.
Below is an example of the NFS share with the Generic driver. After the share
was created it has export location
``10.254.0.3:/shares/share-b2874f8d-d428-4a5c-b056-e6af80a995de``. If you try
to mount it on the host with ``10.254.0.4`` IP address, you'll get the
*"Permission denied"* message.
.. code:: console
# mount.nfs -v 10.254.0.3:/shares/share-b2874f8d-d428-4a5c-b056-e6af80a995de /mnt
mount.nfs: timeout set for Mon Oct 12 13:07:47 2015
mount.nfs: trying text-based options 'vers=4,addr=10.254.0.3,clientaddr=10.254.0.4'
mount.nfs: mount(2): Permission denied
mount.nfs: access denied by server while mounting 10.254.0.3:/shares/share-b2874f8d-...
As an administrator, you can connect through SSH to a host with ``10.254.0.3``
IP address, check the :file:`/etc/exports` file on it and see that it is empty:
.. code:: console
# cat /etc/exports
#
The Generic driver we use in example does not support any of the security
services, thus with NFS shared file system protocol we can grant access only
through the IP address:
.. code:: console
$ manila access-allow Share_demo2 ip 10.254.0.4
+--------------+--------------------------------------+
| Property | Value |
+--------------+--------------------------------------+
| share_id | e57c25a8-0392-444f-9ffc-5daadb9f756c |
| access_type | ip |
| access_to | 10.254.0.4 |
| access_level | rw |
| state | new |
| id | 62b8e453-d712-4074-8410-eab6227ba267 |
+--------------+--------------------------------------+
After the rule has status ``active`` we can connect to the ``10.254.0.3`` host
again and check the :file:`/etc/exports` file and see that the line with rule
was added:
.. code:: console
# cat /etc/exports
/shares/share-b2874f8d-d428-4a5c-b056-e6af80a995de 10.254.0.4(rw,sync,wdelay,hide,nocrossmnt,secure,root_squash,no_all_squash,no_subtree_check,secure_locks,acl,anonuid=65534,anongid=65534,sec=sys,rw,root_squash,no_all_squash)
#
Now we can mount a share on the host with IP address ``10.254.0.4`` and have
``rw`` permissions to the share:
.. code:: console
# mount.nfs -v 10.254.0.3:/shares/share-b2874f8d-d428-4a5c-b056-e6af80a995de /mnt
# ls -a /mnt
. .. lost+found
# echo "Hello!" > /mnt/1.txt
# ls -a /mnt
. .. 1.txt lost+found
#
You also can list the access rules to each share and deny the access using the
Shared File Systems service CLI.
.. tip::
To ensure that the granted or denied access with Shared File Systems
service CLI is correct, check the mount config file on the storage before
releasing a share to the production.

121
security-guide/source/shared-file-systems/share-type-acl.rst Normal file
View File

@ -0,0 +1,121 @@
.. _shared_fs_share_types_acl:
=========================
Share type access control
=========================
A share type is an administrator-defined "type of service", comprised of a
tenant visible description, and a list of non-tenant-visible key-value pairs -
extra specifications. The manila-scheduler uses extra specifications to make
scheduling decisions, and drivers control the share creation.
The administrators can create and delete share types, and manage the extra
specifications that give them meaning inside the Shared File Systems service.
Tenants can list the share types and can use them to create new shares. For
details of managing the share types, see `Shared File Systems API
<http://developer.openstack.org/api-ref-share-v2.html#share-type>`_ and
`Share types managing <http://docs.openstack.org/admin-guide-cloud/
shared_file_systems_share_types.html>`_ documentation.
The shares types can be created as *public* and *private*. This is the level of
visibility for the share type that defines whether other tenants can or cannot
see it in a share types list and use it to create a new share.
By default, the share types are created as public. While creating a share type,
use ``--is_public`` parameter set to ``False`` to make your share type private
for other tenants not to see it in a list of share types and create new share
with it.
The *public* share types are available to every tenant in a cloud.
The Shared File Systems service allows the administrators to grant or deny
access to the *private* share types for some certain tenants. You also can get
information about access for a specified private share type.
.. tip::
Since the share types due to their extra specifications help to filter or
choose back ends before users create a share, using access to the share
types you can limit clients that can choose definite back end.
As an example, being an administrator user in admin tenant, you can create a
private share type named ``my_type`` and see it in the list. In the console
examples the logging in and out is omitted, and environment variables are
provided to show the current logged in user.
.. code:: console
$ env | grep OS_
...
OS_USERNAME=admin
OS_TENANT_NAME=admin
...
$ manila type-list --all
+----+--------+-----------+-----------+-----------------------------------+-----------------------+
| ID | Name | Visibility| is_default| required_extra_specs | optional_extra_specs |
+----+--------+-----------+-----------+-----------------------------------+-----------------------+
| 4..| my_type| private | - | driver_handles_share_servers:False| snapshot_support:True |
| 5..| default| public | YES | driver_handles_share_servers:True | snapshot_support:True |
+----+--------+-----------+-----------+-----------------------------------+-----------------------+
The demo user in demo tenant can list the types and the private share type
named ``my_type`` is not visible for him.
.. code:: console
$ env | grep OS_
...
OS_USERNAME=demo
OS_TENANT_NAME=demo
...
$ manila type-list --all
+----+--------+-----------+-----------+----------------------------------+----------------------+
| ID | Name | Visibility| is_default| required_extra_specs | optional_extra_specs |
+----+--------+-----------+-----------+----------------------------------+----------------------+
| 5..| default| public | YES | driver_handles_share_servers:True| snapshot_support:True|
+----+--------+-----------+-----------+----------------------------------+----------------------+
The administrator can grant the access to the private share type for the demo
tenant with the tenant ID equal to df29a37db5ae48d19b349fe947fada46:
.. code:: console
$ env | grep OS_
...
OS_USERNAME=admin
OS_TENANT_NAME=admin
...
$ openstack project list
+----------------------------------+--------------------+
| ID | Name |
+----------------------------------+--------------------+
| ... | ... |
| df29a37db5ae48d19b349fe947fada46 | demo |
+----------------------------------+--------------------+
$ manila type-access-add my_type df29a37db5ae48d19b349fe947fada46
Thus now the users in demo tenant can see the private share type and use it in
the share creation:
.. code:: console
$ env | grep OS_
...
OS_USERNAME=demo
OS_TENANT_NAME=demo
...
$ manila type-list --all
+----+--------+-----------+-----------+-----------------------------------+-----------------------+
| ID | Name | Visibility| is_default| required_extra_specs | optional_extra_specs |
+----+--------+-----------+-----------+-----------------------------------+-----------------------+
| 4..| my_type| private | - | driver_handles_share_servers:False| snapshot_support:True |
| 5..| default| public | YES | driver_handles_share_servers:True | snapshot_support:True |
+----+--------+-----------+-----------+-----------------------------------+-----------------------+
To deny access for a specified project, use
**manila type-access-remove <share_type> <project_id>** command.
.. tip::
A **real production use case** that shows the purpose of a share types and
access to them is a situation when you have two back ends: cheap LVM as a
public storage and expensive Ceph as a private storage. In this case you
can grant access to the certain tenants and make the access with
``user/group`` authentication method.