CDH配置Kerberos和Sentry详解

1.安全之Kerberos安全认证

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）实例名：实例名简单理解为主机名。

关于 Kerberos 更多的原理讲解可参考以下链接：

看完您如果还不明白 Kerberos 原理，算我输！ - 腾讯云开发者社区-腾讯云

1.3 Kerberos认证原理

2 Kerberos安装

2.1 server节点安装kerberos相关软件

[root@m1 ~]#  yum install -y krb5-server krb5-workstation krb5-libs

#查看结果

[root@m1~]# rpm -qa | grep krb5

krb5-workstation-1.10.3-65.el6.x86_64
krb5-libs-1.10.3-65.el6.x86_64
krb5-server-1.10.3-65.el6.x86_64

2.2 client节点安装

[root@s1 ~]# yum install -y krb5-workstation krb5-libs

[root@s2 ~]#  yum install -y krb5-workstation krb5-libs

#查看结果

[root@s1 ~]# rpm -qa | grep krb5
krb5-workstation-1.10.3-65.el6.x86_64
krb5-libs-1.10.3-65.el6.x86_64

2.3 配置kerberos

需要配置的文件有两个为kdc.conf和krb5.conf , kdc配置只是需要Server服务节点配置，即m1

1） kdc配置

[root@m1 ~]#

[root@m1 ~]# vim /var/kerberos/krb5kdc/kdc.conf

[kdcdefaults]
 kdc_ports = 88
 kdc_tcp_ports = 88

[realms]
 HADOOP.COM = {
  #master_key_type = aes256-cts
  acl_file = /var/kerberos/krb5kdc/kadm5.acl
  dict_file = /usr/share/dict/words
  admin_keytab = /var/kerberos/krb5kdc/kadm5.keytab
  max_life = 1d
  max_renewable_life = 7d
  supported_enctypes = aes128-cts:normal des3-hmac-sha1:normal arcfour-hmac:normal camellia256-cts:normal camellia128-cts:normal des-hmac-sha1:normal des-cbc-md5:normal des-cbc-crc:normal
 }

​编辑
说明：

HADOOP.COM：realm名称，Kerberos支持多个realm，一般全用大写。

acl_file:admin的用户权。

admin_keytab:KDC进行校验的keytab。

supported_enctypes:支持的校验方式，注意把aes256-cts去掉，JAVA使用aes256-cts验证方式需要安装额外的jar包，所有这里不用。

2） krb5文件配置

[root@m1 ~]# vim /etc/krb5.conf

includedir /etc/krb5.conf.d/

[logging]
 default = FILE:/var/log/krb5libs.log
 kdc = FILE:/var/log/krb5kdc.log
 admin_server = FILE:/var/log/kadmind.log

[libdefaults]
 dns_lookup_realm = false
 ticket_lifetime = 24h
 renew_lifetime = 7d
 forwardable = true
 rdns = false
 pkinit_anchors = /etc/pki/tls/certs/ca-bundle.crt
 default_realm = HADOOP.COM
 #default_ccache_name = KEYRING:persistent:%{uid}
 udp_preference_limit = 1
[realms]
 HADOOP.COM = {
  kdc = m1.test.com
  admin_server = m1.test.com
}

[domain_realm]
# .example.com = EXAMPLE.COM
# example.com = EXAMPLE.COM

​编辑
说明：

default_realm：默认的realm，设置 Kerberos 应用程序的默认领域，必须跟要配置的realm的名称一致。

ticket_lifetime：表明凭证生效的时限，一般为24小时。

renew_lifetime ： 表明凭证最长可以被延期的时限，一般为一个礼拜。当凭证过期之后，对安全认证的服务的后续访问则会失败。

udp_preference_limit= 1：禁止使用 udp，可以防止一个 Hadoop 中的错误。

realms：配置使用的 realm，如果有多个领域，只需向 [realms] 节添加其他的语句。

