HDFS透明加密实验kms hdfs数据加密

1 HDFS Trash垃圾桶

1.1 文件系统垃圾桶背景

回收站概述：

• 回收站（垃圾桶）是微软Windows操作系统里的一个系统文件夹，主要用来存放用户临时删除的文档资料，存放在回收站的文件可以恢复。
• 回收站的功能给了我们一剂“后悔药”。回收站保存了删除的文件、文件夹、图片、快捷方式等。这些项目将一直保留在回收站中，直到您清空回收站。我们许多误删除的文件就是从它里面找到的。

HDFS默认：

• HDFS本身也是一个文件系统，那么就会涉及到文件数据的删除操作。
• 默认情况下，HDFS中是没有回收站垃圾桶概念的，删除操作的数据将会被直接删除，没有后悔药。

1.2 HDFS Trash功能概述

概述：

• HDFS Trash机制，叫做回收站或者垃圾桶。Trash就像Windows操作系统中的回收站一样。它的目的是防止你无意中删除某些东西。默认情况下是不开启的。
• 启用Trash功能后，从HDFS中删除某些内容时，文件或目录不会立即被清除，它们将被移动到回收站Current目录中(/user/${username}/.Trash/current)。
• .Trash中的文件在用户可配置的时间延迟后被永久删除。
• 也可以简单地将回收站里的文件移动到.Trash目录之外的位置来恢复回收站中的文件和目录。

Trash Checkpoint：

• 检查点仅仅是用户回收站下的一个目录，用于存储在创建检查点之前删除的所有文件或目录。
• 回收站目录在/user/${username}/.Trash/{timestamp_of_checkpoint_creation}
• 最近删除的文件被移动到回收站Current目录，并且在可配置的时间间隔内，HDFS会为在Current回收站目录下的文件创建检查点/user/${username}/.Trash/<日期>，并在过期时删除旧的检查点。

1.3 Trash功能开启

• Step1：关闭HDFS集群
• Step2：修改core-site.xml文件

<property>
<name>fs.trash.interval</name>
<value>1440</value>
</property>
<property>
<name>fs.trash.checkpoint.interval</name>
<value>0</value>
</property>

属性介绍：

1. lfs.trash.interval：回收站中的文件多少分钟后会被系统永久删除。如果为零，Trash功能将被禁用。
2. lfs.trash.checkpoint.interval：前后两次检查点的创建时间间隔（单位也是分钟），新的检查点被创建后，随之旧的检查点就会被系统永久删除。如果为零，则将该值设置为fs.trash.interval的值。

• Step3:同步集群配置文件

scp -r /export/server/hadoop-3.1.4/etc/hadoop/core-site.xml node2:/export/server/hadoop-3.1.4/etc/hadoop/
scp -r /export/server/hadoop-3.1.4/etc/hadoop/core-site.xml node3:/export/server/hadoop-3.1.4/etc/hadoop/

• Step4：启动HDFS集群

1.4 Trash功能使用

删除文件：

• 开启Trash功能后，正常执行删除操作，文件实际并不会被直接删除，而是被移动到了垃圾回收站。
• 有的时候，我们希望直接把文件删除，不需要再经过Trash回收站了。
• 可以在执行删除操作的时候添加一个参数：-skipTrash.

恢复文件：

• 回收站里面的文件，在到期被自动删除之前，都可以通过命令恢复出来。
• 使用mv、cp命令把数据文件从Trash目录下复制移动出来就可以了。

清空Trash：

• 除了fs.trash.interval参数控制到期自动删除之外，用户还可以通过命令手动清空回收站，释放HDFS磁盘存储空间。
• 首先想到的是删除整个回收站目录，将会清空回收站,这是一个选择。
• 此外。HDFS提供了一个命令行工具来完成这个工作：hadoop fs -expunge。该命令立即从文件系统中删除过期的检查点。

2 HDFSSnapshot快照

概述：

• 可以将快照理解为拍照片时的那一瞬间的投影。
• 快照（Snapshot）是数据存储的某一时刻的状态记录；备份（Backup）则是数据存储的某一个时刻的副本。
• HDFS Snapshot快照是整个文件系统或某个目录在某个时刻的镜像。该镜像并不会随着源目录的改变而进行动态的更新。

作用：

• 数据恢复

