hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Arun Suresh <asur...@apache.org>
Subject Re: Key Rotation in Data-at-Rest Encryption
Date Sun, 14 Jun 2015 07:23:46 GMT
Apologize if I wasn't clear

> Is the EZ key version same as an alias for the key?
yup

> the EDEK along with the EZ key version is stored in the FIleInfo
FileInfo contains both EDEK and EZ key version. The FileInfo (you can look
at the *org.apache.hadoop.fs.FileEncryptionInfo* class for more info)
object is stored as the value of the extended attribute of that file.

> How is the KeyMaterial derived from the KeyAlias and where is the mapping between
the two stored? Is it in the KMS?
Yup. KMS extends the *org.apache.hadoop.crypto.key.KeyProvider* class. You
can take a look at it or a concrete implementation such as
JavaKeyStoreProvider for more information.

Also, you should probably direct questions related to HDFS encryption to
hdfs-dev@hadoop.apache.org

Cheers
-Arun



On Sun, Jun 14, 2015 at 12:11 AM, Sitaraman Vilayannur <
vrsitaramanietflists@gmail.com> wrote:

> Hi Arun,
> Thanks for your response.
> Could you explain this a bit further for me....
> Is the EZ key version same as an alias for the key?
> The EDEK is stored in the extended attributes of the file and the EZkey
> Version is stored
>  in the FileInfo  why is the EZKey Version not stored in the extended
> attributes too.
> Where is the FileInfo object persisted? Is it in the NameNode?
> How is the KeyMaterial derived from the KeyAlias and where is the mapping
> between the two stored? Is it in the KMS?
> Thanks much for your help in this.
> Sitaraman
>
> On Sun, Jun 14, 2015 at 12:14 PM, Arun Suresh <asuresh@cloudera.com>
> wrote:
>
> > Hello Sitaraman,
> >
> > It is the EZ key "version" that is used to generate the EDEK (and which
> is
> > ultimately stored in the encrypted file's extended attributes
> > '*raw.hdfs.crypto.encryption.info
> > <http://raw.hdfs.crypto.encryption.info>*'), not really the the EZ key
> > itself (which is stored in the directory's extended attribute ‘
> > *raw.hdfs.crypto.encryption.zone*’).
> >
> > Essentially, each file in a directory has a unique EDEK.. and an EDEK is
> is
> > generated with the current version of the directory EZ key. The EDEK
> along
> > with the EZ key version is stored in the FIleInfo. While decrypting, both
> > these are passed on to the KMS which provides the client with the DEK
> which
> > can be used to decrypt the file.
> >
> > Hope this clarifies things.
> >
> > Cheers
> > -Arun
> >
> > On Sat, Jun 13, 2015 at 9:51 PM, Sitaraman Vilayannur <
> > vrsitaramanietflists@gmail.com> wrote:
> >
> > > HDFSDataatRestEncryption.pdf says the following about key
> > rotation..(please
> > > see appended below at the end of the mail)
> > > If the existing files do not have their EDEKs reencrypted using the new
> > > ezkeyid, how would the existing files be decrypted? That is where is
> the
> > > mapping between files and its EZKey (for after key rotation different
> > files
> > > have different EZKeys)ids stored and how is it retrieved?
> > > Thanks
> > > Sitaraman
> > >
> > > Key Rotation
> > > When the administrator causes a key rotation of the EZkey
> > > in the KMS, the encryption zone’s EZkey
> > > (stored in the encryption zone directory’s
> > raw.hdfs.crypto.encryption.zone
> > > extended attribute) gets the new keyid and version (only the version
> > > changes). Any new files
> > > created in the encryption zone have their DEKs encrypted using the new
> > key
> > > version. Existing
> > > files do not have their EDEKs reencrypted using the new ezkeyid/
> > > version, but this will be considered as a future enhancement. Note
> that a
> > > key rotation only needs to causes a reencryption of the DEK, not a
> > > reencryption of the underlying file.
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message