[Gluster-devel] On Identity, UUIDs, IPs, SSL, authentication/verification and fragility
paul at jakma.org
Sat Aug 7 15:01:22 UTC 2021
I'm having issues with Gluster with Peer Rejected states. Adding new
peers to a cluster pool tends to be pot-luck, and if I have a host that
others don't like there doesn't seem to be any way to fix it (from
Debugging, my issues seem to stem from Glusters desire to (implicitly,
via various lookups for the peerinfo) validate the IP of a connection,
against the reverse DNS lookup for the hostname, against the forward
lookup for that hostname, and known hostnames.
I guess this stems from a history of IP-as-authentication-handle in
Gluster, but it's a bit frustrating as I'm using SSL. All the packets
were already authenticated - IP/DNS validation is not really adding for
me security wise (indeed, I don't want any assumption of security by
Part of the background here is that I have a network where:
- Hosts may have a number of IPs
- different interfaces on different subnets (e.g. using VLANs to
through L2 switches and give servers presence on multiple subnets,
while avoiding having to bounce packets in and out of a router; v
- service addresses
- ephemeral privacy addresses
- A DNS hostname may list multiple IPs
- v4 and v6
- or v6 only
- The PTR for an IP may not list the IP
- There may be no PTR for an IP
- An IP may not be listed in any AAAA/A record
E.g., ephemeral and other addresses need not have DNS records. You
generally wouldn't want them to have DNS records either.
What I would like to do is make Gluster just accept the SSL identity,
use that for the UUID binding, and not do any host/IP validation (other
than checking for self).
One way would be to just use the SSL peer identity as the hostname, and
store that in the peerinfo, instead of IP or DNS/name-service host.
Another would be to bolt on SSL identity alongside in the peerinfo, and
My inclination would be to just add an option to use SSL identity as the
canonical hostname, and ignore IPs/name-service hostnames - I just don't
see any value in validating the latter when you have strong TLS
authentication in place.
Would such a patch be welcome?
Cause I really need some kind of fix for the current behaviour of
gluster - it just doesn't work on more complex network setups, esp.
Note: Client mount code seems to have similar issues. Will dig into that
(it has a workaround), but need to fix the server side first for myself.
Paul Jakma | paul at jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A
There is no fool to the old fool.
-- John Heywood
More information about the Gluster-devel