透明加密：http://blog.csdn.net/linlinv3/article/details/44963429
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管理）。
HDFS 实现透明，端到端加密。配置完成后，用户往hdfs上存储数据的时候，无需用户做任何程序代码的更改（意思就是调用KeyProvider API ，用于在数据存入到HDFS上面的时候进行数据加密，解密的过程一样）。这意味着数据加密和解密由客户端完成的。HDFS 不会存储或访问未加密的数据或数据加密密钥（由kms管理）。
连接地址：
背景介绍
越来越多的用户关注安全问题，都在寻找一种有效的，方便的加密方式。hadoop提供了几种不同形式的加密，最底层的加密，加密所有节点数据，有效地保护了数据，但是却缺乏更细粒度的加密；
kms 透明加密可以做到更细粒度的加密；
加密可以在不同的层级进行，包括软件/软件堆栈，选择不同的加密层级各有优缺点
- 应用程序级加密。这是最安全、最灵活的方法。应用程序最终控制是什么加密,可以准确地反映用户的需求。然而,编写应用程序这样做是很难的。这也不是一个选择为客户现有的应用程序不支持加密。
- 数据库级加密。类似的应用程序级加密的属性。大多数数据库厂商提供某种形式的加密。然而,可能有性能问题。一个例子是,索引不能加密。
- 文件系统级进行加密。该选项提供了高性能、应用程序透明,通常容易部署。但是,它无法模型应用程序级别的一些政策。例如,多租户应用程序基于最终用户可能想要加密。一个数据库可能需要不同的加密设置每一列存储在单个文件中。
- 磁盘级别加密。容易部署和高性能,但也很不灵活。
hdfs处于数据库加密层和文件系统加密层之间。能有效地防止对文件系统的攻击，因为他的存储都是加密的。对于每个用户可以有不同的加密区
体系结构
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://file@/${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://http@localhost:16000/kms</value>
</property>
/etc/hadoop/confcore-site.xml
<property>
<name>hadoop.security.key.provider.path</name>
<value>kms://http@localhost: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 是加密文件 ，查看该文件 显示的是被加密的文件（乱码）；