“Security in Lustre reflects its roots as a high performance computing (HPC) file system,” said John Hammond of Intel’s High Performance Data Division. In traditional HPC deployments, Lustre resides in a physically secure and logically isolated environment, dependent on strict network access controls, managed by large and siloed teams focused on what’s happening with the systems, and accessed by users already holding appropriate clearances to log on and use the resources. According to Hammond, “Lustre assumes that if a client could connect, it would connect.” Of course, this presents security risks for today’s enterprise environments.

“In the enterprise, computing resources are often connected to wider, shared networks—including the Internet—that may be directly or indirectly accessible to a wide range of users with various privileges,” added Andreas Dilger, principal engineer for Intel’s Lustre development team. “Data center management teams are usually smaller, spread thin in their diverse responsibilities, and used to dealing with more standard security infrastructures and mechanisms that have protections inherent in the file system.” Thus, as Lustre has expanded into more corporate environments, its users have requested deeper security in the file system. Now available, version 2.8 of the community release and 3.0 of the Intel Enterprise Edition for Lustre software (Intel EE for Lustre software) have added three critical security features in Lustre: client and user authentication, policy-based file access restrictions, and encryption.

Kerberos Authentication and Encryption is Back

Kerberos has long been a part of Lustre, but until a couple of years ago, it had been largely unused for various reasons. Community developers revived Kerberos to provide fundamental security features needed by enterprise IT departments. Today, Kerberos version 5 in Lustre can authenticate individual clients, users, and the Meta data servers (MDSs) to allow clients to mount the file system and give users access to the files. Authentication is mutual—client to server and server to client—using standard Linux user credentials and Kerberos-generated keys.

Kerberos in Lustre

Kerberos in Lustre is designed to authenticate users with the MDSs only. Authenticating every request and authenticating the Object Storage Servers is beyond the current implementation of Kerberos on Lustre.

Additionally, Kerberos provides encryption for information sent over the network, whether it be keys, credentials, or data. The technology has several encryption algorithms at its disposal, and Intel processors integrate hardware acceleration for the algorithms used in Lustre. Performance testing in 2015 by Sebastien Buisson of OpenSFS member Data Direct Networks revealed a very modest impact with authentication, as seen in his presentation (http://wiki.lustre.org/images/e/ec/Lustre-and-Kerberos_Buisson.pdf) at the 2015 Lustre User Group (LUG). When encryption was enabled, the impact was much more significant, but the system still delivered 500 to 700 MB/sec, which is still very fast when compared to WAN performance where this would typically be needed. Thus Kerberos gives important security capabilities for critical workloads in some industries, such as health sciences, where data security in transit is often a requirement.

Mandatory Access Controls with SELinux

In an HPC environment, file owners are used to controlling their file access permissions. But organizations with shared sensitive data on an open network often need a greater level of control by some form of policy management. In Lustre, this is implemented with mandatory access controls using SELinux on the client.

SELinux is part of many Linux distributions. SELinux takes file access control out of user space and puts it in kernel space. It labels files and, using type-enforcing mode, enforces security policies on the client, based on the process context. The label is stored in the file’s extended attributes (xattr), so that when the client fetches the label and caches it, SELinux blocks file access to unauthorized clients and grants access to authorized clients.

The way SELinux is implemented in Lustre 2.8 Community edition and 3.0 Intel EE for Lustre software, the SELinux context is not passed to the Meta data targets. It is not enforced on the server. However, using Kerberos, Lustre authenticates a client and user to an MDS, establishing a trust relationship. SELinux, then, enforces that the client has access only to allowed files. Additionally, there are other mechanisms, which are often implemented in IT departments to mitigate lack of SELinux context on the server, including audits, restricting clients that can connect to trusted clients, monitoring configurations to ensure only correctly configured clients are available to connect, and scanning.

SELinux is required in some environments, where it is certified with code suites using approved tests. Many certification suites and tests are not public, and they are tied to the whole security stack, which gets certified together. The Lustre development community does not have access to the entire suite in any one environment. Thus, SELinux in Lustre was limited to fulfill a certain level of security within the file system, so it could be certified as part of the whole stack.

More Security Choices Coming

The Lustre developer community continues to enhance Lustre security with more choices in upcoming software releases.

“Kerberos is a well-known authentication protocol and effective, but it is complex to set up, and it presents technical and political challenges in large organizations when needing to do cross-realm authentication,” said Malcolm Cowe, Lustre product manager for Intel’s High Performance Data Division. “Different sites are typically managed independently. Thus, different users from different administrative domains won’t necessarily have the same UID across the domains. There usually is no unified password file to map differing UIDs across systems to a single user.” But, Lustre uses numerical user IDs (UIDs), making cross-realm authentication impossible without some type of unifying identification.

Indiana University is driving development of a solution that creates a unified identification map based on network IDs (NIDs) that translates the UID and group ID (GID) across realms to the NIDs. The code allows managers to configure ranges of NIDs and map them a certain way so users across domains can access different file systems. “Based on the NID map,” explained Dilger, “if a client with a UID in a remote domain wants to mount a file on a local system, mapping will translate the UID to the proper user on the local system.”

“Besides being a way to simplify cross-realm authentication,” added Hammond, “having a unified identification scheme is a useful security tool. Managers can squash all non-authorized Lustre users in the map, like in NFS.” UID/GID mapping is expected to land in Lustre Community version 2.9.

Where organizations don’t want to use Kerberos for authentication and encryption, code for node authentication only from Indiana University will offer a simpler alternative based on Shared Secret Keys (SSKs). The SSKs method does not authenticate users, and it does not require UID/GID mapping, since it is using SSKs to allow a node access to the file system, even a remote node. But, when it is combined with UID/GID mapping, it enables strong remote, cross-domain authentication and node blocking that does not involve the complexities of setting up Kerberos. The Indiana University solution provides encryption as well as authentication, and it is expected to land in Lustre 2.9.

In enterprises, home directories are commonplace. Yet Lustre exposes the user to the entire namespace. Data Direct Networks has been working on code that will restrict view of the Lustre file system namespace at client mount time to only the subdirectory the client is accessing. “The code changes the FID of the subdirectory to the root of the client directory,” said Hammond. “The client will no longer see the root of the Lustre file tree.” Alone this does not provide adequate security, according to Hammond, but in an authenticated environment and using UID/GID mapping in wide networks, it restricts what subdirectories can be seen by clients. Additionally, subdirectory mounting can be containerized. Each container will mount as a Lustre client and be authenticated with its own credentials. Then, the subdirectory the container has access to can be mounted in the root of the container.

Lustre Spring Cleaning—Ongoing Code Hardening to Improve Security

Clean code is securer code. “We’ve been doing a lot of code cleanup in Lustre of late,” stated Hammond.

“Lustre is 15 years old,” added Dilger. “It has evolved from the Linux 2.4 kernel through the latest kernels, so there’s a lot of code that had originally been needed for compatibility between different kernel versions. Compatibility layers, user space, prototype codes for different platforms that would never be fully implemented—there were lots of wrappers and abstraction layers that needed to be removed. So, we did some spring cleaning. And we continue the efforts.”

Beyond Lustre 2.9

According to Cowe, Lustre security has come a long way. “We’ve added authentication and encryption and mandatory access control support in version 2.8. There are more options coming in 2.9. And we are looking at end-to-end enforcement going forward.”

Author’s note: This year’s Lustre User Group (LUG) included several presentations on security in Lustre. They are well worth reviewing for any Lustre administrator, user, or prospective user. They can be viewed at http://wiki.lustre.org/Lustre_User_Group_2016.