Bug 880241 - Basic security for glusterd
Basic security for glusterd
Status: CLOSED EOL
Product: GlusterFS
Classification: Community
Component: glusterd (Show other bugs)
mainline
Unspecified Unspecified
high Severity high
: ---
: ---
Assigned To: bugs@gluster.org
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-11-26 09:59 EST by Jeff Darcy
Modified: 2015-10-22 11:46 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-10-22 11:46:38 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jeff Darcy 2012-11-26 09:59:14 EST
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.
Comment 1 Amar Tumballi 2013-01-07 05:40:38 EST
Even though, not having proper security policy is 'bug', would like to call it as Feature Future, as there is surely 'enhancement' like work involved for this.
Comment 2 Kaleb KEITHLEY 2015-10-22 11:46:38 EDT
because of the large number of bugs filed against mainline version\ is ambiguous and about to be removed as a choice.

If you believe this is still a bug, please change the status back to NEW and choose the appropriate, applicable version for it.

Note You need to log in before you can comment on or make changes to this bug.