Shared File Systems (Manila) and Managing Security services

The OpenStack Shared File System is a service which helps every case of Compute to utilize the shared file system.

It is offered with the help of following selected services:

manila-api:

It is a Web Server Gateway Interface (WSGI) application which verifies and directs the requests across the shared file system service and also provides support to the OpenStack APIs.

manila-data:

The objective of this independent service is to accept the requests, carry out the data operations with the help of services that probably run for a long time like copying, backup or sharing migration.

manila-scheduler:

manila-scheduler is a service whose purpose is to schedule and direct the requests to the proper shared file system services. For directing the requests, this scheduler takes help of customizable filters and weighing or weighers. The manila-scheduler is default and it starts the filters when the things like Capacity, Availability Zone, Share Types and Capabilities and also the customized filters gets triggered.

manila-share:

All the back end machines or devices which offer the shared file systems are managed by manila-share services. This service can work in any of the two modes, along with or in the absence of share servers. Through share networks, share servers transport the file shares. In the absence of share servers, all the networking needs are managed away from or outside of the manila.

Components involved in the Shared File Systems service:

1. Users and projects (or tenants):

We have already discussed that the Shared File System Service are used by users. These users can be either various cloud computing users or tenants. They can use Shared File System service with the help of role based access projects. That means the roles assigned to the users decides the actions to be performed by that user.

But most of the actions do not require a specific role in the default configuration, until those actions are limited to the administrators. Still if the system administrators want to configure them, then they can configure it properly in the policy.json file which manages the rules.

A project can restrict a users’ access to handle the specific share. If a guest wants to access the mount and consume the shares, then it is secured by IP and/or user access rules. As per each project, the quotas are assigned for controlling the resource usage throughout the offered hardware resources.

 For projects, controlling quota is accessible to restrict:

• Quantity of shares which can be generated.
• Quantity of the GB which can be preplanned for the shares.
• Quantity of the share snaps which can be generated.
• Quantity of the gigabytes which can be preplanned for the share snaps.
• Quantity of share networks which can be generated.

Administrators can edit the restrictions allocated by the quotas; therefore it is important to reconsider the default values of the quotas using Shared File Systems’ Command Line Interpreter.

• Back-end storage devices:

As discussed earlier, the Shared File Services requires back end devices. In other words we can say that these services needs some kind of back end shared file system supplier on which the shared file system services are implemented. The performance of the resource takes help of Block Storage service (Cinder) and also a virtual machine service to offer shares. With the help of extra drivers the shared file systems can be accessed through a series of vendor services.

• Basic resources: Shares, snapshots, and share networks:

Shares, snapshots and share networks are the basic resources which are provided by the Shared File System service. Let’s discuss about them in detail:

• Shares:

It is a unit of storage which includes a protocol, a size and an access list. Shares are the original units offered by manila. All of them reside on a backend and few of them are connected with share networks and share servers. Shares support the main protocols like NFS, CIFs as well as some other protocols.

• Snapshots:

A snapshot is a copy of share in the moment of time, which is used only for creating a new share including the data which is snapshot. Unless and until all the related snapshots are removed or deleted, it is not possible to delete shares.

• Share networks:

It is an object described by using a project which notifies manila regarding the security and network setup for a set of shares. These are applicable only for the backends which controls the share servers. It includes security service as well as security network or subnet.

For verification and confirmation of the users, the storage service of the Shared File Systems may be configured optionally with the help of various authentication protocols. Share networks provide support to the authentication protocols like LDAP, Kerberos and Microsoft Active Directory authentication service.

Security services:

Once a share is created and once its dispatch location is received, then users are not allowed to implement it as well as work with files. Shared File System needs to specifically allocate or grant the access to the new share.

By using security services the user configuration data for verification and confirmation can be stored. The authentication protocols like LDAP, Kerberos or Microsoft Active Directory are utilized by the Shared File Systems service, only if these protocols are supported by drives and back ends. It is possible to configure the verification services without using the Shared File Systems’ service.

Important Note:

In few situations it is needed to specifically mention one of the security services like NetApp, EMC and Windows drivers need Active Directory for the development of shares with the help of CIFS protocol.

Management of Security Services:

This service is an object of the Shared File Systems’ service which extracts a group of options that describes a security domain for a specific shared file system protocol like Kerberos domain or an Active Directory domain. Security service consists of complete information required for the Shared File Systems for creating a server which connects to a given domain.

With the help of APIs it is possible for the users to create, update view and delete a security services.

These security services are designed on the basis of following rules:

1. Projects or tenants give the security service details.
2. Admin users takes care of the security services i.e. they setup the server side of such type of security services. On the inside of the shared file systems’ API, a security_service is related with the share_networks. For configuring the newly developed share servers, the share driver takes help of data present in the security service.
3. One of the following authentication services can be selected at the time of creating a security service:
4. LDAP: It is an abbreviation for the Lightweight Directory Access Protocol, which is an application protocol for examining and managing distributed directory information services above an IP network.
5. Kerberos: It is a network authentication protocol that works on the base of tickets for allowing nodes interacting via an unsecure network for proving their identity to each other in a secure way.
6. Active Directory: It is a directory service which is developed by Microsoft for Windows domain networks and it takes help of LDAP, Microsoft’s version of Kerberos and DNS.

With the help of following options, the Shared File Systems’ service permits you to setup a security service:

• DNS IP addresses which is utilized on the inside of the project network.
• A security service’ IP address or host name.
• Security services Domain.
• User name or group name which is utilized by a project.
• If you mention a user name then a password for that user.
• If there is any existing security service object then it can be related with objects of share network which tells the shared File Systems service regarding the security and the network customization for a set of shares. It is also possible to view the list of entire security services for a particular share network and can be disconnected from a share network.
• Users and the administrator as a owner of share can handle the permission to the shares by developing or creating rules related to the access with the help of verification via an IP address, user, group, or TLS certificates. Verification methods are based on which share driver and security service that you are customizing and using.
• As an administrator, you can customize a back end for using a particular verification service through network and that will also store the users. The verification service can work with users in the absence of the shared file system and the identification service.

Important Note:

As discussed earlier, variety of authentication services are backed by variety of shared drivers. Different authentication services are supported by different share drivers. Providing a support for a particular verification service with the help of a driver does not indicate that security services can be setup by using any shared file system protocol like NFS, CIFS, GlusterFS and HDFS.

The security services that mentioned above are supported by few drives and some other drivers do not support them. For instance, Generic Driver along with NFS or the CIFS shared file system protocol provides support just for the verification method via an IP address.

Hint:

• The drivers which provide support to the CIFS shared file system protocol, in many situations could be customized for using Active Directory and managing access via user verification.
• It is possible to use the drivers which support the GlusterFS protocol for authentication through TLS certificates.
• For the drivers which support NFS protocol verification through an IP address is the only one supported option.
• As the HDFS shared file system protocol utilizes the VFS access, it can also be setup for authentication through an IP address.
• Keep in mind that, even though the verification through IP address is the most minimal secure type of verification.
• The approved customization for the shared file systems’ service original use is to generate a share with the help of CIFS share protocol and then insert into it the directory service of Microsoft Active Directory. Through this customization you will receive a centralized database and also a service which will combine with the Kerberos and LDAP. This is the actual use case which is appropriate for production shared file systems.

That’s all for today! I hope you find this information useful and please do not forget to add a comment in the comment section below. Thank you for reading the blog! See you soon with another interesting blog!