domain_realm：集群域名与Kerberos realm的映射关系，单个realm的情况下，可忽略。

3）同步krb5到Client节点

[root@m1 ~]#

[root@m1 ~]# xsync /etc/krb5.conf

2.4 生成Kerberos数据库

​ 在server节点执行

[root@m1 ~]# kdb5_util create -s
Loading random data
Initializing database '/var/kerberos/krb5kdc/principal' for realm 'HADOOP.COM',
master key name 'K/[email protected]'
You will be prompted for the database Master Password.
It is important that you NOT FORGET this password.
Enter KDC database master key: （输入密码）
Re-enter KDC database master key to verify:（确认密码）

创建完成后/var/kerberos/krb5kdc目录下会生成对应的文件

[root@m1 ~]# ls /var/kerberos/krb5kdc/
kadm5.acl  kdc.conf  principal  principal.kadm5  principal.kadm5.lock  principal.ok

2.5 赋予Kerberos管理员所有权限

[root@m1 ~]# vim /var/kerberos/krb5kdc/kadm5.acl

#修改为以下内容：
*/[email protected]      *

说明：

*/admin：admin实例的全部主体

@HADOOP.COM：realm

*：全部权限

这个授权的意思：就是授予admin实例的全部主体对应HADOOP.COM领域的全部权限。也就是创建Kerberos主体的时候如果实例为admin,就具有HADOOP.COM领域的全部权限，比如创建如下的主体user1/admin就拥有全部的HADOOP.COM领域的权限。

2.6 启动Kerberos服务

启动krb5kdc
[root@m1 ~]# systemctl start krb5kdc
正在启动 Kerberos 5 KDC：                                  [确定]

#启动kadmin
[root@m1 ~]# systemctl start kadmin
正在启动 Kerberos 5 Admin Server：                         [确定]

#设置开机自启
[root@m1 ~]# systemctl enable krb5kdc
#查看是否设置为开机自启
[root@node02 ~]# systemctl is-enabled krb5kdc

[root@m1 ~]# systemctl enable kadmin
#查看是否设置为开机自启
[root@m1 ~]# systemctl is-enabled kadmin

注意：启动失败时可以通过/var/log/krb5kdc.log和/var/log/kadmind.log来查看。

2.7 创建管理员主体/实例

root@m1 ~]# kadmin.local -q "addprinc admin/admin"
Authenticating as principal root/[email protected] with password.
WARNING: no policy specified for admin/[email protected]; defaulting to no policy
Enter password for principal "admin/[email protected]": （输入密码）
Re-enter password for principal "admin/[email protected]": （确认密码）
Principal "admin/[email protected]" created.

2.8 kinit管理员验证

[root@m1 ~]# kinit admin/admin
Password for admin/[email protected]: （输入密码）
[root@m1 ~]# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: admin/[email protected]

Valid starting     Expires            Service principal
08/27/19 14:41:39  08/28/19 14:41:39  krbtgt/[email protected]
        renew until 08/27/19 14:41:39

出现以上admin/[email protected]说明没问题

在其他机器尝试：

[root@m1 ~]# kinit admin/admin
Password for admin/[email protected]: （输入密码）

[root@m1~]# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: admin/[email protected]

Valid starting     Expires            Service principal
08/27/19 14:41:39  08/28/19 14:41:39  krbtgt/[email protected]
        renew until 08/27/19 14:41:39

如果出现：kadmin: GSS-API (or Kerberos) error while initializing kadmin interface，则重启ntp服务：

[root@m1 ~]# service ntpd restart
关闭 ntpd：                                                [确定]
正在启动 ntpd：

3 Kerberos数据库操作

3.1 登录Kerberos数据库

1）本地登录（无需认证）

[root@m1 ~]# kadmin.local 
Authenticating as principal root/[email protected] with password.
kadmin.local: 

2）远程登录（需进行主体认证，先认证刚刚创建的管理员主体）

