Kerberos和Apache Sentry干货实践（下）

在《Kerberos和Apache Sentry干货实践（上）》一文中，主要介绍了Kerberos原理及搭建过程，本文继续讲解Apache Sentry以及其如何和Kerberos配合进行访问权限控制的。

一、Apache Sentry是什么？

Apache Sentry提供了大数据组件访问的权限控制。与Kerberos不同的是，当A组件去访问B组件时，Kerberos承载的身份认证完成，确保A组和B组的身份不被假冒后，Sentry来管理A有哪些权限，能够访问B组件上的哪些内容。

Apache Sentry是Cloudera公司发布的一个Hadoop开源组件，2016年3月成为Apache顶级项目。Sentry是一个基于角色的粒度授权模块，提供了对Hadoop集群上经过身份验证的用户提供了控制和强制访问数据或数据特权的能力。它可以与Hive、Impala、Solr、HDFS和HBase集成。Sentry旨在成为可插拔授权引擎的Hadoop组件。允许定义授权规则以验证用户或应用程序对Hadoop资源的访问请求。

二、特性

a) 用户和组映射

Sentry依靠底层身份验证系统（如Kerberos或LDAP）来识别用户。它还使用Hadoop中配置的组映射机制来确保Sentry看到与Hadoop生态系统的其他组件相同的组映射。

举个例子，假设用户 A 和用户 B 属于名为 finance 的组（Group），我们需要为这两个用户赋权查询 Sales 表，操作如下，在 Sentry 中，我们可以创建一个名为 Analyst 的角色（Role），并将 Sales 表 SELECT 权限授予 Analyst 角色，再将 Analyst 角色授予 finance 组。

b) 基于角色的访问控制

基于角色的访问控制（RBAC）是一种强大的机制，用于管理企业中大量用户和数据对象的授权。RBAC 使得对添加或删除数据对象，用户加入或离开组织的管理更加容易。

继续上面的例子，如果新员工 C 加入财务部门，我们需要做的就是将他添加到 finance 组。这就可以实现员工 C 访问 Sales 表中的数据。

c) 统一授权

Sentry 的另一个重要方面是统一授权。访问控制规则一旦定义，就可以跨多个数据访问工具工作。

三、Sentry 架构

a) 组件

• Sentry Server：Sentry RPC 服务器, 管理授权元数据, 支持安全检索和操作元数据的接口；
• Policy metadata：存储权限策略数据，我们将权限元数据存放在 Sentry Server 机器上 MySQL 数据库的 Sentry 库中；
• Data Engine：数据处理应用组件，如 Hive 或 Impala，需要授权访问数据或元数据资源。数据引擎加载 Sentry 插件，拦截所有访问资源的客户端请求并将其路由到 Sentry 插件进行验证；
• Sentry Plugin：Sentry 插件在对应的组件（如 Hive）中运行。它提供了操作存储在 Sentry 服务器中的授权元数据的接口，包括授权策略引擎，该引擎使用从 Sentry Server 拉取授权元数据来评估访问请求。

b) 关键概念

• Privilege：允许访问对象的指令或规则；
• Role：一组 Privilege 的集合抽象成 Role，用于组合多个访问规则的模板；
• User：由认证系统 (Kerberos) 识别的用户；
• Group：由身份验证系统 (Kerberos) 维护的一组用户；
• Authorization models：定义要受授权规则约束的对象以及允许的操作粒度。例如，在 SQL 中，对象可以是服务，数据库，表或者列，操作是 SELECT,INSERT 和 CREATE 等。

c) 参与授权的角色

• Resource：资源是您要管理访问权限的对象；
• Privilege：默认情况下，Sentry 不允许访问任何资源，除非明确授予。权限本质上是授予对资源的访问权限的规则；
• Role：角色是一组 Privilege；
• Group：组是用户的集合。Sentry 组映射是可扩展的。默认情况下，Sentry 利用 Hadoop 的组映射 (可以是 OS 组或 LDAP 组)。Sentry 允许将角色与组关联，可以将多个用户组合到一个组中。

注意：Sentry 仅支持基于角色的访问控制，无法直接向用户或组授予权限，需要在角色下组合权限。只能将角色授予组，而不能直接授予用户。

d) 具体实现思想

Sentry 将自己的 Hook 函数插入到各 SQL 引擎的编译、执行的不同阶段。这些 Hook 函数起两大作用：一是起过滤器的作用，只放行具有相应数据对象访问权限的 SQL 查询；二是起授权接管的作用，使用了 Sentry 之后，grant/revoke 管理的权限完全被 Sentry 接管，grant/revoke 的执行也完全在 Sentry 中实现；对于所有引擎的授权信息也存储在由 Sentry 设定的统一的数据库中，这样所有引擎的权限就实现了集中管理。

四、Sentry 与 Hadoop 生态系统的集成

Apache Sentry 可以与多个 Hadoop 组件一起工作。从本质上讲，Sentry Server 存储着授权元数据，并提供 API 工具以安全地检索和修改此元数据。

a) Hive 和 Sentry

• 查询授权：Sentry Policy Engine 通过 Hook 函数插入 Hive，HiveServer2 在查询成功编译后执行 Hook 函数。Hook 函数获取查询以读写模式访问的对象列表。Sentry Hive Binding 将此转换为基于 SQL 权限模型的授权请求。
• 策略操作：在查询编译期间，Hive 调用 Sentry 的授权任务工厂，该工厂生成在查询处理期间执行的 Sentry 特定任务。调用 Sentry 存储客户端，向 Sentry 服务发送 RPC 请求，以进行授权策略更改。