对重要目录进行创建snapshot的操作，当用户误操作时，可以通过snapshot来进行相关的恢复操作。

• 数据备份

使用snapshot来进行整个集群，或者某些目录、文件的备份。管理员以某个时刻的snapshot作为备份的起始结点，然后通过比较不同备份之间差异性，来进行增量备份。

• 数据测试

在某些重要数据上进行测试或者实验，可能会直接将原始的数据破坏掉。可以临时的为用户针对要操作的数据来创建一个snapshot，然后让用户在对应的snapshot上进行相关的实验和测试，从而避免对原始数据的破坏。

2.1 HDFS快照功能的实现

• HDFS快照不是数据的简单拷贝，只做差异的记录。
• 对于大多不变的数据，你所看到的数据其实是当前物理路径所指的内容，而发生变更的inode数据才会被快照额外拷贝，也就是所说的差异拷贝。
• inode指索引节点，用来存放文件及目录的基本信息，包含时间、名称、拥有者、所在组等。
• HDFS快照不会复制datanode中的块，只记录了块列表和文件大小。
• HDFS快照不会对常规HDFS操作产生不利影响，修改记录按逆时针顺序进行，因此可以直接访问当前数据。通过从当前数据中减去修改来计算快照数据。

2.2 HDFS快照命令

快照功能开启命令

• HDFS中可以针对整个文件系统或者某个目录创建快照，但是创建快照的前提是相应的目录开启快照的功能。
• 如果针对没有启动快照功能的目录创建快照则会报错

#启用快照功能：
hdfs dfsadmin -allowSnapshot /allenwoon

快照功能禁用命令

• HDFS中可以针对已经开启快照功能的目录进行禁用快照功能的设置
• 禁用的前提是该目录的所有快照已经被删除

#禁用快照功能：
hdfs dfsadmin -disallowSnapshot  /allenwoon

快照操作相关命令

• createSnapshot 创建快照
• deleteSnapshot 删除快照
• renameSnapshot 重命名快照
• lsSnapshottableDir 列出可以快照目录列表
• snapshotDiff 获取快照差异报告。

3 HDFS 权限管理

3.1 权限管理总览概述

认证、授权和审计

• 认证（Authentication）、授权（Authorization）和审计（Accounting）指计算机安全领域的一个架构模式。通常缩写为 AAA。
• 在该模式中，使用服务的用户先要证明自己的身份；然后根据规则被授予权限，同时其操作被记录下来留待审计。
• 与 AAA 紧密相联的一个概念是身份。身份是指系统如何将不同的实体、用户和服务区分开来，典型的代表是一个任意字符串，例如用户名或者诸如用户ID（UID）的唯一号码。

HDFS权限管理概述

• 客户端的操作请求会首先通过用户身份验证机制来获得“凭证”（类似于身份证书）,HDFS根据此“凭证”分辨出合法的用户名;
• 然后HDFS再据此查看该用户所访问的数据是否已经授权,或者说该身份凭证是否具有权限做这件事。
• 一旦这个流程中的某个环节出现异常，客户端的操作请求便会失败。

3.2 UGO权限管理

拥有者、所在组、其他用户组

• HDFS文件权限与Linux/Unix系统的UGO模型类似，简单描述为：每个文件和目录都与一个拥有者和一个组相关联。
• USER（文件的所有者）：一般是创建该文件的用户，对该文件具有完全的权限。
• GROUP（拥有者所在的组）：和文件所有者属于同一组的用户。
• OTHER（其他用户组）：其他用户组的用户。

读、写、执行权限

• HDFS文件权限也细分为：读权限（r）、写权限（w）、执行权限（x）。
• 在HDFS中，对于文件，需要r权限才能读取文件，而w权限才能写入或追加到文件。没有x可执行文件的概念。
• 在HDFS中，对于目录，需要r权限才能列出目录的内容，需要w权限才能创建或删除文件或目录，并且需要x权限才能访问目录的子级。

也可以用数字表示：7–可读可写可执行、5–可读可执行不可写、4–仅可读。

umask权限掩码

• 与Linux/Unix系统类似，HDFS也提供了umask掩码，用于设置在HDFS中默认新建的文件和目录权限位。
• 默认umask值有属性fs.permissions.umask-mode指定，默认值022。
• 创建文件和目录时使用的umask，默认的权限就是

