上篇文章后半部分提到了业界流行的大数据权限管理框架Apache Sentry和Ranger。二者在功能上具有很高的相似性，但是在具体细节上上篇文章阐述的还不够细致。本文笔者来深入浅出地聊聊这两个框架，以及它们的少许异同点。熟悉掌握使用外部权限管理框架，并且将它们合理地应用于自身内部大数据组件系统内，无疑将会大大提高内部组件使用的安全性。
从最源头开始说起这2个项目，Sentry首先是由Cloudera公司内部开发而来的，初衷是为了让用户能够细粒度的控制Hadoop系统中的数据（这里主要指HDFS，Hive的数据）。所以Sentry对HDFS，Hive以及同样由Cloudera开发的Impala有着很好的支持性。
而Ranger则是由于另一家公司Hortonworks所主导。它同样是做细粒度的权限控制。但相比较于Sentry而言，它能支持更丰富的组件，包括于 HDFS, Hive, HBase, Yarn, Storm, Knox, Kafka, Solr and NiFi。
这两个框架在权限管理时都有运用到基于角色的访问控制原理（role-based access control，RBAC）。换句话说，当新来一个用户时，我们赋予它的是一个身份角色，然后这个用户的执行权限操作完全由统一的角色本身所允许的一些权限。基于角色的访问控制，能够大大减轻系统对于大数据量用户的直接ACL控制。
下面我们来细聊着两大组件的内容。
上文提到过，Sentry在最初发展阶段只是对部分组件支持的比较好，没有像Ranger支持的那么多。
首先，我们来看Sentry的整体架构
DataEngine指的是具体的数据应用程序，这里指的是HDFS，Hive和Impala。
Plugin，Plugin程序负责和Sentry Server通信，做权限策略信息的同步。同时在Plugin程序中，包含了认证引擎模块，来做权限的验证操作。
Policy metadata，这里的matadata存储权限策略数据，对应的会需要一个外部存储db。
从另一个角度层面来看Sentry的内部结构
Sentry与Hive，HDFS，Impala等组件集成的较好， 结构图如下图所示：
从上图中，我们注意到一个细节，在HDFS里面多了一个cache层，这个是用来干嘛的呢？其实为了保持HDFS的权限与HIve的一致，NameNode的Sentry Plugin程序会定期拉取Hive的Metadata信息以及Sentry Server上的权限信息，并cache起来。这可以说也是为了性能考虑了。
另外地在Sentry Sever中，它还有audit模块，记录了所有模块的请求访问记录。
Ranger相比较于Sentry来说，它的功能可以说更加具有通用性。这里说的通用性在于以下两点：
第一点，前文已经提到过，第二点这里的资源就不仅仅只有文件和目录了这种了，它还可以有表，行以及列的访问控制。这些都是体现在Ranger的策略信息里面的。
以下是Ranger的架构模型，和Sentry有类似之处。
对于具体的策略控制，由用户通过admin web ui页面进行配置。
我们先来看最简单的，对于用户的访问控制，我们可以设置用户对于选定的路径有哪些权限，策略细节如下：
配置此策略信息后，系统会对这些用户做额外判断处理。
小标题这里我们指的是对Hive的表数据。假设我们有一以下Hive表。
Table: customer
+----+------------+-----------+--------------+---------------+----------------+
| id | name_first | name_last | addr_country | date_of_birth | phone_num |
+----+------------+-----------+--------------+---------------+----------------+
| 1 | Mackenzy | Smith | US | 1993-12-18 | 123-456-7890 |
| 2 | Sherlyn | Miller | US | 1975-本文发布于:2024-01-28 00:06:32，感谢您对本站的认可！
本文链接：https://www.4u4v.net/it/17063715943458.html
版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系，我们将在24小时内删除。
| 留言与评论（共有 0 条评论） |
