<li><ahref="#Rogue_user_exploits">Rogue user exploits</a></li></ul></li></ul>
<section>
<h2><aname="Overview"></a>Overview</h2>
<p>HDFS implements <i>transparent</i>, <i>end-to-end</i> encryption. Once configured, data read from and written to special HDFS directories is <i>transparently</i> encrypted and decrypted without requiring changes to user application code. This encryption is also <i>end-to-end</i>, which means the data can only be encrypted and decrypted by the client. HDFS never stores or has access to unencrypted data or unencrypted data encryption keys. This satisfies two typical requirements for encryption: <i>at-rest encryption</i> (meaning data on persistent media, such as a disk) as well as <i>in-transit encryption</i> (e.g. when data is travelling over the network).</p></section><section>
<h2><aname="Background"></a>Background</h2>
<p>Encryption can be done at different layers in a traditional data management software/hardware stack. Choosing to encrypt at a given layer comes with different advantages and disadvantages.</p>
<ul>
<li>
<p><b>Application-level encryption</b>. This is the most secure and most flexible approach. The application has ultimate control over what is encrypted and can precisely reflect the requirements of the user. However, writing applications to do this is hard. This is also not an option for customers of existing applications that do not support encryption.</p>
</li>
<li>
<p><b>Database-level encryption</b>. Similar to application-level encryption in terms of its properties. Most database vendors offer some form of encryption. However, there can be performance issues. One example is that indexes cannot be encrypted.</p>
</li>
<li>
<p><b>Filesystem-level encryption</b>. This option offers high performance, application transparency, and is typically easy to deploy. However, it is unable to model some application-level policies. For instance, multi-tenant applications might want to encrypt based on the end user. A database might want different encryption settings for each column stored within a single file.</p>
</li>
<li>
<p><b>Disk-level encryption</b>. Easy to deploy and high performance, but also quite inflexible. Only really protects against physical theft.</p>
</li>
</ul>
<p>HDFS-level encryption fits between database-level and filesystem-level encryption in this stack. This has a lot of positive effects. HDFS encryption is able to provide good performance and existing Hadoop applications are able to run transparently on encrypted data. HDFS also has more context than traditional filesystems when it comes to making policy decisions.</p>
<p>HDFS-level encryption also prevents attacks at the filesystem-level and below (so-called “OS-level attacks”). The operating system and disk only interact with encrypted bytes, since the data is already encrypted by HDFS.</p></section><section>
<h2><aname="Use_Cases"></a>Use Cases</h2>
<p>Data encryption is required by a number of different government, financial, and regulatory entities. For example, the health-care industry has HIPAA regulations, the card payment industry has PCI DSS regulations, and the US government has FISMA regulations. Having transparent encryption built into HDFS makes it easier for organizations to comply with these regulations.</p>
<p>Encryption can also be performed at the application-level, but by integrating it into HDFS, existing applications can operate on encrypted data without changes. This integrated architecture implies stronger encrypted file semantics and better coordination with other HDFS functions.</p></section><section>
<p>For transparent encryption, we introduce a new abstraction to HDFS: the <i>encryption zone</i>. An encryption zone is a special directory whose contents will be transparently encrypted upon write and transparently decrypted upon read. Each encryption zone is associated with a single <i>encryption zone key</i> which is specified when the zone is created. Each file within an encryption zone has its own unique <i>data encryption key (DEK)</i>. DEKs are never handled directly by HDFS. Instead, HDFS only ever handles an <i>encrypted data encryption key (EDEK)</i>. Clients decrypt an EDEK, and then use the subsequent DEK to read and write data. HDFS datanodes simply see a stream of encrypted bytes.</p>
<p>A very important use case of encryption is to “switch it on” and ensure all files across the entire filesystem are encrypted. To support this strong guarantee without losing the flexibility of using different encryption zone keys in different parts of the filesystem, HDFS allows <i>nested encryption zones</i>. After an encryption zone is created (e.g. on the root directory <code>/</code>), a user can create more encryption zones on its descendant directories (e.g. <code>/home/alice</code>) with different keys. The EDEK of a file will generated using the encryption zone key from the closest ancestor encryption zone.</p>
<p>A new cluster service is required to manage encryption keys: the Hadoop Key Management Server (KMS). In the context of HDFS encryption, the KMS performs three basic responsibilities:</p>
<olstyle="list-style-type: decimal">
<li>
<p>Providing access to stored encryption zone keys</p>
</li>
<li>
<p>Generating new encrypted data encryption keys for storage on the NameNode</p>
</li>
<li>
<p>Decrypting encrypted data encryption keys for use by HDFS clients</p>
</li>
</ol>
<p>The KMS will be described in more detail below.</p></section><section>
<h3><aname="Accessing_data_within_an_encryption_zone"></a>Accessing data within an encryption zone</h3>
<p>When creating a new file in an encryption zone, the NameNode asks the KMS to generate a new EDEK encrypted with the encryption zone’s key. The EDEK is then stored persistently as part of the file’s metadata on the NameNode.</p>
<p>When reading a file within an encryption zone, the NameNode provides the client with the file’s EDEK and the encryption zone key version used to encrypt the EDEK. The client then asks the KMS to decrypt the EDEK, which involves checking that the client has permission to access the encryption zone key version. Assuming that is successful, the client uses the DEK to decrypt the file’s contents.</p>
<p>All of the above steps for the read and write path happen automatically through interactions between the DFSClient, the NameNode, and the KMS.</p>
<p>Access to encrypted file data and metadata is controlled by normal HDFS filesystem permissions. This means that if HDFS is compromised (for example, by gaining unauthorized access to an HDFS superuser account), a malicious user only gains access to ciphertext and encrypted keys. However, since access to encryption zone keys is controlled by a separate set of permissions on the KMS and key store, this does not pose a security threat.</p></section><section>
<p>The KMS is a proxy that interfaces with a backing key store on behalf of HDFS daemons and clients. Both the backing key store and the KMS implement the Hadoop KeyProvider API. See the <ahref="../../hadoop-kms/index.html">KMS documentation</a> for more information.</p>
<p>In the KeyProvider API, each encryption key has a unique <i>key name</i>. Because keys can be rolled, a key can have multiple <i>key versions</i>, where each key version has its own <i>key material</i> (the actual secret bytes used during encryption and decryption). An encryption key can be fetched by either its key name, returning the latest version of the key, or by a specific key version.</p>
<p>The KMS implements additional functionality which enables creation and decryption of <i>encrypted encryption keys (EEKs)</i>. Creation and decryption of EEKs happens entirely on the KMS. Importantly, the client requesting creation or decryption of an EEK never handles the EEK’s encryption key. To create a new EEK, the KMS generates a new random key, encrypts it with the specified key, and returns the EEK to the client. To decrypt an EEK, the KMS checks that the user has access to the encryption key, uses it to decrypt the EEK, and returns the decrypted encryption key.</p>
<p>In the context of HDFS encryption, EEKs are <i>encrypted data encryption keys (EDEKs)</i>, where a <i>data encryption key (DEK)</i> is what is used to encrypt and decrypt file data. Typically, the key store is configured to only allow end users access to the keys used to encrypt DEKs. This means that EDEKs can be safely stored and handled by HDFS, since the HDFS user will not have access to unencrypted encryption keys.</p></section></section><section>
<h2><aname="Configuration"></a>Configuration</h2>
<p>A necessary prerequisite is an instance of the KMS, as well as a backing key store for the KMS. See the <ahref="../../hadoop-kms/index.html">KMS documentation</a> for more information.</p>
<p>Once a KMS has been set up and the NameNode and HDFS clients have been correctly configured, an admin can use the <code>hadoop key</code> and <code>hdfs crypto</code> command-line tools to create encryption keys and set up new encryption zones. Existing data can be encrypted by copying it into the new encryption zones using tools like distcp.</p><section>
<h3><aname="Configuring_the_cluster_KeyProvider"></a>Configuring the cluster KeyProvider</h3><section>
<p>The KeyProvider to use when interacting with encryption keys used when reading and writing to an encryption zone. HDFS clients will use the provider path returned from Namenode via getServerDefaults. If namenode doesn’t support returning key provider uri then client’s conf will be used.</p></section></section><section>
<h3><aname="Selecting_an_encryption_algorithm_and_codec"></a>Selecting an encryption algorithm and codec</h3><section>
<p>The prefix for a given crypto codec, contains a comma-separated list of implementation classes for a given crypto codec (eg EXAMPLECIPHERSUITE). The first implementation will be used if available, others are fallbacks.</p></section><section>
<p>Comma-separated list of crypto codec implementations for AES/CTR/NoPadding. The first implementation will be used if available, others are fallbacks.</p></section><section>
<p>Comma-separated list of crypto codec implementations for SM4/CTR/NoPadding. The first implementation will be used if available, others are fallbacks.</p></section><section>
<p>When listing encryption zones, the maximum number of zones that will be returned in a batch. Fetching the list incrementally in batches improves namenode performance.</p></section></section></section><section>
<p>Get encryption information from a file. This can be used to find out whether a file is being encrypted, and the key name / key version used to encrypt it.</p>
<tableborder="0"class="bodyTable">
<thead>
<trclass="a">
<thalign="left"></th>
<thalign="left"></th></tr>
</thead><tbody>
<trclass="b">
<tdalign="left"><i>path</i></td>
<tdalign="left"> The path of the file to get encryption information. </td></tr>
<p>Re-encrypts an encryption zone, by iterating through the encryption zone, and calling the KeyProvider’s reencryptEncryptedKeys interface to batch-re-encrypt all files’ EDEKs with the latest version encryption zone key in the key provider. Requires superuser permissions.</p>
<p>Note that re-encryption does not apply to snapshots, due to snapshots’ immutable nature.</p>
<tableborder="0"class="bodyTable">
<thead>
<trclass="a">
<thalign="left"></th>
<thalign="left"></th></tr>
</thead><tbody>
<trclass="b">
<tdalign="left"><i>action</i></td>
<tdalign="left"> The re-encrypt action to perform. Must be either <code>-start</code> or <code>-cancel</code>. </td></tr>
<trclass="a">
<tdalign="left"><i>path</i></td>
<tdalign="left"> The path to the root of the encryption zone. </td></tr>
</tbody>
</table>
<p>Re-encryption is a NameNode-only operation in HDFS, so could potentially put intensive load to the NameNode. The following configurations can be changed to control the stress on the NameNode, depending on the acceptable throughput impact to the cluster.</p>
<tdalign="left"> The number of EDEKs in a batch to be sent to the KMS for re-encryption. Each batch is processed when holding the name system read/write lock, with throttling happening between batches. See configs below. </td></tr>
<tdalign="left"> Ratio of read locks to be held during re-encryption. 1.0 means no throttling. 0.5 means re-encryption can hold the readlock at most 50% of its total processing time. Negative value or 0 are invalid. </td></tr>
<tdalign="left"> Ratio of write locks to be held during re-encryption. 1.0 means no throttling. 0.5 means re-encryption can hold the writelock at most 50% of its total processing time. Negative value or 0 are invalid. </td></tr>
<p>List re-encryption information for all encryption zones. Requires superuser permissions.</p></section></section><section>
<h2><aname="Example_usage"></a>Example usage</h2>
<p>These instructions assume that you are running as the normal user or HDFS superuser as is appropriate. Use <code>sudo</code> as needed for your environment.</p>
<divclass="source">
<divclass="source">
<pre># As the normal user, create a new encryption key
hadoop key create mykey
# As the super user, create a new empty directory and make it an encryption zone
<h3><aname="Running_as_the_superuser"></a>Running as the superuser</h3>
<p>One common usecase for distcp is to replicate data between clusters for backup and disaster recovery purposes. This is typically performed by the cluster administrator, who is an HDFS superuser.</p>
<p>To enable this same workflow when using HDFS encryption, we introduced a new virtual path prefix, <code>/.reserved/raw/</code>, that gives superusers direct access to the underlying block data in the filesystem. This allows superusers to distcp data without needing having access to encryption keys, and also avoids the overhead of decrypting and re-encrypting data. It also means the source and destination data will be byte-for-byte identical, which would not be true if the data was being re-encrypted with a new EDEK.</p>
<p>When using <code>/.reserved/raw</code> to distcp encrypted data, it’s important to preserve extended attributes with the <ahref="../../hadoop-distcp/DistCp.html#Command_Line_Options">-px</a> flag. This is because encrypted file attributes (such as the EDEK) are exposed through extended attributes within <code>/.reserved/raw</code>, and must be preserved to be able to decrypt the file. This means that if the distcp is initiated at or above the encryption zone root, it will automatically create an encryption zone at the destination if it does not already exist. However, it’s still recommended that the admin first create identical encryption zones on the destination cluster to avoid any potential mishaps.</p></section><section>
<h3><aname="Copying_into_encrypted_locations"></a>Copying into encrypted locations</h3>
<p>By default, distcp compares checksums provided by the filesystem to verify that the data was successfully copied to the destination. When copying from unencrypted or encrypted location into an encrypted location, the filesystem checksums will not match since the underlying block data is different because a new EDEK will be used to encrypt at destination. In this case, specify the <ahref="../../hadoop-distcp/DistCp.html#Command_Line_Options">-skipcrccheck</a> and <ahref="../../hadoop-distcp/DistCp.html#Command_Line_Options">-update</a> distcp flags to avoid verifying checksums.</p></section></section><section>
<h2><aname="Rename_and_Trash_considerations"></a>Rename and Trash considerations</h2>
<p>HDFS restricts file and directory renames across encryption zone boundaries. This includes renaming an encrypted file / directory into an unencrypted directory (e.g., <code>hdfs dfs mv /zone/encryptedFile /home/bob</code>), renaming an unencrypted file or directory into an encryption zone (e.g., <code>hdfs dfs mv /home/bob/unEncryptedFile /zone</code>), and renaming between two different encryption zones (e.g., <code>hdfs dfs mv /home/alice/zone1/foo /home/alice/zone2</code>). In these examples, <code>/zone</code>, <code>/home/alice/zone1</code>, and <code>/home/alice/zone2</code> are encryption zones, while <code>/home/bob</code> is not. A rename is only allowed if the source and destination paths are in the same encryption zone, or both paths are unencrypted (not in any encryption zone).</p>
<p>This restriction enhances security and eases system management significantly. All file EDEKs under an encryption zone are encrypted with the encryption zone key. Therefore, if the encryption zone key is compromised, it is important to identify all vulnerable files and re-encrypt them. This is fundamentally difficult if a file initially created in an encryption zone can be renamed to an arbitrary location in the filesystem.</p>
<p>To comply with the above rule, each encryption zone has its own <code>.Trash</code> directory under the “zone directory”. E.g., after <code>hdfs dfs rm /zone/encryptedFile</code>, <code>encryptedFile</code> will be moved to <code>/zone/.Trash</code>, instead of the <code>.Trash</code> directory under the user’s home directory. When the entire encryption zone is deleted, the “zone directory” will be moved to the <code>.Trash</code> directory under the user’s home directory.</p>
<p>If the encryption zone is the root directory (e.g., <code>/</code> directory), the trash path of root directory is <code>/.Trash</code>, not the <code>.Trash</code> directory under the user’s home directory, and the behavior of renaming sub-directories or sub-files in root directory will keep consistent with the behavior in a general encryption zone, such as <code>/zone</code> which is mentioned at the top of this section.</p>
<p>The <code>crypto</code> command before Hadoop 2.8.0 does not provision the <code>.Trash</code> directory automatically. If an encryption zone is created before Hadoop 2.8.0, and then the cluster is upgraded to Hadoop 2.8.0 or above, the trash directory can be provisioned using <code>-provisionTrash</code> option (e.g., <code>hdfs crypto -provisionTrash -path /zone</code>).</p></section><section>
<p>These exploits assume that attacker has gained root shell access to cluster machines, i.e. datanodes and namenodes. Many of these exploits cannot be addressed in HDFS, since a malicious root user has access to the in-memory state of processes holding encryption keys and cleartext. For these exploits, the only mitigation technique is carefully restricting and monitoring root shell access.</p>
<olstyle="list-style-type: decimal">
<li>
<p>Access to encrypted block files.</p>
<ul>
<li>By itself, this does not expose cleartext, as it also requires access to encryption keys.</li>
</ul>
</li>
<li>
<p>Dump memory of client processes to obtain DEKs, delegation tokens, cleartext.</p>
<ul>
<li>No mitigation.</li>
</ul>
</li>
<li>
<p>Recording network traffic to sniff encryption keys and encrypted data in transit.</p>
<ul>
<li>By itself, insufficient to read cleartext without the EDEK encryption key.</li>
</ul>
</li>
<li>
<p>Dump memory of datanode process to obtain encrypted block data.</p>
<ul>
<li>By itself, insufficient to read cleartext without the DEK.</li>
</ul>
</li>
<li>
<p>Dump memory of namenode process to obtain encrypted data encryption keys.</p>
<ul>
<li>By itself, insufficient to read cleartext without the EDEK’s encryption key and encrypted block files.</li>
<p>These exploits assume that the attacker has compromised HDFS, but does not have root or <code>hdfs</code> user shell access.</p>
<olstyle="list-style-type: decimal">
<li>
<p>Access to encrypted block files.</p>
<ul>
<li>By itself, insufficient to read cleartext without the EDEK and EDEK encryption key.</li>
</ul>
</li>
<li>
<p>Access to encryption zone and encrypted file metadata (including encrypted data encryption keys), via -fetchImage.</p>
<ul>
<li>By itself, insufficient to read cleartext without EDEK encryption keys.</li>
</ul>
</li>
</ol></section><section>
<h3><aname="Rogue_user_exploits"></a>Rogue user exploits</h3>
<p>A rogue user can collect keys of files they have access to, and use them later to decrypt the encrypted data of those files. As the user had access to those files, they already had access to the file contents. This can be mitigated through periodic key rolling policies. The <ahref="#reencryptZone">reencryptZone</a> command is usually required after key rolling, to make sure the EDEKs on existing files use the new version key.</p>
<p>Manual steps to a complete key rolling and re-encryption are listed below. These instructions assume that you are running as the key admin or HDFS superuser as is appropriate.</p>
<divclass="source">
<divclass="source">
<pre># As the key admin, roll the key to a new version
hadoop key roll exposedKey
# As the super user, re-encrypt the encryption zone. Possibly list zones first.
hdfs crypto -listZones
hdfs crypto -reencryptZone -start -path /zone
# As the super user, periodically check the status of re-encryption
hdfs crypto -listReencryptionStatus
# As the super user, get encryption information from the file and double check it's encryption key version