• 目录：777-022=755，也就是drwxr-xr-x
• 文件：777-022=755，因为HDFS中文件没有x执行权限的概念，所以是：-rw-r–r–

UGO权限相关命令

#变更目录或文件的权限 可以使用数字 也可以使用字母 u g o a + - r w x
hadoop fs -chmod [-R] 777 /user/itcast/foo
hadoop fs -chmod [-R] u+x,o-x /user/itcast/foo
#变更目录或文件的属主或用户组
hadoop fs -chown [-R] itcast /user/itcast/foo
hadoop fs -chown [-R] itcast:ogroup /user/itcast/foo
#变更用户组
hadoop fs -chgrp [-R] group1 /user/itcast/foo

Web页面修改UGO权限

• Hadoop3.0之后，支持在HDFS Web页面上使用鼠标修改。

注意：

• 粘滞[nián zhì]位（Sticky bit）用在目录上设置，如此以来，只有目录内文件的所有者或者root才可以删除或移动该文件。
• 如果不为目录设置粘滞位，任何具有该目录写和执行权限的用户都可以删除和移动其中的文件。

3.3 用户身份认证

概述：

• 在HDFS中，用户身份认证独立于HDFS项目之外，也就说HDFS并不负责用户身份合法性检查。
• 但HDFS会通过相关接口来获取相关的用户身份，然后用于后续的权限管理。
• 用户是否合法，完全取决于集群使用认证体系。目前社区支持两种身份认证，即简单认证（Simple）和Kerberos。
• 由hadoop.security.authentication属性指定，默认simple。

Simple认证

• 基于HDFS客户端所在的Linux/Unix系统的登录用户名来进行认证。只要用户能正常登录就认证成功。
• 客户端与NN交互时，会将用户的登录账号（通过类似whoami的命令来获取）作为合法用户名传递至NN。
• 意味着使用不同的账号登录到同一个客户端，会产生不同的用户名，故在多租户条件这种认证会导致权限混淆；
• 同时恶意用户也可以伪造其他人的用户名非法获得相应的权限，对数据安全造成极大的隐患。
• 线上生产环境一般不会使用。
• simple认证时，HDFS想法是：防止好人误做坏事，不防止坏人做坏事。
• 当客户端提交给Hadoop一个用户名时，Hadoop会很高兴地相信你所说的一切，并且确保整个集群的所有其他机器也相信。

打个比方，在聚会中，一个人接近你并自我介绍为Bill，你自然会相信他确实是Bill。你怎么知道他确实是Bill ？因为他是这么说的，而且你毫无疑问地相信了他。Hadoop在simple机制下差不多也是这样，不同的是它还做了进一步类推，不仅相信他就是他自己所说的 Bill，还保证其他人也都相信。这是个问题。

Kerberos认证

介绍：

• 在神话里，Kerberos是Cerberus的希腊语，是一只守护地狱入口的三头巨犬，它确保没有人能在进入地狱后离开。
• 从技术角度来说，Kerberos是麻省理工学院（MIT）开发的一种网络身份认证协议。它旨在通过使用密钥加密技术为客户端/服务器应用程序提供强身份验证。

角色：

• 访问服务的Client
• 提供服务的Server
• KDC（Key Distribution Center）密钥分发中心

域：

其中KDC服务默认会安装在一个域的域控中，而Client和Server为域内的用户或者是服务，如HTTP服务，SQL服务。在Kerberos中Client是否有权限访问Server端的服务由KDC发放的票据来决定。

域的产生是为了解决企业内部的资源管理问题，比如一个公司就可以在网络中建立一个域环境，更方便内部的资源管理。在一个域中有域控、域管理员、普通用户、主机等等各种资源。

lYUNYING.LAB为其他两个域的根域，NEWS.YUNYING.LAB和DEV.YUNYING.LAB均为YUNYING.LAB的子域，这三个域组成了一个域树。

子域的概念可以理解为一个集团在不同业务上分公司，他们有业务重合的点并且都属于YUNYING.LAB这个根域，但又独立运作。同样TEST.COM也是一个单独的域树，两个域树YUNYING.LAB和TEST.COM组合起来被称为一个域林。

票据：