b) Impala 和 Sentry

Impala 中的授权处理与 Hive 中的授权处理类似。主要区别在于权限的缓存。Impala 的 Catalog 服务管理缓存 schema 元数据并将其传播到所有 Impala Daemon 节点。此 Catalog 服务也缓存 Sentry 元数据。因此，Impala 的授权在本地就可以实现，速度更快。

c) Sentry-HDFS

Sentry-HDFS 授权主要针对 Hive 仓库数据 - 也即 Hive 或 Impala 中表的数据。Sentry 与 HDFS 的集成的真正目标是将相同的授权检查扩展到从任何其他组件（如 Pig，MapReduce 或 Spark）访问 Hive 仓库数据。基于这一点可以利用 HDFS 已有的 ACL 功能，但与 Sentry 无关的表将保留其旧 ACL。

Sentry 权限与 HDFS ACL 的映射关系如下：

• SELECT -> 文件的 Read 权限；
• INSERT -> 文件的 Write 权限；
• ALL -> 文件的 Read 和 Write 权限

NameNode 会加载一个 Sentry 插件，用于缓存 Sentry 权限以及 Hive 元数据。这有助于 HDFS 保持文件权限和 Hive 表权限同步。Sentry 插件定期轮询 Sentry 以保持元数据更改同步。

五、Kerberos 启用下的 Sentry 使用实践

a) 集成背景

hive，hdfs，hbase 分别是 HIVE，HDFS，HBASE 组件默认的超级管理员用户，同时 os 也存在其 hive，hdfs，hbase 用户和用户组，同时 Kerberos 在安装时会自动创建 admin/admin 的 kerberos 超级用户，和名为【组件 /_HOST】的组件用户（例如 hive/cdh1，hbase/cdh2）。

Sentry 实际上是沿用的 Hadoop 的用户和组，而 Hadoop 沿用了 Linux 的用户和组，当我们需要在 Sentry 中使用某个用户时候，需要确认该用户在 Linux 是否存在，以及 Kerberos 中是否有该用户的 principle。

b) Sentry 与 Hive

进入 hive 当前 HIVESERVER2 进程的执行文件夹，该文件夹下会存在一个叫做 hive.keytab 的文件，通过该文件能以 hive（hive 组件的超级用户）登录 Kerberos KDC 拿到 TGT。在 Kerberos 认证成功后，通过 beeline 登录 hive，创建不同的 role 并赋予不同的权限。

cd /var/run/cloudera-scm-agent/process/ && cd `ls -t1 | grep -e "-HIVESERVER2"`
kinit -kt hive.keytab hive/cdh
# 例如创建只读账号 userread，我们需要在 [Linux](https://www.infoq.cn/article/RCEBzBe0yT3ui5A9BwHy) 用户中添加用户，并在 Kerberos 中将该用户添加为一个 principle：
useradd userread
kadmin.local > addprinc userread (password: userread)

# 生成 keytab(默认在 /etc 下面)
kadmin.local > xst -k dev.keytab -norandkey userread@CDH.COM

# 登录 hive
beeline > !connect jdbc:hive2://localhost:10000/;principal=hive/cdh1
beeline > create role readrole;
beeline > grant select on server server1 to role readrole;
beeline > grant role readrole to group userread;

# 如果想规定 只读 / 只写 / 创建 / 所有权限 某个 集群 / 库 / 表：
grant select/insert/create on server/database/table servername/databasename/tablename to role somerole;

由于 impala 属于 hive 组的成员，所以在 hive 中对 userread 用户赋权，userread 用户同时拥有 hive 和 impala 的权限。

c) Sentry 与 HDFS

HUE 登陆 admin 用户（admin 用户是 HUE 的超级管理员，但不是 HIVE，HBASE，HDFS 等的超级管理员）：

创建用户 hive（HIVE 的超级管理员），用户 hdfs（HDFS 的超级管理员），用户 hbase（HBASE 的超级管理员），impala（IMPALA 的超级管理员）,dev(日常开发维护用户)

密码是自定义的，只用于登陆 HUE：

这个地方的 superuser 指的是 HUE 的 superuser，代表着是否有权限管理 HUE 里面的用户：

HDFS 文件 URL 授权（以下给 dev 用户授权 /Data 目录的读写权限为例）：

首先要以 hdfs 身份登陆 HUE，这是 HDFS 默认的超级管理员（虽然在 HUE 里面只是 HUE 的一个普通用户）。

点击安全性，进入授权界面：

HDFS 文件授权，点中需要更改权限的目录，右边会显示当前更改权限的目录和加号➕：

添加好权限之后，点击保存：

成功添加权限后，目录这一行会有一个小盾牌：

此时 dev 对 /Data 目录已经有读写执行的权限了，具体验证就在此省略。

六、总结

到此，Kerberos 和 Apache Sentry 的原理、搭建和使用就已经介绍完了，目前好大夫在线的大数据集群已经集成 Kerberos 和 Apache Sentry 并稳定运行了一段时间。通过本次对集群的安全升级，使得公司的数据资产更加的安全可靠。

作者介绍：

张博雅：好大夫在线大数据开发工程师，涉猎技术包括分布式实时离线计算，数据仓库建设，数据安全等，喜欢研究解决大数据组件相关问题。

马大芳：好大夫在线大数据开发工程师，专注大数据领域，主要关注 Kafka/Spark/HBase 等开源组件，热爱技术和探索。