[root@s1 ~]# kadmin
Authenticating as principal admin/[email protected] with password.
Password for admin/[email protected]:
kadmin: 

退出输入：exit

3.2 创建Kerberos主体

[root@m1 ~]# kadmin.local -q "addprinc aaa/aaa"
Authenticating as principal root/[email protected] with password.
WARNING: no policy specified for aaa/[email protected]; defaulting to no policy
Enter password for principal "aaa/[email protected]": （输入密码）
Re-enter password for principal "aaa/[email protected]": （输入密码）
Principal "admin/[email protected]" created.

3.3 修改主体密码

[root@m1 ~]# kadmin.local -q "cpw aaa/aaa"
Authenticating as principal root/[email protected] with password.
Enter password for principal "aaa/[email protected]": （输入密码）
Re-enter password for principal "aaa/[email protected]": （输入密码）
Password for "aaa/[email protected]" changed.

3.4 查看所有主体

[root@m1 ~]# kadmin.local -q "list_principals"
Authenticating as principal root/[email protected] with password.
K/[email protected]
[admin/[email protected]](mailto:admin/[email protected])
aaa/[email protected]
kadmin/[email protected]
kadmin/[email protected]
kadmin/[email protected]
kiprop/[email protected]
krbtgt/[email protected]

4 Kerberos主体认证

Kerberos提供了两种认证方式，一种是通过输入密码认证，另一种是通过keytab密钥文件认证，但两种方式不可同时使用。

4.1 密码认证

1）使用kinit进行主体认证

[root@m1 ~]# kinit aaa/aaa
Password for admin/[email protected]:
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: aaa/[email protected]
Valid starting    Expires       Service principal
10/27/2019 18:23:57 10/28/2019 18:23:57 krbtgt/[email protected]
  renew until 11/03/2019 18:23:57

2）查看认证凭证

[root@m1 ~]# klist 

Ticket cache: FILE:/tmp/krb5cc_0
Default principal: aaa/[email protected]
Valid starting    Expires       Service principal
10/27/2019 18:23:57 10/28/2019 18:23:57 krbtgt/[email protected]
  renew until 11/03/2019 18:23:57

4.2 keytab密钥文件认证

1）生成主体admin/admin的keytab文件到指定目录/root/admin.keytab

[root@m1 ~]# 

kadmin.local -q "xst -k /root/aaa.keytab aaa/[email protected]"

2）使用keytab进行认证

[root@m1 ~]# kinit -kt /root/aaa.keytab aaa/aaa

3）查看认证凭证

[root@m1 ~]# klist 

Ticket cache: FILE:/tmp/krb5cc_0
Default principal: aaa/[email protected]
Valid starting   Expires      Service principal
08/27/19 15:41:28 08/28/19 15:41:28 krbtgt/[email protected]
​renew until 08/27/19 15:41:28

4.3 销毁凭证

[root@m1 ~]# kdestroy

[root@m1 ~]# klist  

klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_0)

5 CDH启用Kerberos安全认证

5.1 为CM创建管理员主体/实例

[root@m1 ~]# kadmin.local -q "addprinc cloudera-scm/admin"
Authenticating as principal root/[email protected] with password.
WARNING: no policy specified for cloudera-scm/admin @HADOOP.COM; defaulting to no policy
Enter password for principal " cloudera-scm/admin @HADOOP.COM": （输入密码）
Re-enter password for principal " cloudera-scm/admin @HADOOP.COM": （确认密码）
Principal " cloudera-scm/admin @HADOOP.COM" created.

5.2 启用Kerberos

5.3 环境确认（勾选全部）

5.4 填写配置

Kerberos 加密类型:aes128-cts、des3-hmac-sha1、arcfour-hmac

根据你自己的实际情况填写 比如我下面主机这两个框这就填的m1.test.com 

5.5 继续 

​

5.6 填写主体名和密码
​

5.7 等待导入KDC

5.8 准备重启集群

 

5.9 等待完成

5.10 查看主体

