导读：我们大家都知道，Hive会把元数据信息存储在MySQL中，Hive中的每一张表都会在MySQL中存储与其相关的表信息、权限信息。如果一个用户去查询该表，则会去获取元数据鉴权该用户是否有权限。随着表、用户、用户组等的增多，要对这些表进行权限管理就变得不那么简单。于是诞生了一款专门用于权限管理的组件-- Sentry。
Apache Sentry是Hadoop的一个基于角色（Role）的细粒度授权模块。在Hadoop集群上经过身份验证的用户和应用程序，Sentry可以对他们进行进行精确的权限权限控制。目前，Sentry在Apache Hive、Hive Metastore/HCatalog、Apache Solr、Impala和HDFS(仅限于Hive表数据所涉及的路径)上都是开箱即用的，即它是一个可插拔的Hadoop组件授权引擎。Sentry允许自定义授权规则来控制用户或应用程序对Hadoop资源的访问请求。Sentry是高度模块化的，可以支持Hadoop中各种数据模型的授权。
1. Architecture Overview
1.1 Sentry Components
Sentry Server： Sentry RPC server负责管理授权元数据，它提供接口来检索和操作元数据;Data Engine： 这指的是需要进行权限认证的数据处理引擎（例如Hive或Impala），它们需要通过Sentry来授权访问数据或元数据资源。数据引擎通过加载安装Sentry插件，使得所有访问引擎资源的客户端请求被拦截并路由到Sentry插件进行权限验证;
Sentry Plugin： Sentry Plugin运行在数据引擎中，它提供了操作存储在Sentry Server中的授权元数据的接口，还提供了（能从Sentry Server获取授权访问元数据信息来评估访问请求的）授权策略引擎。
关键概念:
认证 -通过验证证书来可靠地识别用户
- 角色 -一组权限合集;一个集成了多个访问规则的模板
- 授权模型 -定义受授权规则约束的对象和允许的操作粒度。例如，在SQL模型中，受授权规则约束的对象可以是数据库或表，允许的操作粒度可以是SELECT、INSERT、CREATE等。
- 对于Search模型，对象是索引、集合和文档，访问方式有查询、更新等。
1.2 用户身份和组映射
Sentry依靠Kerberos或LDAP等底层身份验证系统来识别用户。它还使用Hadoop中配置的组映射机制，以确保Sentry看到与Hadoop生态系统中的其他组件相同的组映射。举个例子，用户Alice和Bob属于名为finance-department的组，Bob同时还属于finance-managers组。在Sentry中，首先要创建角色，然后向这些角色授权。例如，你可以创建一个名为Analyst的角色（Role），并将Customer和Sales两张表上的SELECT权限授予Analyst角色。下一步是将这些身份验证实体(包括用户user和组group)链接到授权实体(role角色)。例如，把Analyst角色授权到组finance-department（包括Alice和Bob用户）中，这样finance-department组的成员Bob和Alice就都获得了对Customer和Sales表的SELECT权限。1.3 基于角色的访问控制
对于有大量用户和数据对象的授权场景，基于角色的访问控制(Role-based access control, RBAC)是一种非常强大且有效的机制，例如数据对象的添加或删除，用户的加入、移动或离开等，RBAC使管理这些场景变得容易得多。因此，接前面的例子，如果Carol加入到了金融部门，你只需要将她添加到finance-department组中，就能够让Carol 有权访问Sales和Customer表中的数据。1.4 统一授权
Sentry的另一个重要方面是统一授权。一旦定义了访问控制规则，就可以跨多个数据引擎工作。例如，在前面的例子中，被授权Analyst角色的finance-department组，将会使得Bob、Alice和以及组里的其他人通过Hive、Impala、MapReduce、Pig等引擎访问表数据，或者通过HCatalog访问元数据。2. Sentry Integration with the Hadoop Ecosystem
如上所述，Apache Sentry可以适用于多个Hadoop组件，其核心是Sentry Server，它可以存储授权元数据，并且提供了获取和修改授权元数据的API。但是Sentry Server只是提供授权元数据，真正的授权决策是由运行在Hive或Impala的策略引擎作出的。每个加载组件加载的Sentry Plugin会包括处理Sentry服务请求的客户端和验证授权请求的策略引擎。
2.1 Hive and Sentry
举个例子，Hive收到一个请求，请求客户端以某种模式访问一个对象。例如，Bob提交以下Hive查询:select * from production.sales
Hive将识别用户Bob请求对Sales表进行SELECT访问。此时Hive将请求Sentry Plugin验证Bob的访问请求。Server Plugin将检索Bob与Sales表相关的权限，策略引擎将以此确定这个请求是否合理有效。Hive于Sentry Service和策略文件协同工作。2.2 Impala and Sentry
Impala的授权处理与Hive的授权处理类似，主要的区别是Impala可以缓存授权信息。Impala的Catalog Server负责缓存元数据并将其传播到所有Impala服务节点。Catalog Server也同样会缓存Sentry元数据。因此，Impala中的授权验证会非常快速地在本地进行。2.3 Sentry-HDFS Synchronization
Sentry-HDFS的授权主要体现在Hive仓库的相关数据上，换句话说，是与任何属于Hive或Impala中的某个表的数据相关。这种集成的真正目的是将同样的授权检查扩展到其他组件(如Pig、MapReduce或Spark)访问的Hive仓库数据的过程中。这种情况下，这种特性还不能替换HDFS ACLs，那些跟Sentry没有关联的表也将保留其旧的ACLs。Sentry权限和HDFS的ACL权限映射关系如下：- SELECT privilege -> Read access on the file.
- INSERT privilege -> Write access on the file.
- ALL privilege -> Read and Write access on the file.
NameNode加载通过加载Sentry Plugin来缓存Sentry权限以及Hive元数据。这有助于HDFS保持文件权限和Hive表权限的同步。Sentry Plugin会定期轮询Sentry和Metastore以保持元数据的同步。举个例子，如果Bob运行一个Pig作业从Sales表中读取数据文件，Pig将尝试从HDFS中获取文件句柄。此时，NameNode上的Sentry插件会发现该文件是Hive数据的一部分，并将Sentry中的权限覆盖该文件的ACL授权。因此，HDFS将对这个Pig客户端执行与Hive申请SQL查询相同的权限。为了让HDFS-Sentry同步工作，需要使用Sentry服务而不是策略文件授权。参考：
Sentry Tutorial - Apache Sentry - Apache Software Foundationhttps://cwiki.apache.org/confluence/display/SENTRY/Sentry+Tutorial
