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

[Jeff Darcy]

>             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.