[root@m1 ~]# kadmin.local -q "list_principals"
Authenticating as principal cloudera-scm/[email protected] with password.
HTTP/[email protected]
HTTP/[email protected]
HTTP/[email protected]
K/[email protected]
admin/[email protected]
[email protected]
cloudera-scm/[email protected]
hdfs/[email protected]
hdfs/[email protected]
hdfs/[email protected]
hive/[email protected]
hue/[email protected]
kadmin/[email protected]
kadmin/[email protected]
kadmin/[email protected]
krbtgt/[email protected]
mapred/[email protected]
oozie/[email protected]
sentry/[email protected]
yarn/[email protected]
yarn/[email protected]
yarn/[email protected]
zookeeper/[email protected]
zookeeper/[email protected]
zookeeper/[email protected]

6 Kerberos安全环境实操

在启用Kerberos之后，系统与系统（flume-kafka）之间的通讯，以及用户与系统（user-hdfs）之间的通讯都需要先进行安全认证，认证通过之后方可进行通讯。

故在启用Kerberos后，数仓中使用的脚本等，均需要加入一步安全认证的操作，才能正常工作。

6.1 用户访问服务认证

开启Kerberos安全认证之后，日常的访问服务（例如访问HDFS，消费Kafka topic等）都需要先进行安全认证

1）在Kerberos数据库中创建用户主体/实例

[root@m1 ~]# kadmin.local -q "addprinc hive/[email protected]"

2）进行用户认证

[root@m1 ~]# kinit hive/[email protected]

3）访问HDFS

[root@m1 ~]# hadoop fs -ls /
Found 4 items

drwxr-xr-x  - hive hive        0 2019-10-02 01:29 /origin_data
drwxrwxrwt  - hdfs supergroup     0 2019-10-03 00:20 /tmp
drwxr-xr-x  - hdfs supergroup     0 2019-10-02 01:35 /user
drwxr-xr-x  - hive hive        0 2019-10-02 01:38 /warehouse

4）hive查询

[root@m1 ~]# hive 
WARNING: Use "yarn jar" to launch YARN applications.

Logging initialized using configuration in jar:file:/opt/cloudera/parcels/CDH-6.2.1-1.cdh6.2.1.p0.1425774/jars/hive-common-2.1.1-cdh6.2.1.jar!/hive-log4j2.properties Async: false
 
WARNING: Hive CLI is deprecated and migration to Beeline is recommended.

hive>

5）HDFS WebUI浏览器认证

我们设置CDH支持kerberos后会出现下图所示的情况：

可以登录9870，但是不能查看目录及文件，这是由于我们本地环境没有通过认证。

接下来我们设置本地验证。

注意：由于浏览器限制问题，我们这里使用火狐浏览器，其他如：谷歌，ie等均会出现问题。

（1） 下载火狐

（2）设置浏览器

1 打开火狐浏览器，在地址栏输入：about:config，进入设置页面。

2 搜索“network.negotiate-auth.trusted-uris”，修改值为自己的服务器主机名。

  

3搜索“network.auth.use-sspi”，双击将值变为false。

（3）安装kfw

1.安装kfw-4.1-amd64.msi。

2.将集群的/etc/krb5.conf文件的内容复制到C:\ProgramData\MIT\Kerberos5\krb.ini中，删除和路径相关的配置。

[logging]

 [libdefaults]
  default_realm = HADOOP.COM
  dns_lookup_realm = false
  dns_lookup_kdc = false
  ticket_lifetime = 24h
  renew_lifetime = 7d
  forwardable = true
  udp_preference_limit = 1

[realms]
 HADOOP.COM = {
  kdc = m1.test.com
  admin_server = m1.test.com
 }

[domain_realm]

3打开MIT，输入主体名和密码：

4）测试

6.2 数仓脚本更改

（1）生成hive用户的keytab文件

用户认证的方式有“输入密码”和“使用keytab密钥文件”两种方式，此处需使用keytab密钥文件进行认证。

