Setting up Lustre Security

This page summarizes Lustre's security features and points to a detailed guide for each. The authoritative references are the Managing Security, Mapping UIDs and GIDs with Nodemap, and Configuring Shared-Secret Key (SSK) Security chapters of the Lustre Operations Manual.

Feature Summary

Feature	Protects against	Configured on	Details
POSIX ACLs	Permissions that are too coarse	MDS (applies filesystem-wide)	Below
Root squash and nodemaps	Client root acting as filesystem root; ID collisions between sites	MGS	UID/GID Mapping, Lustre Multi Tenancy
Namespace isolation (filesets)	Tenants seeing each other's files	MGS	Lustre Multi Tenancy
Kerberos and Shared-Secret Key	Unauthorized or spoofed nodes; tampering with or eavesdropping on RPCs	All nodes	Lustre Kerberos SSK Authentication
Client-side encryption	Disclosure of file contents on the wire or from server storage	Clients	Lustre Client Encryption
SELinux	Clients not enforcing the expected MAC policy	Clients; policy check enforced through nodemaps	Below
Role-based admin control	Tenants running privileged operations (quota, changelogs, HSM, DNE, and more)	Nodemap rbac property	Lustre Multi Tenancy
Auditing	Unrecorded file access	Changelogs, plus the per-nodemap audit_mode property	Monitoring a Lustre File System chapter of the manual

These features complement each other. A typical multi-tenant site uses nodemaps and filesets for isolation, SSK or Kerberos so that tenants cannot impersonate each other's NIDs, and client-side encryption where data must stay confidential even from storage administrators.

Access Control Lists

Lustre supports POSIX ACLs through the standard getfacl and setfacl tools. ACLs are enabled by default and are controlled filesystem-wide by the MDS mount options acl and noacl: either every client has ACLs or none does. No client-side configuration is needed.

Root Squash

Without root squash, root on any client can read, modify, or delete any file. The preferred way to set up root squash is through nodemaps. With the admin property at its default of 0, root on that nodemap's clients is mapped to squash_uid/squash_gid (default 65534). Combined with ID mapping, this lets clients keep a local root without having root on the filesystem. See Lustre Multi Tenancy.

SELinux

Lustre supports SELinux on the client side, storing labels in the security.selinux extended attribute. Every client must run the SELinux policy provided by its Linux distribution. Servers do not need SELinux.

MLS protection only works if every client actually enforces the right policy, so servers can require it per nodemap:

1. On a client known to enforce the correct policy, get its status string. The format is mode:name:version:hash, where mode 1 means enforcing:

   client# l_getsepol

   SELinux status info: 1:mls:31:40afb76d...

2. Require that string for a nodemap:

   mgs# lctl nodemap_set_sepol --name restricted --sepol '1:mls:31:40afb76d...'

3. Make the requirement persistent:

   mgs# lctl set_param -P nodemap.restricted.sepol=1:mls:31:40afb76d...

4. On the clients, set the ptlrpc module parameter send_sepol to a non-zero value so they report their status: -1 to report on every request, or N to refresh every N seconds.

Clients in that nodemap that do not report a matching policy get "Permission denied" when they mount or access files. To remove the requirement, set --sepol "".

See Also

• Lustre Multi Tenancy
• UID/GID Mapping
• Lustre Kerberos SSK Authentication
• Lustre Client Encryption
• Shared Secret Key Authentication And Encryption — SSK background and design references
• Security