Gluster users - Sep 2013 - Secure Setup / Separate GlusterFS / Encryption

Hi Gluster Users,

 

I'm looking for some advice or best practice recommendations when it
comes to designing secure glusterFS environments. I'm talking about the
basic design principles that a user should consider irrespective of the
content that will be stored. I realise security isn't a destination but
a journey but I'd appreciate any advice you may have and it goes without
saying that if the content is that important it should be separated.

 

What is the current advise on configuring secure glusterFS environments
or the trade-offs to consider? 

 

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? 

 

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

 

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

 

Michael

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://supercolony.gluster.org/pipermail/gluster-users/attachments/20130918/6429d503/attachment.html>

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.