A GlusterFS volume can be reachable from more systems than intended when peer membership, brick ports, client allowlists, or TLS settings drift from the storage design. Hardening starts by proving which servers belong to the trusted pool, which endpoints are listening, and which clients can fetch the volume file.
The native GlusterFS client asks a trusted-pool node for volume configuration, then connects to the brick processes that serve file data. Peer status, auth.allow, auth.reject, auth.ssl-allow, and the client.ssl and server.ssl options protect different parts of that path, while host firewalls still control which management and brick ports are reachable.
Security changes can block new mounts or peer communication immediately. Review one volume at a time, keep an active trusted-pool shell available for rollback, and test from both an approved client and an unapproved source before treating the policy as enforced.
Related: How to restrict GlusterFS client access
Related: How to enable TLS for GlusterFS
Related: How to check GlusterFS logs
Steps to improve GlusterFS security:
- List volumes managed by the trusted pool.
$ sudo gluster volume list volume1 volume2
- Confirm every peer is expected and connected.
$ 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)
Do not detach a peer that still hosts active bricks; that can reduce replica availability or leave volume tasks incomplete.
- Check live brick state for the target 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 2143 Brick node2:/srv/gluster/brick1 49153 0 Y 2311 Brick node3:/srv/gluster/brick1 49154 0 Y 2449 Brick node4:/srv/gluster/brick1 49155 0 Y 2520 Task Status of Volume volume1 ------------------------------------------------------------------------------ There are no active volume tasks
Online should show Y for every expected brick before access or encryption changes are made.
Related: How to check GlusterFS volume status - Inspect listening GlusterFS TCP ports on each node.
$ sudo ss --tcp --listening --numeric --processes State Recv-Q Send-Q Local Address:Port Peer Address:Port Process 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:49152 0.0.0.0:* users:(("glusterfsd",pid=2143,fd=14)) LISTEN 0 128 0.0.0.0:49153 0.0.0.0:* users:(("glusterfsd",pid=2311,fd=14)) ##### snipped #####Allow management and brick ports only from trusted peer networks and approved client networks.
- Review access and TLS volume options together.
$ sudo gluster volume get volume1 all Option Value ------ ----- auth.allow 10.0.0.0/24,10.0.0.21 auth.reject none auth.ssl-allow storage-client-01 client.ssl on server.ssl on server.allow-insecure off ##### snipped #####
auth.allow and auth.reject control source access. auth.ssl-allow applies certificate identity authorization after native protocol TLS is enabled.
- Set the native mount allowlist for approved clients.
$ sudo gluster volume set volume1 auth.allow 10.0.0.0/24,10.0.0.21 volume set: success
A wrong auth.allow value blocks new client mounts until corrected from a trusted-pool node.
- Verify the stored allowlist value.
$ sudo gluster volume get volume1 auth.allow Option Value ------ ----- auth.allow 10.0.0.0/24,10.0.0.21
- Keep insecure client ports disabled unless legacy clients require them.
$ sudo gluster volume get volume1 server.allow-insecure Option Value ------ ----- server.allow-insecure off
Enable server.allow-insecure only for a documented compatibility requirement, because it allows client traffic from unprivileged source ports.
- Enable native protocol TLS after certificates are deployed on every peer and client.
Missing or mismatched certificate files can break mounts and peer operations when client.ssl, server.ssl, or management TLS is enforced.
Related: How to enable TLS for GlusterFS
- Verify certificate-based client authorization when it is used.
$ sudo gluster volume get volume1 auth.ssl-allow Option Value ------ ----- auth.ssl-allow storage-client-01
Certificate identities must match the names expected by the GlusterFS certificate setup.
- Confirm NFS or Samba exports are enabled only when required.
Native GlusterFS TLS does not replace authorization on separate export layers.
Related: How to export GlusterFS volume as NFS share
Related: How to export a GlusterFS volume as a Samba share - Mount the volume from an approved client.
$ sudo mount -t glusterfs node1:/volume1 /mnt/volume1
The client source address must match auth.allow.
Related: How to mount a GlusterFS volume in Linux - Verify the approved client mount is active.
$ df -h /mnt/volume1 Filesystem Size Used Avail Use% Mounted on node1:/volume1 1.0T 120G 880G 13% /mnt/volume1
- Attempt the same mount from an unapproved client.
$ sudo mount -t glusterfs node1:/volume1 /mnt/volume1 mount.glusterfs: Volume file download failed: Permission denied
Run the denial test from a source outside auth.allow; testing from an approved client does not prove the deny path.
- Locate recent GlusterFS logs for access or TLS failures.
$ sudo ls /var/log/glusterfs bricks cli.log glusterd.log glustershd.log mnt-volume1.log
Denied mounts, certificate errors, and peer handshake failures are usually visible in glusterd, mount, or brick logs.
Related: How to check GlusterFS logs
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.
