[Gluster-users] [Gluster-devel] Transparent encryption in GlusterFS: Implications on manageability

[Anand Avati]

+1 for all the points.


On Wed, Aug 13, 2014 at 11:22 AM, Jeff Darcy <jdarcy at redhat.com> wrote:

> >             I.1 Generating the master volume key
> >
> >
> > Master volume key should be generated by user on the trusted machine.
> > Recommendations on master key generation provided at section 6.2 of
> > the manpages [1]. Generating of master volume key is in user's
> > competence.
>
> That was fine for an initial implementation, but it's still the single
> largest obstacle to adoption of this feature.  Looking forward, we need
> to provide full CLI support for generating keys in the necessary format,
> specifying their location, etc.
>
> >            I.2 Location of the master volume key when mounting a
> >            volume
> >
> >
> > At mount time the crypt translator searches for a master volume key on
> > the client machine at the location specified by the respective
> > translator option. If there is no any key at the specified location,
> > or the key at specified location is in improper format, then mount
> > will fail. Otherwise, the crypt translator loads the key to its
> > private memory data structures.
> >
> > Location of the master volume key can be specified at volume creation
> > time (see option "master-key", section 6.7 of the man pages [1]).
> > However, this option can be overridden by user at mount time to
> > specify another location, see section 7 of manpages [1], steps 6, 7,
> > 8.
>
> Again, we need to improve on this.  We should support this as a volume
> or mount option in its own right, not rely on the generic
> --xlator-option mechanism.  Adding options to mount.glusterfs isn't
> hard.  Alternatively, we could make this look like a volume option
> settable once through the CLI, even though the path is stored locally on
> the client.  Or we could provide a separate special-purpose
> command/script, which again only needs to be run once.  It would even be
> acceptable to treat the path to the key file (not its contents!) as a
> true volume option, stored on the servers.  Any of these would be better
> than requiring the user to understand our volfile format and
> construction so that they can add the necessary option by hand.
>
> >                II. Check graph of translators on your client machine
> >                after mount!
> >
> >
> > During mount your client machine receives configuration info from the
> > non-trusted server. In particular, this info contains the graph of
> > translators, which can be subjected to tampering, so that encryption
> > won't be invoked for your volume at all. So it is highly important to
> > verify this graph. After successful mount make sure that the graph of
> > translators contains the crypt translator with proper options (see
> > FAQ#1, section 11 of the manpages [1]).
>
> It is important to verify the graph, but not by poking through log files
> and not without more information about what to look for.  So we got a
> volfile that includes the crypt translator, with some options.  The
> *code* should ensure that the master-key option has the value from the
> command line or local config, and not some other.  If we have to add
> special support for this in otherwise-generic graph initialization code,
> that's fine.
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at gluster.org
> http://supercolony.gluster.org/mailman/listinfo/gluster-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-users/attachments/20140813/57dc0ac3/attachment.html>