HDFS加密存儲，在CSDN上可以看到很多的前輩整理的博客，但是按照https://blog.csdn.net/linlinv3/article/details/44963429所介紹的那樣在我的環境並不能達到預期效果，將自己對hdfs加密的理解和實際操作做一個簡單整理。
首先，hdfs的加密方式爲AES加密，先對AES加密做一個簡單瞭解。
AES算法
對稱加密算法：AES加密算法
下面簡單介紹下各個部分的作用與意義：
密鑰K
用來加密明文的密碼，在對稱加密算法中，加密與解密的密鑰是相同的。密鑰爲接收方與發送方協商產生，但不可以直接在網絡上傳輸，否則會導致密鑰泄漏，通常是通過非對稱加密算法加密密鑰，然後再通過網絡傳輸給對方,實際中，一般是通過RSA加密AES的密鑰，傳輸到接收方，接收方解密得到AES密鑰，然後發送方和接收方用AES密鑰來通信。
或者直接面對面商量密鑰。密鑰是絕對不可以泄漏的，否則會被攻擊者還原密文，竊取機密數據。
AES加密函數
設AES加密函數爲E，則 C = E(K, P),其中P爲明文，K爲密鑰，C爲密文。也就是說，把明文P和密鑰K作爲加密函數的參數輸入，則加密函數E會輸出密文C。
AES解密函數
設AES解密函數爲D，則 P = D(K, C),其中C爲密文，K爲密鑰，P爲明文。也就是說，把密文C和密鑰K作爲解密函數的參數輸入，則解密函數會輸出明文P。
HDFS 透明加密
HDFS Encryption Zone加密空間，即HDFS透明加密，是一種端到端的加密模式，其中的加/解密過程對於客戶端來說是完全透明的。數據在客戶端讀操作的時候被解密，當數據被客戶端寫的時候被加密，所以HDFS服務端本身並不是一個主要的參與者。形象地說，在HDFS服務端，你看到的只是一堆加密的數據流。
這個功能作用就是保證處於加密空間內的數據不被非法查詢，只有經過認證的客戶端才能查看解密內容。
準備知識
Encryption Zone是HDFS中的一個抽象概念，它表示此空間的內容在寫的時候會被透明地加密，同時在讀的時候，被透明地解密；用戶往HDFS上存儲數據的時候，無需用戶做任何程序代碼的更改（意思就是調用KeyProvider API ，用於在數據存入到HDFS上面的時候進行數據加密，解密的過程一樣）。這意味着數據加密和解密由客戶端完成的。HDFS不會存儲或訪問未加密的數據或數據加密密鑰（由KMS管理）。
具體到細節：
- 每個Encryption Zone 會與每個Encryption Zone Key相關聯（EZ Key），這個Key會在創建Encryption Zone的時候同時被指定。
- 每個Encryption Zone中的文件會有其唯一的Data Encryption Key數據加密Key，簡稱就是DEK。
- DEK不會被HDFS直接處理，取而代之的是，HDFS只處理經過加密的DEK，就是Encrypted Data Encryption Key，縮寫就是EDEK。
- 客戶端詢問KMS服務去解密EDEK，然後利用解密後得到的DEK去讀/寫數據。KMS利用存儲的EZ Key來解密EDEK得到DEK。
- 在客戶端向KMS服務請求時候，會有相關權限驗證，不符合要求的客戶端將不會得到解密好的DEK。而且KMS的權限驗證是獨立於HDFS的，是自身的一套權限驗證。
EZKey使用hadoop key命令來創建，DEK使用keytool –genkey來生成。（？待定）
Client向NN（HDFS組件的NameNode服務進程）請求在HDFS某個加密區新建文件；
NN向KMS請求此文件的EDEK，KMS用對應的EZ Key生成一個新的EDEK發送給NN；
NN 發送此EDEK給Client；
Client發送EDEK給KMS請求解密，KMS用對應的EZ Key將EDEK解密爲DEK發送給Client；
Client拿到對應的DEK後對文件進行加密和解密
綜上所述可知：HDFS Server端的進程（NameNode，DataNode）本身並不參與hdfs區域的加密和解密，Namenode所做的事情只是向KMS請求獲取EDEK後將它發送給hdfs client，以便於client將EDEK解密之後，對實際的hdfs區域進行加密與解密，hdfs的加密與解密都只在hdfs client端完成。
HDFS加密測試（Ranger與Ranger KMS）
創建EZKey（此處創建的Key類型待定）
通過ranger快速連接，選擇“Ranger Admin UI”，以keyadmin/keyadmin登錄；點擊Encrytion tab -> 選擇Key Manager； Select Service= 集羣名+ _kms; 點擊Add New Key按鈕，添加key name爲key1的key。
修改hdfs配置，啓用Ranger for hdfs。
通過界面創建hdfs加密區
若此處提示RemoteException，是因爲hdfs被拉進了對應的黑名單，創建如下策略，給hdfs對應的權限，保存即可，請特別注意不要給予解密權限（Decrypt EEK）。
在本地創建文件
Hdfs提示權限問題直接將hdfs對應路徑的權限修改爲777即可。
由以上可知，如果使用者未給對應的用戶賦予Decrypt EEK的權限，對應的用戶是無法往加密區裏面讀或者寫東西的。這一點很好理解，對於別的用戶，即使可以拿到EDEK，但是沒有解密已加密的密鑰的權限，即無法得到真正的密鑰，所以無法對文件進行加密或者解密操作。
加密權限初步驗證
創建本地用戶test。
[root@node1 hdfsencrytest]# useradd test
利用ranger，以keyadmin用戶登錄ranger，點擊aaa_kms，先刪除掉之前爲hdfs分配的policy1，不然後續的policy創建可能不成功。再爲test用戶創建對應的policy。
Test用戶可以進行對加密區的一些列操作，如下所示
查看驗證
用如下命令查看加密區與非加密區域的文件，觀察明文與密文的對比。可見加密區aaa.txt密文顯示，非加密區明文顯示，至此，hdfs加密配置與驗證均完成。
疑問與思考
關於"通過ranger快速連接，選擇“Ranger Admin UI”，以keyadmin/keyadmin登錄；點擊Encrytion tab -> 選擇Key Manager； Select Service= 集羣名+ _kms; 點擊Add New Key按鈕，添加key name爲key1的key"即在Ranger UI裏面創建key1這一步，究竟創建的是EZ key還是DEK？
參考前輩的文章和官網介紹，利用hadoop kms的方式來創建hdfs加密區，都會在命令行利用hadoop key創建一個key，keytool來生成另一個key，Ranger Admin UI實質上只是把hadoop key -create的操作接口放到了前端。這裏hadoop key create到底生成的是哪一個key？我在之前的文本中寫生成了EZ key，其實並不見得如此。因爲通過Ranger KMS（Apache對hadoop kms的封裝，hadoop kms將密鑰存儲在文件中，Ranger KMS將密鑰存儲在安全數據庫中，且提供可視化界面）只進行了一次生成key的操作。假設我們在UI生成的是EZ key，則意味着實際用於加解密數據的DEK是KMS默認生成的，那麼如果用戶對實際加密和解密的密鑰長度與算法有要求，該怎麼處理？
看了一些人寫的KMS文檔，把我搞得有點迷糊，無奈之下只好用Navicat打開PostGres數據庫查看數據庫中存放的密鑰。rangerkms庫下有ranger_keystore和ranger_masterkey兩張表，其中在keystore中，自己創建的key1赫然在列，而masterkey（EZ key）表中，是一個長度爲256的非用戶創建的密鑰。於是由此推測，UI創建的是DEK。以上推測暫時也不確定，如有人對此部分比較瞭解，希望能批評指正，謝謝。
參考：
https://blog.csdn.net/qq_35440040/article/details/78780473