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.
