Apache Hadoop KMS 部署

名词解释

DEK： data encryption key

EDEKs： encrypted data encryption keys

EEK: encrypted encryption keys

介绍

KMS是hadoop自带的组件，只要安装了hadoop，KMS相关的东西就都有了，只要简单配置并启动就可以使用了。

KMS performs three basic responsibilities:

Providing access to stored encryption zone keys（提供对存储的加密区域密钥的访问）
Generating new encrypted data encryption keys for storage on the NameNode（生成新的加密数据加密密钥以存储在 NameNode 上）
Decrypting encrypted data encryption keys for use by HDFS client（解密供 HDFS 客户端使用的加密数据加密密钥）

简单使用场景：

前提场景： 人物：管理员s、用户a、用户b、外部未授权人c 管理员在HDFS上创建目录A，让a访问文件，但是b无权查看（通过hdfs权限控制，与Linux上的文件权限控制相同）管理员在HDFS上创建目录B，让b访问文件，且A无权限查看

无透明加密时： 一般情况下，通过HDFS客户端，a只能查看A中的文件；b只能查看B中的文件，但是如果a（或c）以某种方式进入HDFS的数据块存储区，直接取出B文件的数据块，那么B文件就泄露了。

存在透明的加密：

管理员使用KEY1来传输的目录被设定为“加密区域”，以及B目录也被设置为“加密区域” 当a获取B文件的数据块时，因为他没有使用文件的权限，KMS不会返回给他KEY 2。当c获取B文件的数据块时，因为他没有文件的使用权，KMS不会把KEY 2还给他。此时B文件的安全是有保障的。

KMS和HDFS的结合使用，是为了补充HDFS权限控制的安全漏洞。正常使用HDFS时，用户不会感觉到文件加密的存在，故称为“HDFS透明加密”。

KMS读写流程

Accessing data within an encryption zone

When creating a new file in an encryption zone, the NameNode asks the KMS to generate a new EDEK encrypted with the encryption zone’s key. The EDEK is then stored persistently as part of the file’s metadata on the NameNode.

在加密区域中创建新文件时，NameNode 会要求 KMS 生成使用加密区域密钥加密的新 EDEK。然后将 EDEK 作为文件元数据的一部分持久存储在 NameNode 上。

When reading a file within an encryption zone, the NameNode provides the client with the file’s EDEK and the encryption zone key version used to encrypt the EDEK. The client then asks the KMS to decrypt the EDEK, which involves checking that the client has permission to access the encryption zone key version. Assuming that is successful, the client uses the DEK to decrypt the file’s contents.

当读取加密区域内的文件时，NameNode 向客户端提供文件的 EDEK 和用于加密 EDEK 的加密区域密钥版本。然后客户端要求 KMS 解密 EDEK，这涉及检查客户端是否有权访问加密区域密钥版本。假设成功，客户端使用 DEK 解密文件的内容。

All of the above steps for the read and write path happen automatically through interactions between the DFSClient, the NameNode, and the KMS.

Access to encrypted file data and metadata is controlled by normal HDFS filesystem permissions. This means that if HDFS is compromised (for example, by gaining unauthorized access to an HDFS superuser account), a malicious user only gains access to ciphertext and encrypted keys. However, since access to encryption zone keys is controlled by a separate set of permissions on the KMS and key store, this does not pose a security threat.

对加密文件数据和元数据的访问由普通 HDFS 文件系统权限控制。这意味着，如果 HDFS 受到威胁（例如，通过未经授权访问 HDFS 超级用户帐户），恶意用户只能访问密文和加密密钥。但是，由于对加密区域密钥的访问由 KMS 和密钥存储上的一组单独权限控制，因此这不会构成安全威胁。

Encryption and decryption of EDEKs takes place entirely on the KMS. More importantly, the client requesting creation or decryption of an EDEK never handles the EZ key. Only the KMS can use EZ keys to create and decrypt EDEKs as requested. It is important to note that the KMS does not store any keys, other than temporarily in its cache. It is up to the enterprise keystore to be the authoritative storage for keys, and to ensure that keys are never lost, as a lost key is equivalent to introducing a security hole. For production use, Cloudera recommends you deploy two or more redundant enterprise key stores.

