十三:Transparent Encryption in HDFS(轉)
阿新 • • 發佈:2017-08-31
存儲 oop with combined 生成器 spn prop password and 透明加密:http://blog.csdn.net/linlinv3/article/details/44963429
簡介 Hadoop Key Management Server(KMS)是一個基於HadoopKeyProvider API編寫的密鑰管理服務器。他提供了一個client和一個server組件,client和server之間基於HTTP協議使用REST API通信。Client是一個KeyProvider的實現,使用KMS HTTP REST API與KMS交互。KMS和它的client有內置的安全機制,支持HTTP SPNEGO Kerberos認證和HTTPS安全傳輸。KMS是一個Java Web應用程序,運行在與Hadoop發行版綁定在一起的預先配置好的Tomcat服務器上。
HDFS 實現透明,端到端加密。配置完成後,用戶往hdfs上存儲數據的時候,無需用戶做任何程序代碼的更改(意思就是調用KeyProvider API ,用於在數據存入到HDFS上面的時候進行數據加密,解密的過程一樣)。這意味著數據加密和解密由客戶端完成的。HDFS 不會存儲或訪問未加密的數據或數據加密密鑰(由kms管理)。
連接地址: http://archive.cloudera.com/cdh5/cdh/5/hadoop/hadoop-project-dist/hadoop-hdfs/TransparentEncryption.html http://hadoop.apache.org/docs/r2.6.0/hadoop-kms/index.html
轉載請註明出處 http://blog.csdn.net/linlinv3/article/details/44963429
背景介紹 越來越多的用戶關註安全問題,都在尋找一種有效的,方便的加密方式。hadoop提供了幾種不同形式的加密,最底層的加密,加密所有節點數據,有效地保護了數據,但是卻缺乏更細粒度的加密;
kms 透明加密可以做到更細粒度的加密; 加密可以在不同的層級進行,包括軟件/軟件堆棧,選擇不同的加密層級各有優缺點
體系結構 Kms 有一個加密區 這個特殊的區域 對於能夠進行操作他的用戶 提供有寫入和讀取的權限。當加密區被創建的時候,每個加密區有唯一的秘鑰, data encryption key (DEK),秘鑰dek不由hdfs直接控制,但是hdfs控制encrypted data encryption key (EDEK),被加密的秘鑰;由客戶端解密EDEK;
kms server kms 服務器
kms client kms 客戶端
kms zone kms 加密區
配置
kms 配置
kms server配置
kms-site.xml 文件配置
1、kms backed keyProvider keyProvider 存儲地方的配置Configure the KMS backing KeyProvider properties in the etc/hadoop/kms-site.xml configuration file:
配置kms keyProvider存儲的地方
keytool -genkey -alias ‘key1‘; keytool -delete -alias ‘key1‘;
2、kms cache kms 緩存配置The cache is used with the following 3 methods only, getCurrentKey() and getKeyVersion() and getMetadata().配置緩沖區,這樣的話,當獲取 getCurrentKey() and getKeyVersion() and getMetadata() 的時候 不用每次去訪問 keystore 只用從緩存中讀取就可以。當然,秘鑰更新或者被刪除的時候,會自動更新。
配置聚合日誌,將會對 (user,key,operation) 一樣的操作進行合並輸出,減少日誌流量
kms-ent.sh 配置
kms 客戶端配置
kms-site.xml 配置如下參數
創建key
創建加密區
實驗結果:
用 casliyang用戶 在加密區上傳文件: hdfs dfs -copyFromLocal /home/casliyang/read.log /zone1/web.log 下載文件 hdfs dfs -copyToLocal /zone1/web.log /home/casliyang/3.log
都可以成功
用hadoop220用戶 在加密區上上傳或者下載或者查看均失敗,提示沒有權限
補充說明:1、kms 啟動時候報錯,說找不到加密文件此處的加密文件可以是java自動生成的keystore 使用java keytool命令
首先檢查 是否kms已經啟動,若 kms 確實沒有啟動起來,這時候需要到 根目錄root下的 temp文件夾 手動刪除 kms.pid 然後再次啟動kms
3、加密區建立成功後,任何用戶都能進行訪問等一系列操作
4、加密文件的原始隱藏路徑 :
來自為知筆記(Wiz)
hadoop透明加密 kms
簡介 Hadoop Key Management Server(KMS)是一個基於HadoopKeyProvider API編寫的密鑰管理服務器。他提供了一個client和一個server組件,client和server之間基於HTTP協議使用REST API通信。Client是一個KeyProvider的實現,使用KMS HTTP REST API與KMS交互。KMS和它的client有內置的安全機制,支持HTTP SPNEGO Kerberos認證和HTTPS安全傳輸。KMS是一個Java Web應用程序,運行在與Hadoop發行版綁定在一起的預先配置好的Tomcat服務器上。
HDFS 實現透明,端到端加密。配置完成後,用戶往hdfs上存儲數據的時候,無需用戶做任何程序代碼的更改(意思就是調用KeyProvider API ,用於在數據存入到HDFS上面的時候進行數據加密,解密的過程一樣)。這意味著數據加密和解密由客戶端完成的。HDFS 不會存儲或訪問未加密的數據或數據加密密鑰(由kms管理)。
連接地址: http://archive.cloudera.com/cdh5/cdh/5/hadoop/hadoop-project-dist/hadoop-hdfs/TransparentEncryption.html http://hadoop.apache.org/docs/r2.6.0/hadoop-kms/index.html
轉載請註明出處 http://blog.csdn.net/linlinv3/article/details/44963429
背景介紹 越來越多的用戶關註安全問題,都在尋找一種有效的,方便的加密方式。hadoop提供了幾種不同形式的加密,最底層的加密,加密所有節點數據,有效地保護了數據,但是卻缺乏更細粒度的加密;
kms 透明加密可以做到更細粒度的加密; 加密可以在不同的層級進行,包括軟件/軟件堆棧,選擇不同的加密層級各有優缺點
- 應用程序級加密。這是最安全、最靈活的方法。應用程序最終控制是什麽加密,可以準確地反映用戶的需求。然而,編寫應用程序這樣做是很難的。這也不是一個選擇為客戶現有的應用程序不支持加密。
- 數據庫級加密。類似的應用程序級加密的屬性。大多數數據庫廠商提供某種形式的加密。然而,可能有性能問題。一個例子是,索引不能加密。
- 文件系統級進行加密。該選項提供了高性能、應用程序透明,通常容易部署。但是,它無法模型應用程序級別的一些政策。例如,多租戶應用程序基於最終用戶可能想要加密。一個數據庫可能需要不同的加密設置每一列存儲在單個文件中。
- 磁盤級別加密。容易部署和高性能,但也很不靈活。
體系結構 Kms 有一個加密區 這個特殊的區域 對於能夠進行操作他的用戶 提供有寫入和讀取的權限。當加密區被創建的時候,每個加密區有唯一的秘鑰, data encryption key (DEK),秘鑰dek不由hdfs直接控制,但是hdfs控制encrypted data encryption key (EDEK),被加密的秘鑰;由客戶端解密EDEK;
kms server kms 服務器
kms client kms 客戶端
kms zone kms 加密區
配置
kms 配置
kms server配置
kms-site.xml 文件配置
1、kms backed keyProvider keyProvider 存儲地方的配置Configure the KMS backing KeyProvider properties in the etc/hadoop/kms-site.xml configuration file:
配置kms keyProvider存儲的地方
<!-- KMS Backend KeyProvider --> <property> <name>hadoop.kms.key.provider.uri</name> <value>jceks://[email protected]/${user.home}/kms.keystore</value> <description> URI of the backing KeyProvider for the KMS. </description> </property> <property> <name>hadoop.security.keystore.java-keystore-provider.password-file</name> <value>kms.keystore</value> <description> If using the JavaKeyStoreProvider, the password for the keystore file. </description> </property>這裏的keystore需要用 java 秘鑰生成器來生成
keytool -genkey -alias ‘key1‘; keytool -delete -alias ‘key1‘;
2、kms cache kms 緩存配置The cache is used with the following 3 methods only, getCurrentKey() and getKeyVersion() and getMetadata().配置緩沖區,這樣的話,當獲取 getCurrentKey() and getKeyVersion() and getMetadata() 的時候 不用每次去訪問 keystore 只用從緩存中讀取就可以。當然,秘鑰更新或者被刪除的時候,會自動更新。
<!-- KMS Cache --> <property> <name>hadoop.kms.cache.enable</name> <value>true</value> <description> Whether the KMS will act as a cache for the backing KeyProvider. When the cache is enabled, operations like getKeyVersion, getMetadata, and getCurrentKey will sometimes return cached data without consulting the backing KeyProvider. Cached values are flushed when keys are deleted or modified. </description> </property> <property> <name>hadoop.kms.cache.timeout.ms</name> <value>600000</value> <description> Expiry time for the KMS key version and key metadata cache, in milliseconds. This affects getKeyVersion and getMetadata. </description> </property> <property> <name>hadoop.kms.current.key.cache.timeout.ms</name> <value>30000</value> <description> Expiry time for the KMS current key cache, in milliseconds. This affects getCurrentKey operations. </description> </property>3、kms audit log 消息聚合日誌配置
Audit logs are aggregated for API accesses to the GET_KEY_VERSION, GET_CURRENT_KEY, DECRYPT_EEK, GENERATE_EEK operations.
Entries are grouped by the (user,key,operation) combined key for a configurable aggregation interval after which the number of accesses to the specified end-point by the user for a given key is flushed to the audit log.配置聚合日誌,將會對 (user,key,operation) 一樣的操作進行合並輸出,減少日誌流量
<!-- KMS Audit --> <property> <name>hadoop.kms.audit.aggregation.window.ms</name> <value>10000</value> <description> Duplicate audit log events within the aggregation window (specified in ms) are quashed to reduce log traffic. A single message for aggregated events is printed at the end of the window, along with a count of the number of aggregated eventsfu. </description> </property>4、kms security kms 安全配置 這裏可以有兩種配置 一種是使用simple 一種是使用 kerberos使用 simple 只用如下配置就可以
<!-- KMS Security -->
<property>
<name>hadoop.kms.authentication.type</name>
<value>simple</value>
<description>
Authentication type for the KMS. Can be either "simple"
or "kerberos".
</description>
</property>
kms-ent.sh 配置
- KMS_HTTP_PORT
- KMS_ADMIN_PORT
- KMS_MAX_THREADS
- KMS_LOG
export KMS_LOG=${KMS_HOME}/logs/kms export KMS_HTTP_PORT=16000 export KMS_ADMIN_PORT=16001配置完成後 啟動 kms sbin/kms.sh start ;停止 ksm sbin/kms.sh stop ;jps 後發現進程有 Bootstrap 這個進程就說明啟動成功;
kms 客戶端配置
kms-site.xml 配置如下參數
/etc/hadoop/conf/hdfs-site.xml
<property> <name>dfs.encryption.key.provider.uri</name> <value>kms://[email protected]:16000/kms</value> </property>
/etc/hadoop/confcore-site.xml
<property> <name>hadoop.security.key.provider.path</name> <value>kms://[email protected]:16000/kms</value> </property>重新啟動hadoop
創建key
# su - hdfs # hadoop key create key1 # hadoop key list -metadata
創建加密區
# hdfs dfs -mkdir /secureweblogs # hdfs crypto -createZone -keyName key1 -path /secureweblogs # hdfs crypto -listZones
實驗結果:
用 casliyang用戶 在加密區上傳文件: hdfs dfs -copyFromLocal /home/casliyang/read.log /zone1/web.log 下載文件 hdfs dfs -copyToLocal /zone1/web.log /home/casliyang/3.log
都可以成功
用hadoop220用戶 在加密區上上傳或者下載或者查看均失敗,提示沒有權限
補充說明:1、kms 啟動時候報錯,說找不到加密文件此處的加密文件可以是java自動生成的keystore 使用java keytool命令
生成秘鑰 keytool -delete -alias ‘kms.keystore‘; 刪除別名為kms.keystore的秘鑰keytool -genkey -alias ‘kms.keystore‘; 生成 別名為kms.keystore的秘鑰使用生成秘鑰的命令後,會在用戶根目錄下生成相應的文件2、kms 啟動時候 報錯
首先檢查 是否kms已經啟動,若 kms 確實沒有啟動起來,這時候需要到 根目錄root下的 temp文件夾 手動刪除 kms.pid 然後再次啟動kms
3、加密區建立成功後,任何用戶都能進行訪問等一系列操作
4、加密文件的原始隱藏路徑 :
hdfs dfs -cat /.reserved/raw/zone1/localfile.dat zone1 是加密區 localfile.dat 是加密文件 ,查看該文件 顯示的是被加密的文件(亂碼);
來自為知筆記(Wiz)
十三:Transparent Encryption in HDFS(轉)