如果把Kerberos中的票据类比为一张火车票，那么Client端就是乘客，Server端就是火车，而KDC就是就是车站的认证系统。如果Client端的票据是合法的（由你本人身份证购买并由你本人持有）同时有访问Server端服务的权限（车票对应车次正确）那么你才能上车。当然和火车票不一样的是Kerberos中有存在两张票，而火车票从头到尾只有一张。

KDC：

• Authentication Server： AS的作用就是验证Client端的身份（确定你是身份证上的本人），验证通过就会给一张TGT（Ticket Granting Ticket）票给Client。
• Ticket Granting Server： TGS的作用是通过AS发送给Client的票（TGT）换取访问Server端的票（上车的票ST）。ST（Service Ticket）也有资料称为TGS Ticket，为了和TGS区分，在这里就用ST来说明。

3.4 Group Mapping组映射

概述：

• 在通过用户身份认证拿到用户名后之后，NameNode还需要通过用户组映射服务获取该用户所对应的用户组列表，用于后期的用户组权限校验
• HDFS中用户所属组的确认工作需要通过外部的用户组映射（Group Mapping）服务来获取。用户到组的映射可以使用系统自带的方案（使用NameNode服务器上的用户组系统），也可以通过其他实现类似功能的插件（LDAP、Ranger等）方式来代替。

基于Linux/Unix系统的用户和用户组：

• Linux/Unix系统上的用户和用户组信息存储在/etc/passwd和/etc/group文件中。
• 默认情况下，HDFS会通过调用外部的 Shell 命令来获取用户的所有用户组列表。
• /etc/passwd
• 一行记录对应着一个用户，每行记录又被冒号(:)分隔为7个字段，其格式和具体含义如下：
  用户名:口令:用户标识号:组标识号:注释性描述:主目录:登录Shell
  其中组标识号字段记录的是用户所属的用户组。它对应着/etc/group文件中的一条记录。
• /etc/group
• 文件中每一行各代表一个用户组，每行记录又被冒号(:)分隔为4个字段，其格式和具体含义如下：
  组名：密码：GID：该用户组中的用户列表
  其中最后一个字段列出每个群组包含的所有用户。需要注意的是，如果该用户组是这个用户的初始组，则该 用户不会写入这个字段，可以这么理解，该字段显示的用户都是这个用户组的附加用户。
• 此方案的优点在于组映射服务十分稳定，不易受外部服务的影响。
• 但是用户和用户组管理涉及到root权限等，同时会在服务器上生成大量的用户组，后续管理，特别是自动化运维方面会有较大影响。

3.5 ACL权限管理

背景：

在UGO权限中，用户对文件只有三种身份，就是属主（user）、属组（group）和其他人（other）。

每种用户身份拥有读（read）、写（write）和执行（execute）三种权限。

但是在实际工作中，使用UGO来控制权限可以满足大部分场景下的数据安全性要求，但是对于一些复杂的权限需求则无能为力。

文件系统根目录中有一个 /project 目录，这是班级的项目目录。

班级中的每个学员都可以访问和修改这个目录，老师也需要对这个目录拥有访问和修改权限，其他班级的学员当然不能访问这个目录。

老师使用 root 用户，作为这个目录的属主，权限为 rwx；班级所有的学员都加入 tgroup 组，使 tgroup 组作为 /project目录的属组，权限是 rwx；其他人的权限设定为 0。这样这个目录的权限就可以符合我们的项目开发要求了。

有一天，班里来了一位试听的学员 st，她必须能够访问/project 目录，所以必须对这个目录拥有 r 和 x 权限；

但是她又没有学习过以前的课程，所以不能赋予她 w 权限，怕她改错了目录中的内容，所以学员 st 的权限就是 r-x。可是如何分配她的身份呢？

变为属主？当然不行，要不 root 该放哪里？加入 tgroup 组？也不行，因为 tgroup 组的权限是 rwx，而我们要求学员 st 的权限是 r-x。如果把其他人的权限改为 r-x 呢？这样一来，其他班级的所有学员都可以访问 /project 目录了。

当出现这种情况时，普通权限中的三种身份就不够用了。ACL 权限就是为了解决这个问题的。在使用 ACL 权限给用户st陚予权限时，st 既不是 /project 目录的属主，也不是属组，仅仅赋予用户 st 针对此目录的 r-x 权限。

ACL是Access Control List（访问控制列表）的缩写，ACL提供了一种方法，可以为特定的用户或组设置不同的权限，而不仅仅是文件的所有者和文件的组。