EDEK 的加密和解密完全在 KMS 上进行。更重要的是，请求创建或解密 EDEK 的客户端从不处理 EZ 密钥。只有 KMS 可以使用 EZ 密钥根据请求创建和解密 EDEK。需要注意的是，KMS 不存储任何密钥，除了临时存储在其缓存中。由企业密钥库作为密钥的权威存储，并确保密钥永不丢失，因为丢失的密钥相当于引入了安全漏洞。对于生产用途，Cloudera 建议您部署两个或更多冗余企业密钥存储。

Key Management Server, KeyProvider, EDEKs

The KMS is a proxy that interfaces with a backing key store on behalf of HDFS daemons and clients. Both the backing key store and the KMS implement the Hadoop KeyProvider API. See the KMS documentation for more information.

KMS 是一个代理，代表 HDFS 守护进程和客户端与后备密钥存储接口。后备密钥存储和 KMS 都实现了 Hadoop KeyProvider API。有关详细信息，请参阅 KMS 文档。

In the KeyProvider API, each encryption key has a unique key name. Because keys can be rolled, a key can have multiple key versions, where each key version has its own key material (the actual secret bytes used during encryption and decryption). An encryption key can be fetched by either its key name, returning the latest version of the key, or by a specific key version.

在 KeyProvider API 中，每个加密密钥都有一个唯一的密钥名称。因为密钥可以滚动，一个密钥可以有多个密钥版本，其中每个密钥版本都有自己的密钥材料（加密和解密期间使用的实际秘密字节）。可以通过密钥名称（返回密钥的最新版本）或特定密钥版本来获取加密密钥。

The KMS implements additional functionality which enables creation and decryption of encrypted encryption keys (EEKs). Creation and decryption of EEKs happens entirely on the KMS. Importantly, the client requesting creation or decryption of an EEK never handles the EEK’s encryption key. To create a new EEK, the KMS generates a new random key, encrypts it with the specified key, and returns the EEK to the client. To decrypt an EEK, the KMS checks that the user has access to the encryption key, uses it to decrypt the EEK, and returns the decrypted encryption key.

KMS 实现了附加功能，可以创建和解密加密的加密密钥 (EEK)。 EEK 的创建和解密完全在 KMS 上进行。重要的是，请求创建或解密 EEK 的客户端从不处理 EEK 的加密密钥。为了创建新的 EEK，KMS 会生成一个新的随机密钥，使用指定的密钥对其进行加密，然后将 EEK 返回给客户端。为了解密 EEK，KMS 检查用户是否有权访问加密密钥，使用它来解密 EEK，并返回解密的加密密钥。

In the context of HDFS encryption, EEKs are encrypted data encryption keys (EDEKs), where a data encryption key (DEK) is what is used to encrypt and decrypt file data. Typically, the key store is configured to only allow end users access to the keys used to encrypt DEKs. This means that EDEKs can be safely stored and handled by HDFS, since the HDFS user will not have access to unencrypted encryption keys.

在 HDFS 加密的上下文中，EEK 是加密数据加密密钥 (EDEK)，其中数据加密密钥 (DEK) 用于加密和解密文件数据。通常，密钥库配置为仅允许最终用户访问用于加密 DEK 的密钥。这意味着 HDFS 可以安全地存储和处理 EDEK，因为 HDFS 用户将无法访问未加密的加密密钥。

KMS部署

创建密钥数据库（keystore）(不需要)

使用jdk的密钥生成器keytool来生成密钥命令：keytool -genkey -alias ‘key1’; 说明： keytool : 密钥生成器的命令 -genkey: 密钥生成器的生成密钥的参数 -alias: 密钥生成密钥时给密钥取别名时的参数、 ‘key1’ : 我们给这个密钥取得别名（也就是密钥的名字，可以随便取）