[root@m1 hive]# kadmin.local -q “xst -k /var/lib/hive/hive.keytab hive/[email protected]”

（2）增加读权限

chmod +r /var/lib/hive/hive.keytab

（3）分发keytab文件

xsync /var/lib/hive/hive.keytab

（4）sqoop_import.sh

#!/bin/bash
kinit -kt /var/lib/hive/hive.keytab hive/hive
# 如果是输入的日期按照取输入日期；如果没输入日期取当前时间的前一天
if [ -n "$2" ] ;then
   do_date=$2
else 
   do_date=`date -d "-1 day" +%F`
fi
echo "===日志日期为 $do_date==="



import_ec_data_daily() {
sqoop import \
--connect jdbc:mysql://10.73.129.169:3306/ecdata \
--username admin_user \
--password Tcladmin#20170104 \
--hive-drop-import-delims \
--target-dir /origin_data/db_mall/$1/$do_date \
--delete-target-dir \
--null-string '\\N' \
--null-non-string '\\N' \
--compress \
--compression-codec lzop \
--num-mappers 1 \
--fields-terminated-by "\001" \
--query "$2"
}

import_base_bottom_shop(){
  import_ec_data_daily  "ods_sale_base_bottom_shop_daily"  "select * from base_bottom_shop where 1=1 and \$CONDITIONS"
}


case $1 in
  "import_base_bottom_shop")
     import_base_bottom_shop
;;
   "all")
import_base_bottom_shop

;;
esac

(5)load_ods.sh

#!/bin/bash

# 定义变量方便修改
APP=db_mall
table11=ods_sale_base_bottom_shop_daily

# 如果是输入的日期按照取输入日期；如果没输入日期取当前时间的前一天
if [ -n "$1" ] ;then
   do_date=$1
else 
   do_date=`date -d "-1 day" +%F`
fi 

echo ================== 日志日期为 $do_date ==================
sql="
load data inpath '/origin_data/$APP/$table11/$do_date' OVERWRITE into table "$APP".$table11 partition(dt='$do_date');
"

beeline -u " jdbc:hive2://m1:10000/;principal=hive/[email protected]" -n hive -e "$sql"

6.3问题总结

1.kinit认证时密码输入正确却提示密码错误

[root@m1 ~]# kinit aaa

Password for [email protected]: 
kinit: Password incorrect while getting initial credentials

这是因为aaa已经生成了keytab，所以此时通过这种方式不能认证，需要通过keytab文件来认证，或者修改密码后再认证（修改密码后之前的keytab文件会失效）。

[root@m1 ~]# kinit -kt /root/aaa.keytab aaa
[root@m1 ~]# klist 

Ticket cache: FILE:/tmp/krb5cc_0
Default principal: [email protected]

Password for [email protected]: 
kinit: Password incorrect while getting initial credentials

2.Kerberos启动后台日志提示异常：No such file or directory - while initializing database for realm HADOOP.COM

在/var/log/krb5kdc.log中发现No such file or directory - while initializing database for realm HADOOP.COM。

解决方法：

1）检查kdc.conf和krb5.conf文件是否配置正确,修改配置，注意：配置文件的[kdcdefaults]，[logging]、[libdefaults]等的里面不能有空格

2）停止服务

service krb5kdc stop

service kadmin stop

3）删除Kerberos数据库重新创建数据库

rm -rf /var/kerberos/krb5kdc/principal

kdb5_util create -s -r HADOOP.COM

4）创建管理员

kadmin.local -q “addprinc admin/admin”

5）启动服务

service krb5kdc start

service kadmin start

3 kinit通过keytab认证出现异常

通过Linux的aaa主体执行kinit -kt /root/aaa.keytab aaa出现下面情况:

kinit: ???? while getting initial credentials

或者

kinit: Permission denied while getting initial credentials

解决方式：

1）使用root用户修改aaa.keytab的所属用户：

