> It is true default glusterfs installation is too open. A simple > solution would be to introduce an access control, either by > IP whitelist, or better by shared secret. > > The obvious problem is that it breaks updates. At least peer > know each others and could agree on automatically creating > a shared secret if it is missing, but we need to break clients. > The annoyance can be mitigated with an helpful message on mount > failure, in the log and on stdout such as "please copy > /etc/glusterd/secret from a server" You're correct that the management path is pretty easy. We have TLS support; we should use it. To facilitate testing, we should ship with a default set of certs/keys. For real use, we should provide a tool to generate new certs/keys on the first machine, which will be propagated to other servers as part of the "peer probe" process. That should be only a minor inconvenience, and drastically reduces our attack surface for the management path. For the I/O path, we run into the problem of managing keys or certificates on many clients, across many platforms. There's probably no solution that provides any respectable degree of security without some inconvenience, but we should probably try to shift away from having *no access control whatsoever* by default. That's only convenient until a hacker comes along. _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://lists.gluster.org/mailman/listinfo/gluster-devel
