Separate Silos

Matters of Security

The concept of access via a shared network raises issues in the setups where the back end does not manage its own share servers, because these drivers require either shared networks or gateway functionality – especially in those setups that are actually designed for strict separation of networks.

That raises the important question: How can unauthorized access be prevented? As long as purely virtual private networks are used, the SDN solution takes care of it; however, it is precisely this mechanism that is leveraged by the shared network. The Manila developers' answer is an ACL system that works on an IP basis. The IP space where access is possible can be defined for each share. In the last step, a user also has the option to allow access only to a single IP address.

Security Plus

Theoretically speaking, even if a client were to access a Manila share, it wouldn't mean they could actually use it, because Manila implements its own access system with a login and password where potential clients first need to register. Again, the quality of the implementation is very much dependent on the capabilities of the respective storage driver. The framework in Manila itself is as flexible as possible: LDAP, Kerberos, and Active Directory are available. Using these protocols, admins can define a security service needed by the respective storage drivers to communicate.

That's it for the available drivers in terms of support for those security services. Only NetApps's ONTAP driver has all three modes. The driver designed for CIFS can at least be addressed via Active Directory. The generic driver, which doesn't have any of the three mechanisms described, comes off badly. In such cases, the admin ultimately has no other choice than to switch off the security service control; this might make the setup easier, but it is a setback in terms of security.

On the Dashboard

Even if, as you know, everything involving APIs for the OpenStack services can be controlled in the brave new world of the cloud, many admins still feel more comfortable if they have graphical access to technology they are not familiar with – at least in the beginning. This scenario is what the OpenStack dashboard addresses, alias Horizon. However, anyone who installs the vanilla version of the dashboard will have to do without Manila, because the UI plugin for Manila in Horizon still hasn't made it into the official Horizon source code.

You might be able to solve the problem on the command line, but the solution involves the manual installation of the UI module in Horizon. If in doubt, admins that have completely automated their cloud need to build a package for their own system themselves from the Manila plugin for Horizon. Nevertheless, anyone with experience in building packages will not encounter unsolvable problems, but it cannot be denied that this leaves a bitter taste (Figure 5).

Figure 5: A UI module for Horizon exists, but the admin has to install it separately.