chown aaa /root/aaa.keytab

1. 修改aaa.keytab的权限为660

chmod 660 /root/aaa.keytab

2. 安全之Sentry权限管理

1 Sentry概述

cdh版本的hadoop在对数据安全上的处理通常采用Kerberos+Sentry的结构。

kerberos主要负责平台用户的用户认证，sentry则负责数据的权限管理。

1.1 Sentry是什么

Apache Sentry是Cloudera公司发布的一个Hadoop开源组件，它提供了细粒度级、基于角色的授权以及多租户的管理模式。

Sentry提供了对Hadoop集群上经过身份验证的用户和应用程序的数据控制和强制执行精确级别权限的功能。Sentry目前可以与Apache Hive，Hive Metastore / HCatalog，Apache Solr，Impala和HDFS（仅限于Hive表数据）一起使用。

Sentry旨在成为Hadoop组件的可插拔授权引擎。它允许自定义授权规则以验证用户或应用程序对Hadoop资源的访问请求。Sentry是高度模块化的，可以支持Hadoop中各种数据模型的授权。

1.2 Sentry中的角色

2.Sentry安装部署

2.1 添加Sentry服务

2.2 自定义Sentry角色分配

2.3 配置数据库连接

2.4 成功完成Sentry的服务添加

3 Sentry与Hive/Impala集成

3.1 修改配置参数

（1）取消HiveServer2用户模拟

在hive配置项中搜索“HiveServer2 启用模拟”，取消勾选

（2）确保hive用户能够提交MR任务

在yarn配置项中搜索“允许的系统用户”，确保包含“hive”。

3.2 配置Hive使用Sentry

（1）在Hive配置项中搜索“启用数据库中的存储通知”，勾选。

（2）在Hive配置项中搜索“Sentry”，勾选Sentry

Impala使用Sentry

在Impala配置项中搜索“Sentry”，勾选。

3.4 配置HDFS权限与Sentry同步

1）在HDFS配置项中搜索“启用访问控制列表”，勾选。

2）在HDFS配置项中搜索“启用 Sentry 同步”，做出下图修改。

4 Sentry授权实战

使用Sentry进行授权管理，需要使用Sentry的管理员用户对其他用户进行授权，授权的方式有两种，一是通过HUE进行可视化操作，一是使用HIVE中的授权语句进行操作。

4.1 Sentry实战之HUE

1）配置HUE支持Sentry

在HUE配置项中搜索“Sentry”，勾选Sentry。

2）查看Sentry权限管理中的管理员组。

在Sentry的配置项中搜索“管理员组”，其中包括hive、impala，只有当某用户所属组位于其中时，才可为其他用户授予权限。

3）在Hive集群所有节点创建两个用户reader，writer，为权限测试做准备。必须集群每个节点都创建该用户

[root@hadoop102 ~]# useradd reader

[root@hadoop102 ~]# passwd reader

[root@hadoop102 ~]# useradd writer

[root@hadoop102 ~]# passwd writer

4）使用hive用户登录HUE，创建两个用户组reader、writer，并在两个用户组下创建两个用户reader、writer，为权限测试做准备。

5）Sentry工作界面（需要授予HUE用户访问Sentry的权限）

6）点击Roles按钮，并点击添加按钮

7）编辑Role

admin_role（首先为hive用户添加所有权限）

reader_role

writer_role

7）权限测试

（1）分别使用reader和writer用户登录HUE

（2）查询gmall数据库中的任意一张表，发现只有reader用户可查出，而writer则不能。说明权限控制生效。

reader用户

writer用户

4.2 Sentry实战之命令行

1）在Hive集群所有节点创建两个用户reader_cmd，writer_cmd

[root@hadoop102 ~]# useradd reader_cmd

[root@hadoop102 ~]# passwd reader_cmd

[root@hadoop102 ~]# useradd writer_cmd

[root@hadoop102 ~]# passwd writer_cmd

[root@hadoop101 ~]# useradd reader_cmd