ACL Shell 命令：

hadoop fs -getfacl [-R] <path>
显示文件和目录的访问控制列表（ACL）。如果目录具有默认ACL，则getfacl还将显示默认ACL。
hadoop fs [generic options] -setfacl [-R] [{-b|-k} {-m|-x <acl_spec>} <path>]|[--set <acl_spec> <path>]
设置文件和目录的访问控制列表（ACL）。
hadoop fs -ls <args>
ls的输出将在带有ACL的任何文件或目录的权限字符串后附加一个'+'字符。

其他操作命令：

1、带有ACL的任何文件或目录的权限字符串后附加一个'+'字符
[root@node1 ~]# hadoop fs -ls /
Found 5 items
drwxr-xr-x   - root supergroup          0 2021-01-06 20:59 /data
drwxr-xr-x   - root supergroup          0 2020-12-31 11:59 /itcast
drwxrwxr-x+  - root supergroup          0 2021-01-07 19:38 /itheima
drwx------   - root supergroup          0 2020-12-31 11:56 /tmp
drwxr-xr-x   - root supergroup          0 2020-12-31 11:56 /user
2、删除指定的ACL条目
hadoop fs -setfacl -x user:allenwoon /itheima
3、删除基本ACL条目以外的所有条目。保留用户，组和其他条目以与权限位兼容。
hadoop fs -setfacl -b /itheima

4、设置默认的ACl权限，以后在该目录中新建文件或者子目录时，新建的文件/目录的ACL权限都是之前设置的default ACLs
[root@node1 ~]# hadoop fs -setfacl -m default:user:allenwoon:rwx /itheima
[root@node1 ~]# hadoop fs -getfacl /itheima                             
# file: /itheima
# owner: root
# group: supergroup
user::rwx
group::r-x
other::r-x
default:user::rwx
default:user:allenwoon:rwx
default:group::r-x
default:mask::rwx
default:other::r-x
5、删除默认ACL权限
hadoop fs -setfacl -k /itheima 
6、--set: 完全替换ACL，丢弃所有现有条目。 acl_spec必须包含用户，组和其他条目，以便与权限位兼容。
hadoop fs -setfacl --set user::rw-,user:hadoop:rw-,group::r--,other::r-- /file

4 HDFSProxy user代理用户

概述：

• Proxy中文称之为代理、委托。用来进行事物不想或不能进行的其他操作。
• HDFS Proxy user（代理用户）描述的是一个用户（比如超级用户）如何代表另一个用户提交作业或访问HDFS。
• 比如：用户名为“Admin”的超级用户代表用户Allen提交作业并访问HDFS。
• 因为超级用户Admin具有kerberos凭证，但Allen用户没有任何凭证。这些任务需要以用户Allen的身份运行，而对namenode的任何文件访问都必须以用户Allen的身份进行。要求用户Allen可以在通过Admin的kerberos凭据进行身份验证的连接上连接到namenode。换句话说， Admin正在冒充用户Allen 。

5 HDFS 透明加密

5.1 HDFS明文存储弊端

• HDFS中的数据会以block的形式保存在各台数据节点的本地磁盘中，但这些block都是明文的。
• 通过Web UI页面找到Block的ID和副本位于的机器信息
• 如果在操作系统下，直接访问block所在的目录，通过Linux的cat命令是可以直接查看里面的内容的，且是明文。

5.2 加密技术

数据加密概述：

• 数据加密是计算机系统对信息进行保护的一种最可靠的办法。它利用密码技术对信息进行加密，实现信息隐蔽，从而起到保护信息的安全的作用。
• 数据加密通常采用通过加密算法和加密密钥将明文转变为密文，而解密则是通过解密算法和解密密钥将密文恢复为明文。它的核心是密码学。

常见的加密层级：

• 应用层加密

这是最安全也是最灵活的方式。加密内容最终由应用程序来控制，并且可以精确的反映用户的需求。但是，编写应用程序来实现加密一般都比较困难。

• 数据库层加密

类似于应用程序加密。大多数数据库厂商都提供某种形式的加密，但是可能会有性能问题，另外比如说索引没办法加密。

• 文件系统层加密

这种方式对性能影响不大，且对应用程序是透明的，一般也比较容易实施。但是应用程序细粒度的要求策略，可能无法完全满足。比如加密文件系统 (EFS) 用于在 NTFS 文件系统卷上存储已加密的文件。

