hadoop 透明加密 kms transparent

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 透明加密可以做到更细粒度的加密；

    加密可以在不同的层级进行，包括软件/软件堆栈，选择不同的加密层级各有优缺点

• 应用程序级加密。这是最安全、最灵活的方法。应用程序最终控制是什么加密,可以准确地反映用户的需求。然而,编写应用程序这样做是很难的。这也不是一个选择为客户现有的应用程序不支持加密。

• 数据库级加密。类似的应用程序级加密的属性。大多数数据库厂商提供某种形式的加密。然而,可能有性能问题。一个例子是,索引不能加密。

• 文件系统级进行加密。该选项提供了高性能、应用程序透明,通常容易部署。但是,它无法模型应用程序级别的一些政策。例如,多租户应用程序基于最终用户可能想要加密。一个数据库可能需要不同的加密设置每一列存储在单个文件中。

• 磁盘级别加密。容易部署和高性能,但也很不灵活。

  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存储的地方

  
    hadoop.kms.key.provider.uri
    jceks://file@/${user.home}/kms.keystore
    
      URI of the backing KeyProvider for the KMS.
    
  
  
    hadoop.security.keystore.java-keystore-provider.password-file
    kms.keystore
    
      If using the JavaKeyStoreProvider, the password for the keystore file.
    
  
 

这里的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 只用从缓存中读取就可以。当然，秘钥更新或者被删除的时候，会自动更新。

 
  
    hadoop.kms.cache.enable
    true
    
      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.
    
  

  
    hadoop.kms.cache.timeout.ms
    600000
    
      Expiry time for the KMS key version and key metadata cache, in
      milliseconds. This affects getKeyVersion and getMetadata.
    
  

  
    hadoop.kms.current.key.cache.timeout.ms
    30000
    
      Expiry time for the KMS current key cache, in milliseconds. This
      affects getCurrentKey operations.
    
  

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) 一样的操作进行合并输出，减少日志流量

  
    hadoop.kms.audit.aggregation.window.ms
    10000
    
      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.
    
  

4、kms security    kms  安全配置  

这里可以有两种配置 一种是使用simple 一种是使用 kerberos

使用 simple 只用如下配置就可以

  

  
    hadoop.kms.authentication.type
    simple
    
      Authentication type for the KMS. Can be either "simple"
      or "kerberos".
    
  

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

     dfs.encryption.key.provider.uri
     kms://http@localhost:16000/kms

/etc/hadoop/confcore-site.xml

      hadoop.security.key.provider.path
      kms://http@localhost:16000/kms

重新启动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 是加密文件 ，查看该文件 显示的是被加密的文件（乱码）；