Hardening GlusterFS reduces the chance of unauthorized mounts, data disclosure, and disruptive client behavior when storage networks are reachable beyond the intended cluster and client segments.
GlusterFS security hinges on a trusted storage pool for peer membership, per-volume client allowlists, and transport settings that determine whether management and data traffic can be intercepted or modified in transit. Clients mount a volume by retrieving a volume file from the cluster, then establishing TCP connections to the brick processes that serve the data.
Access control and encryption changes can block mounts immediately, so verify client source IPs, hostnames, and certificate identities before enforcing restrictions. Network firewalls remain part of the security boundary because brick ports are reachable over TCP, and additional export layers such as NFS and Samba introduce their own authorization rules.
Related: How to enable TLS for GlusterFS
GlusterFS security hardening checklist:
- List volumes managed by the cluster.
$ sudo gluster volume list volume1 volume2
- Confirm only expected peers are connected in the trusted pool.
$ sudo gluster peer status Number of Peers: 2 Hostname: node2 Uuid: 6770f88c-9ec5-4cf8-b9f5-658fa17b6bdc State: Peer in Cluster (Connected) Hostname: node3 Uuid: 5a3c65f3-1b4d-4d6e-93d4-4c24f0b6b5bf State: Peer in Cluster (Connected)
Detaching a peer that still hosts active bricks can affect volume availability.
- Review brick status and port exposure for each volume.
$ sudo gluster volume status volume1 Status of volume: volume1 Gluster process TCP Port RDMA Port Online Pid ------------------------------------------------------------------------------ Brick node1:/srv/gluster/brick1 49152 0 Y 1443 Brick node2:/srv/gluster/brick1 49153 0 Y 1398
Brick TCP ports shown here should be reachable only from trusted peer networks and approved clients.
Related: How to check GlusterFS volume status
- Inspect listening GlusterFS ports for firewall policy review.
$ sudo ss --tcp --listening --numeric --processes | grep -E 'gluster(d|fsd)' LISTEN 0 128 0.0.0.0:24007 0.0.0.0:* users:(("glusterd",pid=1023,fd=10)) LISTEN 0 128 0.0.0.0:24008 0.0.0.0:* users:(("glusterfsd",pid=1443,fd=13)) LISTEN 0 128 0.0.0.0:49152 0.0.0.0:* users:(("glusterfsd",pid=1443,fd=14)) LISTEN 0 128 0.0.0.0:49153 0.0.0.0:* users:(("glusterfsd",pid=1398,fd=14))Limit management and brick ports to internal networks where possible, and treat exported protocols (NFS, Samba) as additional ingress paths.
- Restrict volume mounts to approved clients or networks.
$ sudo gluster volume set volume1 auth.allow 10.0.0.0/24,10.0.0.21 volume set: success
auth.allow accepts comma-separated IP addresses and CIDR ranges.
- Verify the effective access list for the volume.
$ sudo gluster volume get volume1 auth.allow Volume Name: volume1 auth.allow: 10.0.0.0/24,10.0.0.21
An empty or unset auth.allow value can permit mounts from any reachable client.
- Enable TLS for client and management traffic when certificates are available.
Enforcing TLS without matching certificate material across nodes and clients can prevent mounts and peer connections.
- Confirm NFS or Samba exports are only enabled when required.
- Mount the volume from an approved client host.
$ sudo mkdir -p /mnt/volume1 $ sudo mount -t glusterfs node1:/volume1 /mnt/volume1
Run from a client whose source IP matches auth.allow.
- Verify the mount is active.
$ df -h /mnt/volume1 Filesystem Size Used Avail Use% Mounted on node1:/volume1 200G 21G 180G 11% /mnt/volume1
- Confirm mounts are denied from clients outside the allowlist.
$ sudo mount -t glusterfs node1:/volume1 /mnt/volume1 mount.glusterfs: failed to fetch volume file (Permission denied) mount: /mnt/volume1: mount(2) system call failed: Permission denied.
Testing from a host included in auth.allow does not validate deny behavior.
- Locate recent GlusterFS logs when troubleshooting access failures.
$ sudo ls -1 /var/log/glusterfs cli.log glusterd.log brick-node1-srv-gluster-brick1.log brick-node2-srv-gluster-brick1.log
Log files under /var/log/glusterfs are the primary source for denied mounts, TLS negotiation errors, and peer connectivity issues.
Mohd Shakir Zakaria is a cloud architect with deep roots in software development and open-source advocacy. Certified in AWS, Red Hat, VMware, ITIL, and Linux, he specializes in designing and managing robust cloud and on-premises infrastructures.
