HDFS数据安全与隐私保护
一、HDFS Trash垃圾桶
1.文件系统垃圾桶背景
HDFS本身也是一个文件系统，那么就会涉及到文件数据的删除操作。
默认情况下，HDFS中是没有回收站垃圾桶概念的，删除操作的数据将会被直接删除，没有后悔药。
2.功能概述
1.HDFS Trash机制，叫做回收站或者垃圾桶。Trash就像Windows操作系统中的回收站一样。它的目的是防止你无意中删除某些东西。默认情况下是不开启的。
2.启用Trash功能后，从HDFS中删除某些内容时，文件或目录不会立即被清除，它们将被移动到回收站Current目录中(/user/${username}/.Trash/current)。
3.Trash中的文件在用户可配置的时间延迟后被永久删除。
4.也可以简单地将回收站里的文件移动到.Trash目录之外的位置来恢复回收站中的文件和目录。
Trash Checkpoint
检查点仅仅是用户回收站下的一个目录，用于存储在创建检查点之前删除的所有文件或目录。
回收站目录在/user/${username}/.Trash/{timestamp_of_checkpoint_creation}
最近删除的文件被移动到回收站Current目录，并且在可配置的时间间隔内，HDFS会为在Current回收站目录下的文件创建检查点/user/${username}/.Trash/<日期>，并在过期时删除旧的检查点。
3.开启Trash功能
修改core-site.xml文件，添加下面两个属性
fs.trash.interval：回收站中的文件多少分钟后会被系统永久删除。如果为零，Trash功能将被禁用。
fs.trash.checkpoint.interval：前后两次检查点的创建时间间隔（单位也是分钟），新的检查点被创建后，随之旧的检查点就会被系统永久删除。如果为零，则将该值设置为fs.trash.interval的值。
同步集群配置文件，重启HDFS
stop-dfs.sh
start-dfs.sh
4.Trash功能使用
4.1 删除文件到Trash
开启Trash功能后，正常执行删除操作，文件实际并不会被直接删除，而是被移动到了垃圾回收站。
删除文件跳过Trash、直接删除
有的时候，我们希望直接把文件删除，不需要再经过Trash回收站了。
可以在执行删除操作的时候添加一个参数：-skipTrash.
4.2 从Trash中恢复文件
回收站里面的文件，在到期被自动删除之前，都可以通过命令恢复出来。
使用mv、cp命令把数据文件从Trash目录下复制移动出来就可以了。
4.3 清空Trash
1.除了fs.trash.interval参数控制到期自动删除之外，用户还可以通过命令手动清空回收站，释放HDFS磁盘存储空间。
2.删除整个回收站目录，将会清空回收站,这是一个选择。
3.此外。HDFS提供了一个命令行工具来完成这个工作：hadoop fs -expunge。该命令立即从文件系统中删除过期的检查点。
二、HDFS Snapshot快照
1.快照概述及作用
1.1 概述
可以将快照理解为拍照片时的那一瞬间的投影。
快照（Snapshot）是数据存储的某一时刻的状态记录；备份（Backup）则是数据存储的某一个时刻的副本。
HDFS Snapshot快照是整个文件系统或某个目录在某个时刻的镜像。该镜像并不会随着源目录的改变而进行动态的更新。
1.2 快照作用
数据恢复
对重要目录进行创建snapshot的操作，当用户误操作时，可以通过snapshot来进行相关的恢复操作。
数据备份
使用snapshot来进行整个集群，或者某些目录、文件的备份。管理员以某个时刻的snapshot作为备份的起始结点，然后通过比较不同备份之间差异性，来进行增量备份。
数据测试
在某些重要数据上进行测试或者实验，可能会直接将原始的数据破坏掉。可以临时的为用户针对要操作的数据来创建一个snapshot，然后让用户在对应的snapshot上进行相关的实验和测试，从而避免对原始数据的破坏。
2.快照功能实现
1 HDFS快照不是数据的简单拷贝，只做差异的记录。
2 对于大多不变的数据，你所看到的数据其实是当前物理路径所指的内容，而发生变更的inode数据才会被快照额外拷贝，也就是所说的差异拷贝。
3 inode指索引节点，用来存放文件及目录的基本信息，包含时间、名称、拥有者、所在组等。
4 HDFS快照不会复制datanode中的块，只记录了块列表和文件大小。
5 HDFS快照不会对常规HDFS操作产生不利影响，修改记录按逆时针顺序进行，因此可以直接访问当前数据。通过从当前数据中减去修改来计算快照数据。
3.快照相关命令
3.1 启用快照功能
1 HDFS中可以针对整个文件系统或者某个目录创建快照，但是创建快照的前提是相应的目录开启快照的功能。
2 如果针对没有启动快照功能的目录创建快照则会报错
3.2 禁用快照功能
gHDFS中可以针对已经开启快照功能的目录进行禁用快照功能的设置
禁用的前提是该目录的所有快照已经被删除
3.3 快照操作相关命令
createSnapshot 创建快照
deleteSnapshot 删除快照
renameSnapshot 重命名快照
lsSnapshottableDir 列出可以快照目录列表
snapshotDiff 获取快照差异报告。
4.快照使用示例
4.1 开启指定目录快照功能
4.2 创建快照
4.3 HDFS Web UI查询集群快照信息
4.4 Web页面浏览快照
4.5 重命名快照
#重命名快照 hdfs dfs -renameSnapshot /allenwoon mysnap1 mysnap2
4.6 列出HDFS集群所有开启快照功能的目录
4.7 快照间差异比较
不同版本快照准备
[root@node1 ~]# echo 222 > 2.txt
[root@node1 ~]# hadoop fs -appendToFile 2.txt /allenwoon/1.txt
[root@node1 ~]# hadoop fs -cat /allenwoon/1.txt
1
222
[root@node1 ~]# hdfs dfs -createSnapshot /allenwoon mysnap3
Created snapshot /allenwoon/.snapshot/mysnap3
[root@node1 ~]# hadoop fs -put zookeeper.out /allenwoon
[root@node1 ~]# hdfs dfs -createSnapshot /allenwoon mysnap4
Created snapshot /allenwoon/.snapshot/mysnap4
快照间差异比较
#比较指定目录两个版本快照之间的差异
hdfs snapshotDiff /allenwoon mysnap2 mysnap3
结果
5.删除快照
#删除指定快照
hdfs dfs -deleteSnapshot /allenwoon mysnap4
6.删除开启快照功能的目录
hadoop fs -rm -r /allenwoon #拥有快照的目录不允许被删除，某种程度上也保护了文件安全
三、HDFS 权限管理
1.HDFS权限管理概述
1 作为分布式文件系统，HDFS也集成了一套权限管理系统。
2 客户端在进行每次文件操时，系统会从用户身份认证和数据访问授权两个环节进行验证。
3 客户端的操作请求会首先通过用户身份验证机制来获得“凭证”（类似于身份证书）,HDFS根据此“凭证”分辨出合法的用户名;
4 然后HDFS再据此查看该用户所访问的数据是否已经授权,或者说该身份凭证是否具有权限做这件事。
5 一旦这个流程中的某个环节出现异常，客户端的操作请求便会失败。
2.HDFS UGO权限管理
2.1 拥有者、所在组、其他用户组
HDFS文件权限与Linux/Unix系统的UGO模型类似，简单描述为：每个文件和目录都与一个拥有者和一个组相关联。
USER（文件的所有者）：一般是创建该文件的用户，对该文件具有完全的权限。
GROUP（拥有者所在的组）：和文件所有者属于同一组的用户。
OTHER（其他用户组）：其他用户组的用户。
2.2 读、写、执行权限
1 HDFS文件权限也细分为：读权限（r）、写权限（w）、执行权限（x）。
2 在HDFS中，对于文件，需要r权限才能读取文件，而w权限才能写入或追加到文件。没有x可执行文件的概念。
3 在HDFS中，对于目录，需要r权限才能列出目录的内容，需要w权限才能创建或删除文件或目录，并且需要x权限才能访问目录的子级。
2.3 UGO权限相关命令
#变更目录或文件的权限 可以使用数字 也可以使用字母 u g o a + - r w
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权限
3. HDFS用户身份认证
在HDFS中，用户身份认证独立于HDFS项目之外，也就说HDFS并不负责用户身份合法性检查。
但HDFS会通过相关接口来获取相关的用户身份，然后用于后续的权限管理。
用户是否合法，完全取决于集群使用认证体系。目前社区支持两种身份认证，即简单认证（Simple）和Kerberos。
由hadoop.security.authentication属性指定，默认simple。
3.1 Simple认证
基于HDFS客户端所在的Linux/Unix系统的登录用户名来进行认证。只要用户能正常登录就认证成功。
客户端与NN交互时，会将用户的登录账号（通过类似whoami的命令来获取）作为合法用户名传递至NN。
3.2 Kerberos
pass,自行百度
4.ACL权限管理
在实际工作中，使用UGO来控制权限可以满足大部分场景下的数据安全性要求，但是对于一些复杂的权限需求则无能为力。
4.1 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的任何文件或目录的权限字符串后附加一个'+'字符
4.2 示例
1.使用root超级用户在HDFS上创建一个文件夹
hadoop fs -mkdir /itheima
2.使用普通用户allenwoon去操作/itheima 发现没有权限
[allenwoon@node1 ~]$ echo 1 >> 1.txt
[allenwoon@node1 ~]$ hadoop fs -put 1.txt /itheima
put: Permission denied: user=allenwoon, access=WRITE, inode="/itheima":root:supergroup:drwxr-xr-x
3.接下来使用ACL给allenwoon用户单独添加权限 而/itheima文件夹本身权限不变
hadoop fs -setfacl -m user:allenwoon:rwx /itheima
setfacl: The ACL operation has been rejected. Support for ACLs has been disabled by setting dfs.namenode.acls.enabled to false.
4.发现报错 原因是ACL功能默认是关闭的。在hdfs-site.xml中设置dfs.namenode.acls.enabled=true 开启ACL，重启HDFS集群
5.设置成功之后查看ACL权限
hadoop fs -getfacl /itheima
[root@node1 ~]# hadoop fs -getfacl /itheima
# file: /itheima
# owner: root
# group: supergroup
user::rwx
user:allenwoon:rwx # 发现allenwoon权限配置成功
group::r-x
mask::rwx
other::r-x
6.再使用普通用户allenwoon去操作，发现可以成功了.如果切换其他普通用户比如itcast 发现还是无法操作
[itcast@node2 ~]$ echo 2 >> 2.txt
[itcast@node2 ~]$ hadoop fs -put 2.txt /itheima
put: Permission denied: user=itcast, access=WRITE, inode="/itheima":root:supergroup:drwxrwxr-x
4.3 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
四、HDFS Proxy user代理用户
1.背景介绍
Proxy中文称之为代理、委托。用来进行事物不想或不能进行的其他操作。
HDFS Proxy user（代理用户）描述的是一个用户（比如超级用户）如何代表另一个用户提交作业或访问HDFS。
比如：用户名为“Admin”的超级用户代表用户Allen提交作业并访问HDFS。
因为超级用户Admin具有kerberos凭证，但Allen用户没有任何凭证。这些任务需要以用户Allen的身份运行，而对namenode的任何文件访问都必须以用户Allen的身份进行。
要求用户Allen可以在通过Admin的kerberos凭据进行身份验证的连接上连接到namenode。换句话说， Admin正在冒充用户Allen 。
2.使用示例
Admin的身份凭据用于登录，并为Allen创建了代理用户ugi对象。
在代理用户ugi对象的doAs方法内执行操作。
3.配置参数
可以通过在core-site.xml中使用下面属性来配置代理用户：
hadoop.proxyuser.$superuser.hosts
hadoop.proxyuser.$superuser.groups
通过通配符*可用于允许来自任何主机或任何用户的模拟
配置示例
例如：名为super的超级用户只能从host1和host2连接来模拟属于group1和group2的用户。
<property>
<name>hadoop.proxyuser.super.hosts</name>
<value>host1,host2</value>
</property>
<property>
<name>hadoop.proxyuser.super.groups</name>
<value>group1,group2</value>
</property>
# 从任何主机访问的名为oozie的用户都可以假冒属于任何组的任何用户
<property>
<name>hadoop.proxyuser.oozie.hosts</name>
<value>*</value>
</property>
<property>
<name>hadoop.proxyuser.oozie.groups</name>
<value>*</value>
</property>
五、HDFS 透明加密
1.HDFS明文存储弊端
HDFS中的数据会以block的形式保存在各台数据节点的本地磁盘中，但这些block都是明文的。
通过Web UI页面找到Block的ID和副本位于的机器信息
如果在操作系统下，直接访问block所在的目录，通过Linux的cat命令是可以直接查看里面的内容的，且是明文
2.HDFS透明加密介绍
HDFS透明加密（Transparent Encryption）支持端到端的透明加密，启用以后，对于一些需要加密的HDFS目录里的文件可以实现透明的加密和解密，
而不需要修改用户的业务代码。端到端是指加密和解密只能通过客户端。
对于加密区域里的文件，HDFS保存的即是加密后的文件，文件加密的秘钥也是加密的。让非法用户即使从操作系统层面拷走文件，也是密文，没法查看。
特点
1.HDFS集群管理和密钥的管理是互相独立的职责，由不同的用户角色（HDFS管理员，密钥管理员）承担
2.只有HDFS客户端可以加密或解密数据，密钥管理在HDFS外部，HDFS无法访问未加密的数据或加密密钥
3.block在操作系统是以加密的形式存储的，从而减轻了操作系统和文件系统级别的安全威胁
4.HDFS使用AES-CTR加密算法。AES-CTR支持128位加密密钥（默认）
3.HDFS透明加密关键概念和架构
3.1 加密区域
HDFS的透明加密有一个新的概念，加密区域（the encryption zone）。
加密区域就是HDFS上的一个目录，只不过该目录比其他目录特殊。
加密区域里写入文件的时候会被透明加密，读取文件的时候又会被透明解密。
3.2 秘钥
当加密区域被创建时，都会有一个加密区域秘钥（EZ密钥，encryption zone key）与之对应，EZ密钥存储在HDFS外部的密钥库中。
加密区域里的每个文件都有其自己加密密钥，叫做数据加密秘钥（DEK，data encryption key）。
DEK会使用其各自的加密区域的EZ密钥进行加密，以形成加密数据加密密钥（EDEK）。
3.3 密钥库（keystore）
存储密钥（key）的叫做密钥库（keystore）,将HDFS与外部企业级密钥库（keystore）集成是部署透明加密的第一步。
这是因为密钥（key）管理员和HDFS管理员之间的职责分离是此功能的非常重要的方面。
但是，大多数密钥库都不是为Hadoop工作负载所见的加密/解密请求速率而设计的。
3.4 KMS（密钥管理服务）
Hadoop密钥管理服务（Key Management Server，简写KMS），用作HDFS客户端与密钥库之间的代理。
KMS主要有以下几个职责：
1.访问加密区域秘钥（EZ key）
2.生成EDEK，EDEK存储在NameNode上
3.为HDFS客户端解密EDEK
4.加密及解密文件过程
4.1 加密文件过程
提前动作：创建加密区，设置加密区密钥
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。
4.2 读取解密文件过程
读流程与写流程类型，区别就是NN直接读取加密文件元数据里的EDEK返回给客户端，客户端一样把EDEK发送给KMS获取DEK。再对加密内容解密读取。
EDEK的加密和解密完全在KMS上进行。更重要的是，请求创建或解密EDEK的客户端永远不会处理EZ密钥。仅KMS可以根据要求使用EZ密钥创建和解密EDEK。
5.KMS配置
5.1 keystore密钥库
存储密钥（key）的地方叫做密钥库（keystore）。
HDFS与keystore是互相独立的，两者之间通过KMS进行沟通。
KMS可以选择任何KeyProvider（密钥供应者）实现作为keystore 。
此处的示例使用JavaKeyStoreProvider来作为keystore。
https://hadoop.apache.org/docs/r3.1.4/hadoop-project-dist/hadoop-common/CredentialProviderAPI.html#Keystore_Passwords
5.2 创建keystore
#密钥库的名字叫做itcast，访问密钥库的密码是：123456。
keytool -genkey -alias 'itcast_keystore'
5.3 配置kms-site.xml
<configuration>
<property>
<name>hadoop.kms.key.provider.uri</name> # 设置密钥库的提供者 这里设置jceks，表示就是java密钥库。
<value>jceks://file@/${user.home}/kms.jks</value>
</property>
<property>
<name>hadoop.security.keystore.java-keystore-provider.password-file</name>
<value>kms.keystore.password</value>
</property>
<property>
<name>dfs.encryption.key.provider.uri</name>
<value>kms://http@node1:16000/kms</value>
</property>
<property>
<name>hadoop.kms.authentication.type</name>
<value>simple</value>
</property>
</configuration>
5.4 配置kms密码文件(kms.keystore.password 上一步配置文件中定义)
KMS访问java密钥库的密码文件需配置在Hadoop的配置目录下,在该文件中填写keystore的密码，此处为123456
5.5 配置 kms-env.sh
export KMS_HOME=/export/server/hadoop-3.1.4 #hadoop 安装目录
export KMS_LOG=${KMS_HOME}/logs/kms
export KMS_HTTP_PORT=16000
export KMS_ADMIN_PORT=16001
5.6 修改core|hdfs-site.xml
core-site.xml
<property>
<name>hadoop.security.key.provider.path</name>
<value>kms://http@node1:16000/kms</value>
</property>
hdfs-site.xml
<property>
<name>dfs.encryption.key.provider.uri</name>
<value>kms://http@node1:16000/kms</value>
</property>
5.7 同步配置
5.8 启动kms服务(KMSWebServer)
6.HDFS透明加密使用
6.1 创建key
创建的key用于后面创建加密空间时，指定加密空间的EZ key。
hadoop key create ezk
hadoop key list -metadata
5.2 创建加密区
首先创建一个目录，然后把该目录设置为加密区
hadoop fs -mkdir /zone
hdfs crypto -createZone -keyName ezk -path /zone
5.3 测试加密效果
上传文件到加密区，然后读取文件内容
echo helloitcast >> helloWorld
hadoop fs -put helloWorld /zone
hadoop fs -cat /zone/helloWorld
获取文件加密信息
hdfs crypto -getFileEncryptionInfo -path /zone/helloWorld
切换不同用户进行文件读取操作只要具备read权限都可以读取文件的内容。也就是对客户端来说是透明的，感觉不到文件被加密。
如果直接从DataNode的机器的本地文件系统读取Block信息。发现是无法读取数据的。因为在存储数据的时候被加密了。
"一劳永逸" 的话，有是有的，而 "一劳永逸" 的事却极少
