借助 KMS (Hadoop Key Management Server) 实现 HDFS 数据加密

这样设计的目的，是为了保证在 HDFS 中，不保存任何明文密钥信息，这样即使恶意用户攻破了 HDFS，也只能拿到加密后的文件和加密后的 DEK，依然读不到文件的原始内容。

多个 KMS Server 的 backing keystore 并不共享，原生 KMS Server 使用的是 JKS（Java KeyStore） 存储机制，EZ Key 都保存在本地文件系统上的 keyStore 文件中，这样的话，由于 keyStore 文件无法在多个 KMS Server 之间共享，导致挂掉任何一个 Server 后，其它剩余的 KMS Server 都可能读取不到已有的 EZ Key，导致 EZ key 丢失，进而使得加密文件打不开。

原生的这种集群组织方式，更像是一种负载均衡策略，从这种情况下 KMS 客户端的名字也能看的出来：LoadBalancingKMSClientProvider。在 Hadoop 的官方文档中，也强调了 JKS 这种存储机制不能用在生产环境中。

这个地方需要实现一个新的分布式的、共享存储的 backing keyStore 方式，可以使用 zookeeper 或者 ratis 等等。Apache Zookeeper 和 Apache Ratis 的比较：

目前的话，还是建议：

在普通的 HDFS 目录之间，文件的 move 并不涉及到数据的移动，仅仅是元数据的修改，速度非常快，但在 EZ 和非 EZ 之间、不同 EZ 之间，并不支持 move *** 作，只支持 copy *** 作，相对较慢，具体如下图所示：

这其中的原因是，HDFS client 无论 create、append 还是 open 一个文件时，如果发现这个文件是一个加密文件，那就需要特殊处理，而判断文件是否加密及随后正确的加解密处理（写入需要加密、读取需要解密），需要来自两方面的信息：

既然如此，那么：

如前所述，EZ 和 非 EZ 之间的 move *** 作是禁止的，换句话说 Trash 功能对 EZ 中的文件是不可用的，而在 TDWHadoop 中，数据保护功能默认打开（配置项 hadoop.tdw.protect.data.enable 默认为 true），客户端的 delete *** 作实际上最终是一个 move *** 作，既然 move 被禁止，那么最终表现为EZ 中的文件无法删除。

这个问题在 Hadoop 2.8.0 中得到解决，解决思路如下：

加密是使用数字密钥对各种组件进行编码的过程，因此只有适当的实体才能进行解码，然后查看，修改或添加到数据中。

CDH提供了加密机制来保护持久保存在磁盘或其他存储介质上的数据（以及在网络上移动时的数据）。

保护静止数据通常意味着对存储在磁盘上的数据进行加密，并允许授权用户和进程在手头的应用程序或任务需要时解密数据。对于静态数据加密，必须分发和管理加密密钥，应定期旋转或更改密钥，并且许多其他因素使该过程复杂化。

Cloudera Navigator Key Trustee Server

使用的企业级密钥存储和管理系统，它将加密密钥与数据分离，从而确保即使未经授权的用户访问存储介质，数据也受到保护。它使您的集群能够满足最严格的数据安全规定。此外，Navigator密钥托管服务器可以与硬件安全模块(HSM)集成，为密钥提供最高级别的安全性。

Navigator HSM KMS backed by Thales HSM

Navigator HSM KMS backed by Luna HSM

(上面三个需要认证证书，我不用)

基于文件且受密码保护的 Java KeyStore

使用Java keytool库进行加密

！！！注意：这里特别说明一下

这部分最好使用ip，不要使用hostname，之前使用的是hostname，导致后面有一步认证过不去，注意一下。

输入密码：EXAMPLE.COM

进入后输入

添加管理账号

查看账号

进入KDC

添加管理员账号

查看是否添加成功

进入主页 -->管理 -->安全

启用 Kerberos

对应修改配置 --->继续

开始配置

---