Security concerns with glusterfs?

Solution 1:

TL,DR: Adding servers to the cluster (called pool) is safe, because a 3rd party cannot join an existing cluster on it's own, it needs to be invited from within. But make sure to restrict which clients can mount the volumes and encrypt the connections.

There was no questions asked. I did nothing to tell server2 to allow server1 to add it to the cluster.

I had this question myself so I went to take a look at the documentation.

When you are creating a new cluster, you start on one server and add others using gluster peer probe OTHER_SERVER. Additional security isn't strictly required, because you are adding new, uninitialized glusterfs servers. (Unless you leave a freshly installed, uninitialized gluster running with public access - then you are in trouble).

So what prevents an attacker from joining your existing cluster? The key is the following paragraph:

Once this pool has been established, only trusted members may probe new servers into the pool. A new server cannot probe the pool, it must be probed from the pool. (source)

As the documentation says, a 3rd party/adversary cannot join your cluster, it needs to be invited from within.

Note that clients do not need to be in the pool to mount the volumes.

Gluster also provides other security mechanisms to restrict access to data and to mitigate against related attacks:

• IP allow/deny on volume level, gluster volume set VOL_NAME auth.allow IP1,IP2
• TLS - transport encryption as well as using identities from certificates instead of IP addresses for authorization (not enabled by default and out of scope of this answer, see link)

So if the volumes are not meant to be public:

• use encrypted and authenticated links between servers and servers-clients (Gluster TLS/IPSec/VPN)
• with a firewall setup that does not allow any connections from the outside
• and use auth.allow (auth.ssl-allow for TLS) for finer control on the volume level.

Solution 2:

Your Gluster servers should be on their own, firewalled off section of your infrastructure. They are not intended to be exposed to the public internet.

Solution 3:

I agree that this is insane: security is an add-on to glusterfs. As pointed out by @ceejayoz, glusterfs is designed to only be run on a physically secured and isolated network.

Fortunately, glusterfs has added on ssl support, which is sadly almost completely undocumented. Presumably using ssl will make things better, although since it's undocumented it's hard to say for certain. What documentation exists is in this blog. Sadly, it only gives a sequence of steps.

Solution 4:

I'd like to add to this topic for reference, because I too initially had security concerns with glusterfs.

My organization is in the process of deploying a quite large RHGS cluster to consolidate multiple dispersed aging storage systems.

The security concerns I had was related to the ability to run the gluster console commmands as root from a client system such as...

"yes | gluster --remote-host=rhgs1 volume delete data"

Yikes! It looks like anybody with root privileges on a system that you don't control the root account on, can destroy your data!

Luckily this is not the case. Any of the commands that modify volumes return an exit status of 1 and fail with EPOLLERR as indicated by /var/log/glusterfs/cli.log. It appears you can only get info about the volumes for which that client has access.

Basically the system has to be a cluster peer to be able to perform cluster maintenance tasks from any of the gluster nodes. Now I get why they call a glusterfs cluster a "Secure Storage Pool".