回车之后，密钥生成器还需用户填入密码以及其他用户信息，按照要求填写完毕即可按照这个流程执行完之后，密钥会在用户的系统目录里生成（Linux是：/home/用户名）,直接打开该目录看不到新生成的文件，因为这是个隐藏文件（文件名默认为： .keystore）使用ls -a即可看到该文件（keystore后缀可以是.keystore 或者 .jks）还可以一次性把密钥生成器所需的全部参数一次性写完，包括定义keystore的文件名及存储路径，如：

keytool -genkey -alias 'kmskey' -keystore /home/henghe/kms.keystore  -dname "CN=localhost, OU=localhost, O=localhost, L=SH, ST=SH, C=CN" -keypass 123456 -storepass 123456 -validity 180

keytool具体使用及说明详见keytool使用文档 说明一点：一个keystore中可以放多个密钥，只要多次生成密钥，并且保证指向的是同一个keystore（不过这里即使产生多个也没啥用，后面会讲hadoop必须使用的自己产生的密钥，这一步的意义仅仅是产生一个密钥容器）

创建密码文件：

生成了keystore后，这个keystore就可以作为kms的密钥存储数据库了，由于这个keystore有访问密码（比如上面所设置的storepass ：123456），这个密码是要告诉kms的，否则kms访问不了这个keystore，kms通过读取一个文本文件来获取密码。所以我们需要创建一文本文件，在里面写上keystore访问密码

下面讲怎么把 keystore 和这个keystore的访问密码配置到kms配置文件中，让kms读取 kms由于是hadoop自带的组件，所以kms的配置文件默认和hadoop放在一起

配置kms-site.xml

配置kms keyProvider存储的地方，也就是密钥存储的地方

<!-- KMS Backend KeyProvider -->
<property><name>hadoop.kms.key.provider.uri</name><value>jceks://file@/home/henghe/kms.keystore</value>
</property>
<property><name>hadoop.security.keystore.java-keystore-provider.password-file</name><value>kms.keystore.password</value>
</property>

说明：

<name>的值是固定的写法，必须要这么写 hadoop.kms.key.provider.uri jceks://file@/user.home/kms.jks：意义：keystore地址：这个地址前面的jceks://file@是固定写法不要随意改变或删除，kms在获取了这个地址之后会把他转换为file://user.home/kms.jks：意义：keystore地址：这个地址前面的jceks://file@是固定写法不要随意改变或删除，kms在获取了这个地址之后会把他转换为file://{user.home}/kms.keystore来访问，如果用户是aa，那么kms就会找/home/aa/kms.jks这个文件

hadoop.security.keystore.java-keystore-provider.password-file kms.keystore 意义：keystore的访问密码文件地址，也就是在生成keystore时，输入的-storepass 注意：这个地址的意思是“kms.passwd”这个文件要放在kms的tomcat下的classes中（放在其他目录系统会找不到而报错）

1.core-site.xml 新增配置项

<property><name>hadoop.security.key.provider.path</name><value>kms://http@sh-100-63:9600/kms</value>
</property>

2.hdfs-site.xml 新增配置项

<property><name>hadoop.security.key.provider.path</name><value>kms://http@sh-100-63:9600/kms</value>
</property>

与读取和写入加密区域时使用的加密密钥交互时使用的 KeyProvider。 HDFS 客户端将使用通过 getServerDefaults 从 Namenode 返回的提供程序路径。如果 namenode 不支持返回密钥提供程序 uri，则将使用客户端的 conf。

启动和停止KMS

hadoop --daemon start kms

创建key