[root@hadoop101 ~]# passwd reader_cmd
 
[root@hadoop101 ~]# useradd writer_cmd

[root@hadoop101 ~]# passwd writer_cmd

2）使用Sentry管理员用户hive通过beeline客户端连接HiveServer2

[root@hadoop102 ~]# kinit -kt /var/lib/hive/hive.keytab hive/[email protected]

[root@hadoop102 ~]# beeline -u "jdbc:hive2://node01:10000/;principal=hive/[email protected]"

进去之后只能看到一个default  因为此时没有任何帐号有权限

创建管理员角色:

CREATE ROLE hive_admin;
GRANT ALL ON SERVER server1 TO ROLE hive_admin WITH GRANT OPTION;

其中有个server1，需要注意，这个值参考自hive配置hive.sentry.server。
这是一个别名，Sentry用其关联Hive服务。 就直接用这个server1就行了 

Hive组
将hive组设置为超级管理员组

GRANT ROLE hive_admin TO GROUP hive;

好了 现在hive用户可以看到所有表 拥有所有权限了 

1）创建Role（reader_role_cmd,writer_role_cmd）

create role reader_role_cmd;

create role writer_role_cmd;

2）为role赋予privilege

GRANT select ON DATABASE db_mall TO ROLE reader_role_cmd;

GRANT insert ON DATABASE db_mall TO ROLE writer_role_cmd;

GRANT ALL ON DATABASE db_mall TO ROLE writer_role_cmd;

3）将role授予用户组

GRANT ROLE reader_role_cmd TO GROUP reader_cmd;

GRANT ROLE writer_role_cmd TO GROUP writer_cmd;

到这就已经授权到用户了

4）查看权限授予情况

（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;

5）权限测试

（1）为reader_cmd、writer_cmd创建Kerberos主体

[root@hadoop102 ~]# kadmin.local -q "addprinc reader_cmd/[email protected]"

[root@hadoop102 ~]#

 kadmin.local -q "addprinc writer_cmd/[email protected]"

（2）使用reader_cmd登录HiveServer2，查询gmall库下的任意一张表

[root@hadoop102 ~]# kinit reader_cmd/[email protected]

[root@hadoop102 ~]# beeline -u "jdbc:hive2://node01:10000/;principal=hive/ [email protected]"

（3）使用writer_cmd登录HiveServer2，查询gmall库下的任意一张表

[root@hadoop102 ~]# kinit writer_cmd/[email protected]

[root@hadoop102 ~]# beeline -u "jdbc:hive2://node01:10000/;principal=hive/ [email protected]"

（4）查询结果

reader_cmd有对于gmall表的查询权限，而writer_cmd没有。说明授权生效。

5.Sentry与Kafka的集成

（1）修改Kafka配置

1在Kafka的配置项搜索“security.inter.broker.protocol”，设置为SALS_PLAINTEXT。

2在Kafka的配置项搜索“ssl.client.auth”，设置为none。

3在Kafka的配置项搜索“Kerberos”

4 启用Kafka的Sentry，通过Cloudera Manager修改Kafka服务的配置

（2）创建jaas.conf文件

[root@hadoop102 hive]#

 vim /var/lib/hive/jaas.conf

文件内容如下

KafkaClient {

com.sun.security.auth.module.Krb5LoginModule required

useTicketCache=true;

};

（3）创建consumer.properties文件

[root@hadoop102 conf]# vim /etc/kafka/conf/client.properties

文件内容如下

security.protocol=SASL_PLAINTEXT

sasl.kerberos.service.name=kafka

（4）创建kafka管理员用户

为了后面操作方便，我们这里还创建一个kafka的principle，当然你也可以到/var/run/cloudera-scm-agent/process目录下去拿kafka用户的principle。

[root@cdh01 shell]# kadmin.local

