This started with the discussion on http://review.gluster.org/#change,4231 which proposes a new use of the gluster CLI from non-servers.  I also have some scripts that use the same --remote-host hook.  The problem is that glusterd is still utterly, totally, trusting.  Anyone who can connect to the port can issue any command, including those that are often hard to recover from even when used properly.  Relying on firewalls to block access to the glusterd port is just too weak to consider, and allowed-host lists aren't much better (especially without any reasonable way to manage either).  We don't need full role-based access control, but we do need *some* reasonable login-level control.

Our two main options are SSL and username/password.  Both exist at the transport layer, though SSL currently only does authentication without authorization so something like http://review.gluster.org/#change,3695 would be necessary.  Either way, the servers can be pre-provisioned with the right credentials (e.g. propagated as part of the "peer probe" process) so they wouldn't notice anything different when communicating among themselves.  All we really need is some way to extend those credentials to another trusted machine that isn't a server, and possibly some way to modify the passwords/certificates.

NB: This is not the same as bug 765359, which has to do with *local* CLI access.  Obviously they're related, though.  This one's almost a superset, in the sense that if we resolve this then we pretty much automatically resolve the other as well.