#创建Key
[henghe@sh-100-63 hadoop]$ hadoop key create key2
key2 has been successfully created with options Options{cipher='AES/CTR/NoPadding', bitLength=128, description='null', attributes=null}.
org.apache.hadoop.crypto.key.kms.LoadBalancingKMSClientProvider@394a2528 has been updated.#查看Key
[henghe@sh-100-63 hadoop]$ hadoop key list
Listing keys for KeyProvider: org.apache.hadoop.crypto.key.kms.LoadBalancingKMSClientProvider@4988d8b8
key2
kmskey#查看文件目录
[henghe@sh-100-63 hadoop]$ hadoop dfs -ls /
WARNING: Use of this script to execute dfs is deprecated.
WARNING: Attempting to execute replacement "hdfs dfs" instead.
Found 4 items
drwxr-xr-x   - hbase  supergroup          0 2021-11-23 16:03 /hbase2
drwxr-xr-x   - hive   supergroup          0 2021-11-19 14:19 /hive
drwxrwxrwx   - henghe supergroup          0 2021-11-19 14:20 /tmp
drwxr-xr-x   - henghe supergroup          0 2021-11-19 14:20 /user#创建文件目录
[henghe@sh-100-63 hadoop]$ hadoop dfs -mkdir  /kms
WARNING: Use of this script to execute dfs is deprecated.
WARNING: Attempting to execute replacement "hdfs dfs" instead

创建加密区

使用hdfs crypto 命令来操作加密区，之后被放入加密区的文件会被自动加密，有权限查看的用户查看会自动解密

[henghe@sh-100-63 hadoop]$ hdfs  crypto -createZone  -keyName  key2  -path  /kms1
Added encryption zone /kms1

key2 ：密钥名 /kms : 需要被设置为加密区的目录

查看加密区

hdfs  crypto -listZones

注意

当密钥K已经被用于加密了某个hdfs文件夹，再删除这个密钥K，是可以删除成功的当某个文件夹已经用密钥K1设置为加密区了，再用k2设置这个目录为加密区的时候，会报错，并创建加密区失败： RemoteException: Directory /testdir2 is already in an encryption zone. (/testdir2) 当某个目录里有其他目录，不能用于创建加密区 RemoteException: Attempt to create an encryption zone for a non-empty directory. 成功创建加密区后： Added encryption zone /testdir2 所有密钥操作的前提是kms必须正常开启并可访问，否则会报错: Cannot list keys for KeyProvider: KMSClientProvider[http://192.168.50.157:16000/kms/v1/]: java.net.ConnectException: Connection refused … 如果想换一个keystore，比如想把另一个系统个密钥迁移过来，直接拷贝keystore文件是不行的，因为kms有文件校验机制：在keystore的同级目录会有一个隐藏文件.keystore.crc，用于校验keystore的完整性，如果想从其他地方迁移一个keystore，必须先把本地这个.crc校验文件删除（不用担心：当做下一次keystore更新的时候，比如新增一个密钥，kms会自动检查并新增一个.crc文件）

查看加密区文件在datanode目录里是否加密

[henghe@sh-100-62 root]$ hadoop fsck hdfs://192.168.100.63:8020/kms3/c.txt  -files -locations -blocks
WARNING: Use of this script to execute fsck is deprecated.
WARNING: Attempting to execute replacement "hdfs fsck" instead.Connecting to namenode via http://sh-100-63:50070/fsck?ugi=henghe&files=1&locations=1&blocks=1&path=%2Fkms3%2Fc.txt
FSCK started by henghe (auth:SIMPLE) from /192.168.100.62 for path /kms3/c.txt at Fri Dec 03 13:25:46 CST 2021
/kms3/c.txt 19 bytes, replicated: replication=3, 1 block(s):  OK
0. BP-1698780750-192.168.100.63-1637302646599:blk_1073744611_3792 len=19 Live_repl=3  [DatanodeInfoWithStorage[192.168.100.63:9866,DS-dcdef1c0-8579-48aa-bf9d-2f1486ba3dcd,DISK], DatanodeInfoWithStorage[192.168.100.71:9866,DS-752471b5-c821-4088-a10a-fcda55042edc,DISK], DatanodeInfoWithStorage[192.168.100.69:9866,DS-ddbff0d7-3af4-44f7-a8b0-3835ed5db0b3,DISK]]#到对应datanode的dn目录下查找相应块：[henghe@sh-100-62 root]$ # find /dfs/dn -name blk_1073744611*