Authenticating as principal root/[email protected] with password.
kadmin.local:  addprinc kafka/admin
WARNING: no policy specified for kafka/[email protected]; defaulting to no policy
Enter password for principal "kafka/[email protected]": 
Re-enter password for principal "kafka/[email protected]": 
Principal "kafka/[email protected]" created.
kadmin.local:  

（5）声明jass.conf文件路径（临时用，后续可以加入到配置文件中）

[root@hadoop102 conf]# export KAFKA_OPTS="-Djava.security.auth.login.config=/var/lib/hive/jaas.conf"

或者

vim /etc/profile
source /etc/profile

6.Kafka的赋权测试

1.消费者命令

kafka-console-producer --broker-list m1:9092 --topic first --producer.config /etc/kafka/conf/consumer.properties

2.生产者命令

kafka-console-consumer --bootstrap-server m1:9092 --topic first --from-beginning --consumer.config /etc/kafka/conf/consumer.properties

3.创建管理员用户

我们给hive用户组赋权可以写入数据到first，注意需要使用管理员kafka用户登录Kerberos才能进行操作

[root@cdh01 kafka]# kinit kafka/admin

Password for kafka/[email protected]: 
[root@cdh01 kafka]# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: kafka/[email protected]
Valid starting       Expires              Service principal
06/13/2018 00:41:45  06/14/2018 00:41:45  krbtgt/[email protected]
        renew until 06/20/2018 00:41:45

4.创建角色kafka_role

[root@cdh01 kafka]# kafka-sentry -cr -r kafka_role

5.列出Sentry中的角色

[root@cdh01 kafka]# kafka-sentry -lr

6.使用hive用户启动produce程序

1.给kafka_role角色赋权可以给first写入权限

[root@cdh01 kafka]# kafka-sentry -gpr -r kafka_role -p "Topic=first->action=write"

2.给kafka_role角色赋权可以给testTopic的describe权限

在给Topic赋权read或者write权限时，务必同时带上describe权限，否则权限不生效。当然你也可以将权限设置为ALL

[root@cdh01 kafka]# kafka-sentry -gpr -r kafka_role -p "Topic=testTopic->action=describe"

3.把kafka_role加入到用户组kafka中

[root@cdh01 kafka]# kafka-sentry -arg -r kafka_role -g kafka

4.再次使用hive用户登录Kerberos，启用producer程序

执行成功，说明赋权写入权限成功。

7.使用fayson用户启动consumer程序

1.给kafka_role角色赋权consumer相关的权限

kafka-sentry -gpr -r kafka_role -p "CONSUMERGROUP=testgroup->action=read"
kafka-sentry -gpr -r kafka_role -p "CONSUMERGROUP=testgroup->action=describe"
kafka-sentry -gpr -r kafka_role -p "Topic=testTopic->action=read"

2.再次使用fayson用户登录Kerberos后启动producer和consumer

kafka-console-producer --broker-list cdh02.fayson.com:9092,cdh03.fayson.com:9092,cdh04.fayson.com:9092 --topic testTopic --producer.config client.properties

消费成功，表明赋权消费者相关权限以后，消费成功。

7.总结

1.通过Sentry可以对Kafka的topic进行权限管理，主要是往topic写入数据以及读取topic的数据。

2.在给Topic赋权read或者write权限时，务必同时带上describe权限，否则权限不生效。当然你也可以将权限设置为ALL。

3.一旦对Kafka启用Sentry授权以后，kafka用户就是管理员，一切管理员操作都需要使用kafka用户来操作，这个与我们在Hive/Impala中使用Sentry时，hive用户是管理员原理是一样的，Fayson之前介绍Solr的Sentry赋权时，solr用户就是默认管理员，也是一样。

4.目前Kafka的授权，对于create和delete topic还不完善，需要等待后续版本。

5.Hue使用Sentry进行权限管理之后, 要求登录Hue的用户及其组需要在Sentry Server节点(以正式环境为例, 即gs01节点)Linux系统中存在对应的用户和组, 否则无法进行权限控制.