Cloudera Docs

Re-encrypting an EDEK

This scenario operates on the assumption that an encryption zone has already been set up for this cluster.

  1. Navigate to the cluster in which you will be rolling keys and re-encrypting the EDEK.
  2. Log in as HDFS Superuser.
  3. Optional: View all of the options for the hdfs crypto command: 
    $ hdfs crypto
[-createZone –keyName <keyName> -path <path>]
[-listZones]
[-provisionTrash –path <path>]
[-getFileEncryptionInfo –path <path>]
[-reencryptZone <action> -path <zone>]
[-listReencryptionStatus]
[-help <command-name>]
  4. Before rolling any keys, verify/identify the encryption zones to which the current key applies.
    This operation also helps clarify the relationship between the EZ key and encryption zones, and, if necessary, makes it easier to identify more important, high priority zones.
    $ hdfs crypto –listZones
/ez     key1

    The first column identifies the encryption zone path (/ez); the second column identifies the encryption key name (key1).

  5. Exit from the HDFS Superuser account and log in as Key Administrator.
  6. Roll the encryption key (previously identified/confirmed by the HDFS Superuser in step 4).
    Here, the <key name> is key1
    hadoop key roll key1
    This operation contacts the KMS and rolls the keys. Note that this can take a considerable amount of time, depending on the number of key versions. 
    Rolling key version from KeyProvider: org.apache.hadoop.crypto.key.kms.LoadBalancingKMSClientProvider@5ea434c8
for keyName: key1
key1 has been successfully rolled.
org.apache.hadoop.crypto.key.kms.LoadBalancingKMSClientProvider@5ea434c8 has been updated.
  7. Log out as Key Administrator, and log in as HDFS Superuser.
  8. Optional: Before performing the re-encryption, you can verify the status of the current key version being used (keyName).
    Then, after re-encrypting, you can confirm that the EZ key version (ezKeyVersionName) and EDEK have changed.
    $ hdfs crypto –getFileEncryptionInfo –path /ez/f
{cipherSuite: {name: AES/CTR/NoPadding, algorithmBlockSize: 16}. cryptoProtocolVersion:
CryptoProtocolVersion{description=’Encryption zones’, version=2, unknownValue=null}, edek: 9aa13ea4a700f96287cfe1349f6ff4f2,
iv: d129c913c8a34cde6371ec95edfb7337, keyName: key1, ezKeyVersionName: 7mbvopZ0Weuvs0XtTkpGw3G92KuWc4e4xcTXl0bXCpF}
  9. After the EZ key has been rolled successfully, re-encrypt the EDEK by running the re-encryption command on the encryption zone: 
    $ hdfs crypto –reencryptZone –start –path /ez
    The following information appears when the submission is complete. At this point, the NameNode is processing and re-encrypting all of the EDEKs under the /ez directory.
    re-encrypt command successfully submitted for zone: /ez action:  START:
    Depending on the number of files, the re-encryption operation can take a long time. Re-encrypting a 1M EDEK file typically takes between 2-6 minutes, depending on the NameNode hardware. To check the status of the re-encryption for the zone:
    hdfs crypto –listReencryptionStatus
    Column Name Description Sample Data
    ZoneName The encryption zone name /ez
    Status
    • Submitted: the command is received, but not yet being processed by the NameNode.
    • Processing: the zone is being processed by the NameNode.
    • Completed: the NameNode has finished processing the zone, and every file in the zone has been re-encrypted.
    		 Completed
    EZKey Version Name The encryption zone key version name, which used for re-encryption comparison. After re-encryption is complete, all files in the encryption zone are guaranteed to have an EDEK whose encryption zone key version is at least equal to this version. ZMHfRoGKeXXgf0QzCX8q16NczIw2sq0rWRTOHS3YjCz
    Submission Time The time at which the re-encryption operation commenced. 2017-09-07 10:01:09,262-0700
    Is Canceled? True: the encryption operation has been canceled.

    False: the encryption operation has not been canceled.

    		 False
    Completion Time The time at which the re-encryption operation completed. 2017-09-07 10:01:10,441-0700
    Number of files re-encrypted The number that appears in this column reflects only the files whose EDEKs have been updated. If a file is created after the key is rolled, then it will already have an EDEK that has been encrypted by the new key version, so the re-encryption operation will skip that file. In other words, it's possible for a "Completed" re-encryption to reflect a number of re-encrypted files that is less than the number of files actually in the encryption zone.

    Note: In cases when you re-encrypt an EZ key that has already been re-encrypted and there are no new files, the number of files re-encrypted will be 0.

    		 1
    Number of failures When 0, no errors occurred during the re-encryption operation. If larger than 0, then investigate the NameNode log, and re-encrypt. 0
    Last file Checkpointed Identifies the current position of the re-encryption process in the encryption zone--in other words, the file that was most recently re-encrypted. 0
  10. After the re-encryption completes, you can confirm that the EDEK and EZ Key Version Name values have changed. 
    $ hdfs crypto –getFileEncryptionInfo –path /ez/f
{cipherSuite: {name: AES/CTR/NoPadding, algorithmBlockSize: 16}. cryptoProtocolVersion:
CryptoProtocolVersion{description=’Encryption zones’, version=2, unknownValue=null}, edek: 373c0c2e919c27e58c1c343f54233cbd,
iv: d129c913c8a34cde6371ec95edfb7337, keyName: key1, ezKeyVersionName: ZMHfRoGKeXXgf0QzCX8q16NczIw2sq0rWRTOHS3YjCz }