[Gluster-users] Secure Setup / Separate GlusterFS / Encryption

[Jeff Darcy]

On 09/18/2013 06:01 AM, Michael.OBrien wrote:
> Should everything from bricks to storage nodes and the storage data network
> be separated into different glusterFS’s or can I share storage nodes across
>  different clients without fear of crossed wires or a rogue client being
> able to list the other mount points of other clients or worse access their
> data?

There are several pieces to this puzzle.

One feature that already exists, though it's not as widely used and thus
"battle hardened" as I'd like, is SSL.  You can specify that a particular
volume uses SSL, and create client/server certificates so that only clients
with recognized certificates can connect to that volume.  Thus, multiple bricks
and volumes can be present on one server, but a client could only connect to
those for which they have certificates.

Another feature that's still in the pipeline is volume multi-tenancy.  This
allows multiple distinct tenants to share a volume without being able to see
each others' files.  Basically each tenant gets its own subdirectory within
each brick, though other implementations are possible.  This relates to both
SSL (to authenticate tenants) and quota (which is also still a work in progress).

> My mindset would be to try and compare it to a SAN (but I’m not a SAN guy
> either) where disk storage is pooled and provisioned as LUN’s and the LUN’s
> are presented to certain HBA’s . The SAN can be configured so that only
> particular HBA’s can access a LUN so even if the client is compromised the
> SAN doesn’t allow it to access other LUN’s

This is essentially what you would get (plus on-the-wire encryption) with the
features above.

> Finally also on the topic of security how would people suggest handling
> encryption of client data and working with a storage server hosting
> different encrypted data

Server-side encryption is possible now, using mechanisms outside of GlusterFS
(e.g. LUKS or ecryptfs).  The weakness of such approaches is that the same
entity - the server operator - will have access to both the encrypted data and
keys.  In far too many cases, this means both will be equally available to an
attacker (or even more likely insider).  You might as well not bother
encrypting at all IMO.

A more robust solution was developed for HekaFS (my now-dormant flavor of
GlusterFS).  In that solution, encryption is done *on the client* using keys
that never exist on servers.  This provides both security and deniability,
either of which can be critical in current environments.  A medium-strength
version of this encryption has existed for about two years in HekaFS, though
enough has changed that it would probably require a refresh before it could
even build.  A stronger version - developed in concert with security experts at
Red Hat and on par with anything else that's out there - has been in review for
a while and might appear in the next GlusterFS release or two.  Bear in mind
that even the "medium-strength" version is far more secure in practice than any
server-side encryption method.