• 磁盘层加密

易于部署和高性能，但是相当不灵活，只能防止用户从物理层面盗窃数据。常用的方式有：修改硬盘分区表信息、对硬盘启动加口令、磁盘扇区数据加密等等。

5.3 HDFS透明加密介绍

概述：

• HDFS透明加密（Transparent Encryption）支持端到端的透明加密，启用以后，对于一些需要加密的HDFS目录里的文件可以实现透明的加密和解密，而不需要修改用户的业务代码。端到端是指加密和解密只能通过客户端。
• 对于加密区域里的文件，HDFS保存的即是加密后的文件，文件加密的秘钥也是加密的。让非法用户即使从操作系统层面拷走文件，也是密文，没法查看。

特点：

• HDFS集群管理和密钥的管理是互相独立的职责，由不同的用户角色（HDFS管理员，密钥管理员）承担
• 只有HDFS客户端可以加密或解密数据，密钥管理在HDFS外部，HDFS无法访问未加密的数据或加密密钥
• block在操作系统是以加密的形式存储的，从而减轻了操作系统和文件系统级别的安全威胁
• HDFS使用AES-CTR加密算法。AES-CTR支持128位加密密钥（默认）

5.4 HDFS透明加密关键概念和架构

加密区域

• HDFS的透明加密有一个新的概念，加密区域（the encryption zone）。
• 加密区域就是HDFS上的一个目录，只不过该目录比其他目录特殊。
• 加密区域里写入文件的时候会被透明加密，读取文件的时候又会被透明解密。

密钥

• 当加密区域被创建时，都会有一个加密区域秘钥（EZ密钥，encryption zone key）与之对应，EZ密钥存储在HDFS外部的密钥库中。
• 加密区域里的每个文件都有其自己加密密钥，叫做数据加密秘钥（DEK，data encryption key）。
• DEK会使用其各自的加密区域的EZ密钥进行加密，以形成加密数据加密密钥（EDEK）。

密钥库

• 存储密钥（key）的叫做密钥库（keystore）,将HDFS与外部企业级密钥库（keystore）集成是部署透明加密的第一步。
• 这是因为密钥（key）管理员和HDFS管理员之间的职责分离是此功能的非常重要的方面。
• 但是，大多数密钥库都不是为Hadoop工作负载所见的加密/解密请求速率而设计的。

KMS（密钥管理服务）

• Hadoop密钥管理服务（Key ManagementServer，简写KMS），用作HDFS客户端与密钥库之间的代理。
• KMS主要有以下几个职责：
  1.访问加密区域秘钥（EZ key）
  2.生成EDEK，EDEK存储在NameNode上
  3.为HDFS客户端解密EDEK

写入加密文件过程

提前动作：创建加密区，设置加密区密钥

1、Client向NN请求在HDFS某个加密区新建文件；

2、NN从缓存中取出一个新的EDEK（后台不断从KMS拉取新的EDEK到缓存中）；

3、获取到EDEK会被NN保存到文件的元数据中；

4、然后NN将EDEK发送给Client；

5、Client发送EDEK给KMS，KMS用对应的EZ key将EDEK解密出DEK发送给Client；

6、Client用DEK加密文件内容发送给datanode进行存储。

• DEK是加解密一个文件的密匙，而KMS里存储的EZ key是用来加解密所有文件的密匙（DEK）的密匙。
• 所以，EZ Key是更为重要的数据，只在KMS内部使用（DEK的加解密只在KMS内存进行），不会被传递到外面使用；
• 而HDFS服务端只能接触到EDEK。

读取解密文件过程

• 读流程与写流程类型，区别就是NN直接读取加密文件元数据里的EDEK返回给客户端，客户端一样把EDEK发送给KMS获取DEK。再对加密内容解密读取。
• EDEK的加密和解密完全在KMS上进行。更重要的是，请求创建或解密EDEK的客户端永远不会处理EZ密钥。仅KMS可以根据要求使用EZ密钥创建和解密EDEK。

5.5 KMS配置

Step1：关闭HDFS集群

Step2：keystore密钥库

Step3：配置kms-site.xml

Step4：kms-env.sh

Step5：修改core|hdfs-site.xml

Step6：kms服务启动