Chapter 17. Hardening the Shared File System (Manila)
The Shared File Systems service (manila) provides a set of services for managing shared file systems in a multi-project cloud environment. With manila, you can create a shared file system and manage its properties, such as visibility, accessibility, and quotas.
For more information on manila, see the Storage Guide: https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/17.0/html-single/storage_guide/
17.1. Security considerations for manila
Manila is registered with keystone, allowing you to the locate the API using the manila endpoints
command. For example:
$ manila endpoints +-------------+-----------------------------------------+ | 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 manila API service only listens on port 8786
with tcp6
, which supports both IPv4 and IPv6.
Manila uses multiple configurations files; these are stored in /var/lib/config-data/puppet-generated/manila/
:
api-paste.ini manila.conf policy.json rootwrap.conf rootwrap.d ./rootwrap.d: share.filters
It is recommended that you configure manila to run under a non-root service account, and change file permissions so that only the system administrator can modify them. Manila expects that only administrators can write to configuration files, and services can only read them through their group membership in the manila
group. Other users must not be able to read these files, as they contain service account passwords.
Only the root user should own be able to write to the configuration for manila-rootwrap
in rootwrap.conf
, and the manila-rootwrap
command filters for share nodes in rootwrap.d/share.filters
.
17.2. Network and security models for manila
A share driver in manila is a Python class that can be set for the back end to manage share operations, some of which are vendor-specific. The back end is an instance of the manila-share
service. Manila has share drivers for many different storage systems, supporting both commercial vendors and open source solutions. Each share driver supports one or more back end modes: share servers
and no share servers
. An administrator selects a mode by specifying it in manila.conf
, using driver_handles_share_servers
.
A share server is a logical Network Attached Storage (NAS) server that exports shared file systems. Back-end storage systems today are sophisticated and can isolate data paths and network paths between different OpenStack projects.
A share server provisioned by a manila share driver would be created on an isolated network that belongs to the project user creating it. The share servers
mode can be configured with either a flat network, or a segmented network, depending on the network provider.
It is possible to have separate drivers for different modes use the same hardware. Depending on the chosen mode, you might need to provide more configuration details through the configuration file.
17.3. Share backend modes
Each share driver supports at least one of the available driver modes:
-
Share servers -
driver_handles_share_servers = True
- The share driver creates share servers and manages 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 a network interface, instead of relying on the presence of the share servers.
No share servers mode
- In this mode, drivers will not set up share servers, and consequently will not need to set up any new network interfaces. It is assumed that storage controller being managed by the driver has all of the network interfaces it is going to need. Drivers create shares directly without previously creating a share server. To create shares using drivers operating in this mode, manila does not require users to create any private share networks either.
In no share servers mode
, manila will assume that the network interfaces through which any shares are exported are already reachable by all projects.
In the no share servers
mode a share driver does not handle share server life cycle. An administrator is expected to handle the storage, networking, and other host-side configuration that might be necessary to provide project isolation. In this mode an administrator can set storage as a host which exports shares. All projects within the OpenStack cloud share a common network pipe. Lack of isolation can impact security and quality of service. When using share drivers that do not handle share servers, cloud users cannot be sure that their shares cannot be accessed by untrusted users by a tree walk over the top directory of their file systems. In public clouds it is possible that all network bandwidth is used by one client, so an administrator should care for this not to happen. Network balancing can be done by any means, and not necessarily just with OpenStack tools.
Share servers mode
- In this mode, a driver is able to create share servers and plug them to existing OpenStack networks. Manila determines if a new share server is required, and provides all the networking information necessary for the share drivers to create the requisite share server.
When creating shares in the driver mode that handles share servers, users must provide a share network that they expect their shares to be exported upon. Manila uses this network to create network ports for the share server on this network.
Users can configure security services
in both share servers
and no share servers
back end modes. But with the no share servers
back end mode, an administrator must set the required authentication services manually on the host. And in share servers
mode manila can configure security services identified by the users on the share servers it spawns.
17.4. Networking requirements for manila
Manila can integrate with different network types: flat
, GRE
, VLAN
, VXLAN
.
Manila is only storing the network information in the database, with the real networks being supplied by the network provider. Manila supports using the OpenStack Networking service (neutron) and also "standalone" pre-configured networking.
In the share servers
back end mode, a share driver creates and manages a share server for each share network. This mode can be divided in two variations:
-
Flat network in
share servers
backend mode -
Segmented network in
share servers
backend mode
Users can use a network and subnet from the OpenStack Networking (neutron) service to create share networks. If the administrator decides to use the StandAloneNetworkPlugin
, users need not provide any networking information since the administrator pre-configures this in the configuration file.
Share servers spawned by some share drivers are Compute servers created with the Compute service. A few of these drivers do not support network plugins.
After a share network is created, manila retrieves network information determined by a network provider: network type, segmentation identifier (if the network uses segmentation) and the IP block in CIDR notation from which to allocate the network.
Users can create security services that specify security requirements such as AD or LDAP domains or a Kerberos realm. Manila assumes that any hosts referred to in security service are reachable from a subnet where a share server is created, which limits the number of cases where this mode could be used.
Some share drivers might not support all types of segmentation, for more details see the specification for the driver you are using.
17.5. Security services with manila
Manila can restrict access to file shares by integrating with network authentication protocols. Each project can have its own authentication domain that functions separately from the cloud’s keystone authentication domain. This project domain can be used to provide authorization (AuthZ) services to applications that run within the OpenStack cloud, including manila. Available authentication protocols include LDAP, Kerberos, and Microsoft Active Directory authentication service.
17.6. Introduction to security services
After creating a share and getting its export location, users have no permissions to mount it and operate with files. Users need to explicitly grant access to the new share.
The client authentication and authorization (authN/authZ) can be performed in conjunction with security services. Manila can use LDAP, Kerberos, or Microsoft Active directory if they are supported by the share drivers and back ends.
In some cases, it is required to explicitly specify one of the security services, for example, NetApp, EMC and Windows drivers require Active Directory for the creation of shares with the CIFS protocol.
17.7. Security services management
A security service is a manila entity that abstracts a set of options that define a security zone 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 manila to create a server that joins a given domain.
Using the API, users can create, update, view, and delete a security service. Security Services are designed on the following assumptions:
- Projects provide details for the security service.
- Administrators care about security services: they configure the server side of such security services.
-
Inside the manila API, a
security_service
is associated with theshare_networks
. - Share drivers use data in the security service to configure newly created share servers.
When creating a security service, you can select one of these authentication services:
- 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.
Manila allows you to configure a security service with these options:
- A DNS IP address that is used inside the project network.
- An IP address or hostname of a security service.
- A domain of a security service.
- A user or group name that is used by a project.
- A password for a user, if you specify a username.
An existing security service entity can be associated with share network entities that inform manila about 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.
An administrator and users as share owners can manage access to the shares by creating access rules with authentication through an IP address, user, group, or TLS certificates. Authentication methods depend on which share driver and security service you configure and use. You can then configure a back end to use a specific authentication service, which can operate with clients without manila and keystone.
Different authentication services are supported by different share drivers. For details of supporting of features by different drivers, see https://docs.openstack.org/manila/latest/admin/share_back_ends_feature_support_mapping.html
Support for a specific authentication service by a driver does not mean that it can be configured with any shared file system protocol. Supported shared file systems protocols are NFS, CEPHFS, CIFS, GlusterFS, and HDFS. See the driver vendor’s documentation for information on a specific driver and its configuration for security services.
Some drivers support security services and other drivers do not support any of the security services mentioned above. For example, Generic Driver with the NFS or the CIFS shared file system protocol supports only authentication method through the IP address.
In most cases, drivers that support the CIFS shared file system protocol can be configured to use Active Directory and manage access through the user authentication.
- Drivers that support the GlusterFS protocol can be used with authentication using TLS certificates.
- With drivers that support NFS protocol authentication using an IP address is the only supported option.
- Since the HDFS shared file system protocol uses NFS access it also can be configured to authenticate using an IP address.
The recommended configuration for production manila deployments is to create a share with the CIFS share protocol and add to it the Microsoft Active Directory directory service. With this configuration you will get the centralized database and the service that integrates the Kerberos and LDAP approaches.
17.8. Share access control
Users can specify which specific clients have access to the shares they create. Due to the keystone service, shares created by individual users are only visible to themselves and other users within the same project. Manila allows users to create shares that are "publicly" visible. These shares are visible in dashboards of users that belong to other OpenStack projects if the owners grant them access, they might even be able to mount these shares if they are made accessible on the network.
While creating a share, use key --public
to make your share public for other projects to see it in a list of shares and see its detailed information.
According to the policy.json
file, an administrator and the users as share owners can manage access to shares by means of creating access rules. Using the manila access-allow
, manila access-deny
, and manila access-list
commands, you can grant, deny and list access to a specified share correspondingly.
Manila does not provide end-to-end management of the storage system. You will still need to separately protect the backend system from unauthorized access. As a result, the protection offered by the manila API can still be circumvented if someone compromises the backend storage device, thereby gaining out of band access.
When a share is just created there are no default access rules associated with it and permission to mount it. This could be seen in mounting config for export protocol in use. For example, there is an NFS command exportfs
or /etc/exports
file on the storage which controls each remote share and defines hosts that can access it. It is empty if nobody can mount a share. For a remote CIFS server there is net conf list
command which shows the configuration. The hosts deny
parameter should be set by the share driver to 0.0.0.0/0
which means that any host is denied to mount the share.
Using manila, 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.
The RO access level can be helpful in 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
- Uses an IP address to authenticate an instance. IP access can be provided to clients addressable by well-formed IPv4 or IPv6 addresses or subnets denoted in CIDR notation. -
cert
- Uses a TLS certificate to authenticate an instance. Specify the TLS identity as theIDENTKEY
. 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.
Supported authentication methods depend on which share driver, security service and shared file system protocol you use. Supported shared file system protocols are MapRFS, CEPHFS, NFS, CIFS, GlusterFS, and HDFS. Supported security services are LDAP, Kerberos protocols, or Microsoft Active Directory service.
To verify that access rules (ACL) were configured correctly for a share, you can list its permissions.
When selecting a security service for your share, you will need to consider whether the share driver is able to create access rules using the available authentication methods. Supported security services are LDAP, Kerberos, and Microsoft Active Directory.
17.9. Share type access control
A share type is an administrator-defined type of service, comprised of a project visible description, and a list of non-project-visible key-value pairs called extra specifications. The manila-scheduler
uses extra specifications to make scheduling decisions, and drivers control the share creation.
An administrator can create and delete share types, and can also manage extra specifications that give them meaning inside manila. Projects can list the share types and can use them to create new shares. Share types can be created as public
and private
. This is the level of visibility for the share type that defines whether other projects can or cannot see it in a share types list and use it to create a new share.
By default, share types are created as public. While creating a share type, use --is_public
parameter set to False
to make your share type private which will prevent other projects from seeing it in a list of share types and creating new shares with it. On the other hand, public
share types are available to every project in a cloud.
Manila allows an administrator to grant or deny access to the private
share types for projects. You can also get information about the access for a specified private share type.
Since 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 in choice of specific back ends.
For example, an administrator user in the admin
project can create a private share type named my_type
and see it in the list. In the console examples below, the logging in and out is omitted, and environment variables are provided to show the currently logged in user.
$ 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 the demo
project can list the types and the private share type named my_type
is not visible for him.
$ 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 access to the private share type for the demo project with the project ID equal to df29a37db5ae48d19b349fe947fada46
:
$ env | grep OS_ ... OS_USERNAME=admin OS_TENANT_NAME=admin ... $ openstack project list +----------------------------------+--------------------+ | ID | Name | +----------------------------------+--------------------+ | ... | ... | | df29a37db5ae48d19b349fe947fada46 | demo | +----------------------------------+--------------------+ $ manila type-access-add my_type df29a37db5ae48d19b349fe947fada46
As a result, users in the demo
project can see the private share type and use it in the share creation:
$ 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>
.
For an example that demonstrates the purpose of the share types, consider a situation where you have two back ends: LVM as a public storage and Ceph as a private storage. In this case you can grant access to certain projects and control access with user/group
authentication method.
17.10. Policies
The Shared File Systems service API is gated with role-based access control policies. These policies determine which user can access certain APIs in a certain way, and are defined in the service’s policy.json
file.
The configuration file policy.json
may be placed anywhere. The path /var/lib/config-data/puppet-generated/manila/etc/manila/policy.json
is expected by default.
Whenever an API call is made to manila, the policy engine uses the appropriate policy definitions to determine if the call can be accepted. A policy rule determines under which circumstances the API call is permitted. The /var/lib/config-data/puppet-generated/manila/etc/manila/policy.json
file has rules where an 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 policy.json
file for manila. It can be expected to change between OpenStack releases.
{ "context_is_admin": "role:admin", "admin_or_owner": "is_admin:True or project_id:%(project_id)s", "default": "rule:admin_or_owner", "share_extension:quotas:show": "", "share_extension:quotas:update": "rule:admin_api", "share_extension:quotas:delete": "rule:admin_api", "share_extension:quota_classes": "", }
Users must be assigned to groups and roles that you refer to in your policies. This is done automatically by the service when user management commands are used.
Any changes to /var/lib/config-data/puppet-generated/manila/etc/manila/policy.json
are effective immediately, which allows new policies to be implemented while manila is running. Manual modification of the policy can have unexpected side effects and is not encouraged. Manila does not provide a default policy file; all the default policies are within the code base. You can generate the default policies from the manila code by executing: oslopolicy-sample-generator --config-file=var/lib/config-data/puppet-generated/manila/etc/manila/manila-policy-generator.conf