0 说明
本文基于《CDH数仓项目(一) —— CDH安装部署搭建详细流程》和《CDH数仓项目(二) —— 用户行为数仓和业务数仓搭建》和搭建CDH数仓。本章节主要介绍基于CDH数仓的Kerberos认证和Sentry权限管理
1 Kerberos安全认证
1.1 Kerberos概述
Kerberos是一种计算机网络授权协议，用来在非安全网络中，对个人通信以安全的手段进行身份认证。软件设计上采用客户端/服务器结构，并且能够进行相互认证，即客户端和服务器端均可对对方进行身份认证。可以用于防止窃听、防止重放攻击、保护数据完整性等场合，是一种应用对称密钥体制进行密钥管理的系统。
1.2 Kerberos概念
Kerberos中有以下一些概念需要了解：
1）KDC：密钥分发中心，负责管理发放票据，记录授权。
2）Realm：Kerberos管理领域的标识。
3）principal：当每添加一个用户或服务的时候都需要向kdc添加一条principal，principl的形式为：主名称／实例名@领域名。
4）主名称：主名称可以是用户名或服务名，表示是用于提供各种网络服务（如hdfs，yarn，hive）的主体。
5）实例名：实例名简单理解为主机名。
1.3 Kerberos认证原理
2 Kerberos安装
2.1 server节点安装kerberos相关软件
server节点只需安装一个节点即可，这里安装在chen102节点上
yum install -y krb5-server krb5-workstation krb5-libs
查看安装结果
rpm -qa | grep krb5
2.2 client节点安装
client节点可以安装多个
yum install -y krb5-workstation krb5-libs
2.3 配置Kerberos
需要配置的文件有两个为kdc.conf和krb5.conf , kdc配置只是需要Server服务节点配置，即chen102.
1） kdc配置
vim /var/kerberos/krb5kdc/kdc.conf
说明：
CHEN.COM：realm名称，Kerberos支持多个realm，一般全用大写。
acl_file:admin的用户权。
admin_keytab:KDC进行校验的keytab。
supported_enctypes:支持的校验方式，注意把aes256-cts去掉，JAVA使用aes256-cts验证方式需要安装额外的jar包，所有这里不用
2） krb5文件配置
vim /etc/krb5.conf
修改内容同步到集群其他节点
default_realm：默认的realm，设置 Kerberos 应用程序的默认领域，必须跟要配置的realm的名称一致。
ticket_lifetime：表明凭证生效的时限，一般为24小时。
renew_lifetime ： 表明凭证最长可以被延期的时限，一般为一个礼拜。当凭证过期之后，对安全认证的服务的后续访问则会失败。
udp_preference_limit= 1：禁止使用 udp，可以防止一个 Hadoop 中的错误。
realms：配置使用的 realm，如果有多个领域，只需向 [realms] 节添加其他的语句。
domain_realm：集群域名与Kerberos realm的映射关系，单个realm的情况下，可忽略。
2.4 生成Kerberos数据库
在server节点执行
kdb5_util create -s
创建完成后/var/kerberos/krb5kdc目录下会生成对应的文件
ls /var/kerberos/krb5kdc/
2.5 赋予Kerberos管理员所有权限
vim /var/kerberos/krb5kdc/kadm5.acl
#修改为以下内容：
*/admin@CHEN.COM *
说明：
*/admin：admin实例的全部主体
@HADOOP.COM：realm
*：全部权限
这个授权的意思：就是授予admin实例的全部主体对应CHEN.COM领域的全部权限。也就是创建Kerberos主体的时候如果实例为admin,就具有CHEN.COM领域的全部权限，比如创建如下的主体user1/admin就拥有全部的CHEN.COM领域的权限。
2.6 启动Kerberos服务(server节点执行)
启动krb5kdc
systemctl start krb5kdc
启动kadmin
systemctl start kadmin
设置开机自启
systemctl enable krb5kdc
systemctl enable kadmin
查看是否设置为开机自启
systemctl is-enabled krb5kdc
systemctl is-enabled kadmin
注：启动失败时可以通过/var/log/krb5kdc.log和/var/log/kadmind.log来查看。
2.7 创建管理员主体/实例
kadmin.local -q "addprinc admin/admin"
2.8 kinit管理员验证
kinit admin/admin
klist
其他节点尝试
2.9 Kerberos数据库操作
2.9.1 登录kerberos数据库
1）本地登录（无需认证）
kadmin.local
2）远程登录（需进行主体认证，先认证刚刚创建的管理员主体）
kadmin
2.9.2 创建kerberos主体
kadmin.local -q "addprinc test/test"
2.9.3 修改主体密码
kadmin.local -q "cpw test/test"
2.9.4 查看所有主体
kadmin.local -q "list_principals"
2.10 Kerberos主体认证
Kerberos提供了两种认证方式，一种是通过输入密码认证，另一种是通过keytab密钥文件认证，但两种方式不可同时使用
2.10.1 密码认证
kinit test/test
klist
2.10.2 keytabl密钥文件认证
1）生成主体admin/admin的keytab文件到指定目录/root/admin.keytab
kadmin.local -q "xst -k /root/test.keytab test/test@CHEN.COM"
2）使用keytab进行认证
kinit -kt /root/test.keytab test/test
查看keytab包含的主体名称
klist -ekt /root/test.keytab
3）查看认证凭证
klist
此时通过密码认证就不能再登录了
2.11 销毁认证
kdestroy
klist
3 CDH安装Kerberos
3.1 CDH启用Kerberos安全认证
为CM创建管理员主体/实例
kadmin.local -q "addprinc cloudera-scm/admin"
3.2 CDH页面启动kerberos
3.3 环境确认
3.4 填写配置
Kerberos 加密类型:aes128-cts、des3-hmac-sha1、arcfour-hmac
3.5 填写主题名和密码
3.6 等待导入kdc
3.7 等待重启集群
3.8 查看主体
4 Kerberos安全环境实操
在启用Kerberos之后，系统与系统（flume-kafka）之间的通讯，以及用户与系统（user-hdfs）之间的通讯都需要先进行安全认证，认证通过之后方可进行通讯。
故在启用Kerberos后，数仓中使用的脚本等，均需要加入一步安全认证的操作，才能正常工作。
4.1 用户访问服务认证
开启Kerberos安全认证之后，日常的访问服务（例如访问HDFS，消费Kafka topic等）都需要先进行安全认证
1）在Kerberos数据库中创建用户主体/实例
kadmin.local -q "addprinc hive/hive@CHEN.COM"
2）进行用户认证
kinit hive/hive@CHEN.COM
3）访问HDFS
hadoop fs -ls /
4）hive查询
hive
5）消费Kafka topic
（1）修改Kafka配置
① 在Kafka的配置项搜索“security.inter.broker.protocol”，设置为SALS_PLAINTEXT。
② 在Kafka的配置项搜索“ssl.client.auth”，设置为none。
（2）创建jaas.conf文件
vim /var/lib/hive/jaas.conf
KafkaClient {
com.sun.security.auth.module.Krb5LoginModule required
useTicketCache=true;
};
（3）创建consumer.properties文件
vim /etc/kafka/conf/consumer.properties
文件内容如下
security.protocol=SASL_PLAINTEXT
sasl.kerberos.service.name=kafka
（4）声明jass.conf文件路径
export KAFKA_OPTS="-Djava.security.auth.login.config=/var/lib/hive/jaas.conf"
（5）使用kafka-console-consumer消费Kafka topic数据
kafka-console-consumer --bootstrap-server chen102:9092 --topic topic_start --from-beginning --consumer.config /etc/kafka/conf/consumer.properties
能够正常消费数据
4.2 windows webui浏览器认证
我们设置CDH支持kerberos后会出现下图所示的情况：
可以登录9870，但是不能查看目录及文件，这是由于我们本地环境没有通过认证。
接下来我们设置本地验证。
（1） 下载火狐
（2）设置浏览器
① 打开火狐浏览器，在地址栏输入：about:config，进入设置页面。
② 搜索“network.negotiate-auth.trusted-uris”，修改值为自己的服务器主机名
③ 搜索“network.auth.use-sspi”，双击将值变为false
（3）安装kfw
① 安装提供的kfw-4.1-amd64.msi。
② 将集群的/etc/krb5.conf文件的内容复制到C:\ProgramData\MIT\Kerberos5\krb.ini中，删除和路径相关的配置。
链接：https://pan.baidu.com/s/1sMmqTbVcVhNQubjQR5CrCQ
提取码：amo6
文件内容：
[logging]
[libdefaults]
default_realm = CHEN.COM
dns_lookup_realm = false
dns_lookup_kdc = false
ticket_lifetime = 24h
renew_lifetime = 7d
forwardable = true
udp_preference_limit = 1
[realms]
CHEN.COM = {
kdc = chen102
admin_server = chen102
}
[domain_realm]
③ 打开MIT，输入主体名和密码：
④ 测试
4.3 用户行为数仓
4.3.1 日志采集Flume配置
日志采集Flume，数据被发送到了Kafka，该Flume相当于一个Kafka生产者。所以需要我们进行上述Kafka客户端的安全认证。但是此处不需要我们进行手动配置，在开启Kerberos后，CM会自动进行配置。
4.3.2 消费Kafka Flume配置
消费Kafka Flume，将数据从Kafka传输到HDFS，该Flume相当于一个Kafka消费者。所以也需要我们进行上述Kafka客户端的安全认证（无需手动认证，CM会自动进行配置）。除此之外，我们还需要进行HDFS客户端的安全认证，这需要我们手动配置。
（1）生成hive用户的keytab文件
用户认证的方式有“输入密码”和“使用keytab密钥文件”两种方式，此处需使用keytab密钥文件进行认证。
kadmin.local -q "xst -k /var/lib/hive/hive.keytab hive/hive@CHEN.COM"
（2）增加读权限
chmod +r /var/lib/hive/hive.keytab
（3）分发keytab文件
（4）修改flume agent配置文件
## 组件
a1.sources=r1 r2
a1.channels=c1 c2
a1.sinks=k1 k2
## source1
a1.sources.r1.type = org.apache.flume.source.kafka.KafkaSource
a1.sources.r1.batchSize = 5000
a1.sources.r1.batchDurationMillis = 2000
a1.sources.r1.kafka.bootstrap.servers = chen102:9092,chen103:9092,chen104:9092
a1.sources.r1.kafka.topics=topic_start
## source2
a1.sources.r2.type = org.apache.flume.source.kafka.KafkaSource
a1.sources.r2.batchSize = 5000
a1.sources.r2.batchDurationMillis = 2000
a1.sources.r2.kafka.bootstrap.servers = chen102:9092,chen103:9092,chen104:9092
a1.sources.r2.kafka.topics=topic_event
## channel1
a1.channels.c1.type=memory
a1.channels.c1.capacity=100000
a1.channels.c1.transactionCapacity=10000
## channel2
a1.channels.c2.type=memory
a1.channels.c2.capacity=100000
a1.channels.c2.transactionCapacity=10000
## sink1
a1.sinks.k1.type = hdfs
#a1.sinks.k1.hdfs.proxyUser=hive
a1.sinks.k1.hdfs.kerberosPrincipal=hive/hive@CHEN.COM
a1.sinks.k1.hdfs.kerberosKeytab=/var/lib/hive/hive.keytab
a1.sinks.k1.hdfs.path = /origin_data/gmall/log/topic_start/%Y-%m-%d
a1.sinks.k1.hdfs.filePrefix = logstart-
a1.sinks.k1.hdfs.round = true
a1.sinks.k1.hdfs.roundValue = 10
a1.sinks.k1.hdfs.roundUnit = second
##sink2
a1.sinks.k2.type = hdfs
#a1.sinks.k2.hdfs.proxyUser=hive
a1.sinks.k2.hdfs.kerberosPrincipal=hive/hive@CHEN.COM
a1.sinks.k2.hdfs.kerberosKeytab=/var/lib/hive/hive.keytab
a1.sinks.k2.hdfs.path = /origin_data/gmall/log/topic_event/%Y-%m-%d
a1.sinks.k2.hdfs.filePrefix = logevent-
a1.sinks.k2.hdfs.round = true
a1.sinks.k2.hdfs.roundValue = 10
a1.sinks.k2.hdfs.roundUnit = second
## 不要产生大量小文件
a1.sinks.k1.hdfs.rollInterval = 10
a1.sinks.k1.hdfs.rollSize = 134217728
a1.sinks.k1.hdfs.rollCount = 0
a1.sinks.k2.hdfs.rollInterval = 10
a1.sinks.k2.hdfs.rollSize = 134217728
a1.sinks.k2.hdfs.rollCount = 0
## 控制输出文件是原生文件。
a1.sinks.k1.hdfs.fileType = CompressedStream
a1.sinks.k2.hdfs.fileType = CompressedStream
a1.sinks.k1.hdfs.codeC = lzop
a1.sinks.k2.hdfs.codeC = lzop
## 拼装
a1.sources.r1.channels = c1
a1.sinks.k1.channel= c1
a1.sources.r2.channels = c2
a1.sinks.k2.channel= c2
配置成功后，重启flume，执行采集脚本验证是否能正常采集。查看hdfs可看到如下页面，说明已经可以正常采集
4.3.3 ods层
ods_log.sh添加如下内容：
kinit -kt /var/lib/hive/hive.keytab hive/hive
beeline -u "jdbc:hive2://chen102:10000/;principal=hive/chen102@CHEN.COM" -n hive -e "$sql"
4.3.4 dwd层
dwd_start_log.sh
kinit -kt /var/lib/hive/hive.keytab hive/hive
beeline -u "jdbc:hive2://chen102:10000/;principal=hive/chen102@CHEN.COM" -n hive -e "$sql"
4.3.5 dws层
dws_log.sh
kinit -kt /var/lib/hive/hive.keytab hive/hive
beeline -u "jdbc:hive2://chen102:10000/;principal=hive/chen102@CHEN.COM" -n hive -e "$sql"
4.3.6 ads层
ads_uv_log.sh
kinit -kt /var/lib/hive/hive.keytab hive/hive
beeline -u "jdbc:hive2://chen102:10000/;principal=hive/chen102@CHEN.COM" -n hive -e "$sql"
4.4 业务数仓
分别向业务数仓中添加kerberos认证
4.4.1 sqoop导入
sqoop_import.sh
kinit -kt /var/lib/hive/hive.keytab hive/hive
4.4.2 ods层
ods_db.sh
kinit -kt /var/lib/hive/hive.keytab hive/hive
beeline -u "jdbc:hive2://chen102:10000/;principal=hive/chen102@CHEN.COM" -n hive -e "$sql"
4.4.3 dwd层
dwd_db.sh
kinit -kt /var/lib/hive/hive.keytab hive/hive
beeline -u "jdbc:hive2://chen102:10000/;principal=hive/chen102@CHEN.COM" -n hive -e "$sql"
4.4.4 dws层
dws_db_wide.sh
kinit -kt /var/lib/hive/hive.keytab hive/hive
beeline -u "jdbc:hive2://chen102:10000/;principal=hive/chen102@CHEN.COM" -n hive -e "$sql"
4.4.5 ads层
ads_db_gmv.sh
kinit -kt /var/lib/hive/hive.keytab hive/hive
beeline -u "jdbc:hive2://chen102:10000/;principal=hive/chen102@CHEN.COM" -n hive -e "$sql"
4.4.6 sqoop导出
kinit -kt /var/lib/hive/hive.keytab hive/hive
4.5 测试运行
4.5.1 hdfs新建目录
hadoop fs -mkdir /user/hive/bin_kerberos
4.5.2 上传最新脚本到hdfs目录
4.5.3 造数据
4.5.4 hue页面新建调度任务
4.5.6 查看执行结果
5 Sentry
5.1 sentry概述
cdh版本的hadoop在对数据安全上的处理通常采用Kerberos+Sentry的结构。kerberos主要负责平台用户的用户认证，sentry则负责数据的权限管理。
5.2 Sentry 是什么
Apache Sentry是Cloudera公司发布的一个Hadoop开源组件，它提供了细粒度级、基于角色的授权以及多租户的管理模式。
Sentry提供了对Hadoop集群上经过身份验证的用户和应用程序的数据控制和强制执行精确级别权限的功能。Sentry目前可以与Apache Hive，Hive Metastore / HCatalog，Apache Solr，Impala和HDFS（仅限于Hive表数据）一起使用。
Sentry旨在成为Hadoop组件的可插拔授权引擎。它允许自定义授权规则以验证用户或应用程序对Hadoop资源的访问请求。Sentry是高度模块化的，可以支持Hadoop中各种数据模型的授权
5.3 Sentry安装部署
5.3.1 添加Sentry服务
5.3.2 自定义sentry角色
5.3.3 配置数据库连接
5.3.4 完成sentry服务添加
5.4 sentry与Hive集成
5.4.1 修改配置参数
（1）取消HiveServer2用户模拟
在hive配置项中搜索“HiveServer2 启用模拟”，取消勾选
（2）确保hive用户能够提交MR任务
在yarn配置项中搜索“允许的系统用户”，确保包含“hive”。
（3）在Hive配置项中搜索“启用数据库中的存储通知”，勾选。
（4）在Hive配置项中搜索“Sentry”，勾选Sentry。
5.5 sentry与impala配置
在Impala配置项中搜索“Sentry”，勾选。
5.6 HDFS配置sentry
1）在HDFS配置项中搜索“启用访问控制列表”，勾选。
2）在HDFS配置项中搜索“启用 Sentry 同步”，做出下图修改。
5.7 sentry与hue
1）配置HUE支持Sentry
在HUE配置项中搜索“Sentry”，勾选Sentry。
6 sentry权限认证测试
6.1 通过HUE操作
1）查看Sentry权限管理中的管理员组。
在Sentry的配置项中搜索“管理员组”，其中包括hive、impala，只有当某用户所属组位于其中时，才可为其他用户授予权限。
2）在Hive集群所有节点创建两个用户reader，writer，为权限测试做准备。
useradd reader
passwd reader
useradd writer
passwd writer
3）使用hive用户登录HUE，创建两个用户组reader、writer，并在两个用户组下创建两个用户reader、writer，为权限测试做准备。
4）Sentry工作界面（需要授予HUE用户访问Sentry的权限）
5）点击Roles按钮，并点击添加按钮
6）编辑Role
admin_role（首先为hive用户添加管理员权限）
reader_role
writer_role
7）权限测试
（1）分别使用reader和writer用户登录HUE
（2）查询gmall数据库中的任意一张表，发现只有reader用户可查出，而writer则不能。说明权限控制生效。
reader用户，具有查询权限
reader用户，不具备插入数据权限
writer用户不具备查询权限
writer用户具备插入权限
6.2 命令行操作
1）在Hive集群所有节点创建两个用户reader_cmd，writer_cmd
useradd reader_cmd
passwd reader_cmd
useradd writer_cmd
passwd writer_cmd
2）使用Sentry管理员用户hive通过beeline客户端连接HiveServer2
kinit -kt /var/lib/hive/hive.keytab hive/hive@CHEN.COM
beeline -u "jdbc:hive2://chen102:10000/;principal=hive/chen102@CHEN.COM"
① 创建Role（reader_role_cmd,writer_role_cmd）
create role reader_role_cmd;
create role writer_role_cmd;
② 为role赋予privilege
GRANT select ON DATABASE gmall TO ROLE reader_role_cmd;
GRANT insert ON DATABASE gmall TO ROLE writer_role_cmd;
③ 将role授予用户组
GRANT ROLE reader_role_cmd TO GROUP reader_cmd;
GRANT ROLE writer_role_cmd TO GROUP writer_cmd;
执行上述命令后，在hue页面也能查看到当前新建的角色
④ 查看权限授予情况
（1）查看所有role（管理员）
SHOW ROLES;
（2）查看指定用户组的role（管理员）
SHOW ROLE GRANT GROUP reader_cmd;
（3）查看当前认证用户的role
SHOW CURRENT ROLES;
（4）查看指定ROLE的具体权限（管理员）
SHOW GRANT ROLE reader_role_cmd;
⑤ 权限测试
（1）为reader_cmd、writer_cmd创建Kerberos主体
kadmin.local -q "addprinc reader_cmd/reader_cmd@CHEN.COM"
kadmin.local -q "addprinc writer_cmd/writer_cmd@CHEN.COM"
（2）使用reader_cmd登录HiveServer2，查询gmall库下的任意一张表
kinit reader_cmd/reader_cmd@CHEN.COM
beeline -u "jdbc:hive2://chen102:10000/;principal=hive/chen102@CHEN.COM"
具有查询权限
不具备插入权限
（3）使用writer_cmd登录HiveServer2，查询gmall库下的任意一张表
kinit writer_cmd/writer_cmd@CHEN.COM
beeline -u "jdbc:hive2://chen102:10000/;principal=hive/chen102@CHEN.COM"
writer_cmd不具备查询表权限
writer_cmd具备插入表权限
（4）查询结果
reader_cmd有对于gmall表的查询权限，而writer_cmd没有。说明授权生效。
后面是对CDH数仓项目性能测试及清理CDH集群操作，详见
《CDH数仓项目(四) —— 集群性能测试/资源管理/清理CDH集群》
1740
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
