Hadoop集群权限框架-Apache Sentry
2020-10-25 13:44:38 
阿炯
Apache Sentry 是Cloudera公司发布的一个加强的细粒度的基于角色的授权系统，针对存储在 Hadoop 集群中的数据和元数据。它提供了细粒度级、基于角色的授权以及多租户的管理模式，可以和Hive/Hcatalog、Solr 和Cloudera Impala集成，未来会扩展到其他的Hadoop组件，例如HDFS和HBase。2016年3月从Incubator毕业，成为Apache顶级项目，旨在成为可插拔授权引擎的Hadoop组件，允许定义授权规则以验证用户或应用程序对Hadoop资源的访问请求。Sentry是高度模块化的，可以支持Hadoop中各种数据模型的授权。
Apache Sentry™ is a system for enforcing fine grained role based authorization to data and metadata stored on a Hadoop cluster. it is a granular, role-based authorization module for Hadoop. Sentry provides the ability to control and enforce precise levels of privileges on data for authenticated users and applications on a Hadoop cluster. Sentry currently works out of the box with Apache Hive, Hive Metastore/HCatalog, Apache Solr, Impala, and HDFS (limited to Hive table data). it's designed to be a pluggable authorization engine for Hadoop components. It allows you to define authorization rules to validate a user or application's access requests for Hadoop resources. Sentry is highly modular and can support authorization for a wide variety of data models in Hadoop.
特性
用户身份和组映射
Sentry依靠底层身份验证系统(如Kerberos或LDAP)来识别用户。它还使用Hadoop中配置的组映射机制来确保Sentry看到与Hadoop生态系统的其他组件相同的组映射。假设有一个组织机构，用户Alice和Bob属于名为finance-department的Active Directory(AD)组。Bob同时也属于一个名为finance-managers的组。在Sentry中，首先创建角色，然后为这些角色授予权限。例如，您可以创建一个名为Analyst的角色，并将表Customer和Sales上的SELECT授予此角色。
基于角色的访问控制
基于角色的访问控制(RBAC)是一种强大的机制，用于管理典型企业中大量用户和数据对象的授权。添加或删除新数据对象，用户一直加入，移动或离开组织。RBAC使管理更容易。继续上面的例子，如果新员工Carol加入财务部门，需要做的就是将她添加到AD中的finance-managers组。这就可以实现Carol访问Sales和Customer表中的数据。
统一授权
Sentry的另一个重要方面是统一授权。访问控制规则一旦定义，就可以跨多个数据访问工具工作。
优缺点：
支持细粒度的hdfs元数据访问控制，对hive支持列级别的访问控制
通过基于角色的授权简化了管理，将访问同一数据集的不同特权级别授予多个角色
提供了一个统一平台方便管理与Kerberos集成
组件只支持hive,hdfs,impala 不支持hbase，yarn，kafka，storm等
架构
Apache Sentry是Hadoop的授权模块，它提供了为正确的用户和应用程序提供精确级别访问所需的基于角色的精细授权。
在Sentry诞生之前，对于授权有两种备选解决方案：粗粒度级的HDFS授权和咨询授权，但它们并不符合典型的规范和数据安全需求，原因如下：
粗粒度级的HDFS授权：安全访问和授权的基本机制被HDFS文件模型的粒度所限制。五级授权是粗粒度的，因为没有对文件内数据的访问控制：用户要么可以访问整个文件，要么什么都看不到。另外，HDFS权限模式不允许多个组对同一数据集有不同级别的访问权限。
咨询授权：咨询授权在Hive中是一个很少使用的机制，旨在使用户能够自我监管，以防止意外删除或重写数据。这是一种“自服务”模式，因为用户可以为自己授予任何权限。因此，一旦恶意用户通过认证，它不能阻止其对敏感数据的访问。
通过引进Sentry，Hadoop目前可在以下方面满足企业和政府用户的RBAC需求：
安全授权：Sentry可以控制数据访问，并对已通过验证的用户提供数据访问特权。
细粒度访问控制：Sentry支持细粒度的Hadoop数据和元数据访问控制。在Hive和Impala中Sentry的最初发行版本中，Sentry在服务器、数据库、表和视图范围提供了不同特权级别的访问控制，包括查找、插入等，允许管理员使用视图限制对行或列的访问。管理员也可以通过Sentry和带选择语句的视图或UDF，根据需要在文件内屏蔽数据。
基于角色的管理：Sentry通过基于角色的授权简化了管理，你可以轻易将访问同一数据集的不同特权级别授予多个组。
多租户管理：Sentry允许为委派给不同管理员的不同数据集设置权限。在Hive/Impala的情况下，Sentry可以在数据库/schema级别进行权限管理。
统一平台：Sentry为确保数据安全，提供了一个统一平台，使用现有的Hadoop Kerberos实现安全认证。同时，通过Hive或Impala访问数据时可以使用同样的Sentry协议。未来，Sentry协议会被扩展到其它组件。
Apache Sentry的目标是实现授权管理，它是一个策略引擎，被数据处理工具用来验证访问权限。它也是一个高度扩展的模块，可以支持任何的数据模型。当前，它支持Apache Hive和Cloudera Impala的关系数据模型，以及Apache中的有继承关系的数据模型。
Sentry提供了定义和持久化访问资源的策略的方法。目前，这些策略可以存储在文件里或者是能使用RPC服务访问的数据库后端存储里。数据访问工具，例如Hive，以一定的模式辨认用户访问数据的请求，例如从一个表读一行数据或者删除一个表。这个工具请求Sentry验证访问是否合理。Sentry构建请求用户被允许的权限的映射并判断给定的请求是否允许访问。请求工具这时候根据Sentry的判断结果来允许或者禁止用户的访问请求。
Sentry授权包括以下几种角色：
资源：可能是Server、Database、Table、或者URL(例如：HDFS或者本地路径)。Sentry1.5中支持对列进行授权。
权限：授权访问某一个资源的规则。
角色：角色是一系列权限的集合。
用户和组：一个组是一系列用户的集合。Sentry 的组映射是可以扩展的，默认情况下Sentry使用Hadoop的组映射(可以是操作系统组或者LDAP中的组)。Sentry允许你将用户和组进行关联，你可以将一系列的用户放入到一个组中。Sentry不能直接给一个用户或组授权，需要将权限授权给角色，角色可以授权给一个组而不是一个用户。
组件
Sentry Server
Sentry RPC服务器管理授权元数据。它支持安全检索和操作元数据的接口。在CDH5.13及更高版本中，您可以配置多个Sentry服务以实现高可用性。
Data Engine
这是一个数据处理应用程序，如Hive或Impala，需要授权访问数据或元数据资源。数据引擎加载Sentry插件，拦截所有访问资源的客户端请求并将其路由到Sentry插件进行验证。
Sentry Plugin
Sentry插件在数据引擎中运行。它提供了操作存储在Sentry服务器中的授权元数据的接口，包括授权策略引擎，该引擎使用从服务器检索的授权元数据来评估访问请求。
Policy metadata
存储权限策略数据，一般是外部存储db。
关键概念
Authentication: 验证凭据以识别用户
Authorization: 限制用户访问指定资源
User: 由认证系统识别的用户
Group: 由身份验证系统维护的一组用户- 由认证系统维护的一组用户
Privilege: 允许访问对象的指令或规则
Role: 一组Privilege，用于组合多个访问规则的模板
Authorization models: 定义要受授权规则约束的对象以及允许的操作粒度。例如，在SQL中，对象可以是数据库或表，操作是SELECT,INSERT和CREATE 等等。在Solr中，对象是索引，集合和文档， 访问模式是query，update等。
Sentry参与授权的角色
Resource: 资源是您要管理访问权限的对象
Privilege: 默认情况下，Sentry不允许访问任何资源，除非明确授予。权限本质上是授予对资源的访问权限的规则。
Role: 角色是一组Privilege。
Group: 组是用户的集合。Sentry组映射是可扩展的。默认情况下，Sentry利用Hadoop的组映射(可以是OS组或LDAP组)。Sentry允许您将角色与组关联，可以将多个用户组合到一个组中。
注意：Sentry仅支持基于角色的访问控制。无法直接向用户或组授予权限，需要在角色下组合权限。只能将角色授予组，而不能直接授予用户。
Sentry鸟瞰图
Binding
实现了对不同的查询引擎授权，是调用工具和Sentry授权之间的桥梁。Sentry将自己的Hook函数插入到各SQL引擎的编译、执行的不同阶段。这些Hook函数起两大作用：一是起过滤器的作用，只放行具有相应数据对象访问权限的SQL查询；二是起授权接管的作用，使用了Sentry之后，grant/revoke管理的权限完全被Sentry接管，grant/revoke的执行也完全在Sentry中实现；对于所有引擎的授权信息也存储在由Sentry设定的统一的数据库中。这样所有引擎的权限就实现了集中管理。
Policy Engine
这是Sentry授权的核心。判断从binding层获取请求权限与服务提供层已保存的权限描述是否匹配。
Policy Provider
用于为Policy Engine提供授权元数据的抽象，负责从存储库中读取出原先设定的访问权限。目前Sentry支持基于文件的存储和基于数据库的存储开箱即用。
File based provider
基于文件的提供者使用的是ini格式的文件保存元数据信息，这个文件可以是一个本地文件或者HDFS文件。策略文件包含一个包含组到角色映射的groups部分，roles部分包含特权映射的角色。但是基于文件的方式不易于使用程序修改，在修改过程中会存在资源竞争，不利于维护。下面是一个例子:
[groups]
# Assigns each Hadoop group to its set of roles manager = analyst_role, junior_analyst_role
analyst = analyst_role
admin = admin_role
[roles]
analyst_role = server=server1->db=analyst1, \
server=server1->db=jranalyst1->table=*->action=select, \
server=server1->uri=hdfs://ha-nn-uri/landing/analyst1, \
server=server1->db=default->table=tab2
# Implies everything on server1.
admin_role = server=server1
DB based provider
Sentry 策略存储和Sentry服务将角色保留为RDBMS中的特权和分组到角色映射，并提供编程API来创建，查询，更新和删除它。这使各种Sentry客户端能够同时安全地检索和修改权限。Sentry Policy Store可以使用多种数据库，例如MySQL、Postgres等等，它使用ORM库DataNucleus来完成持久化操作。Sentry Service支持Kerberos身份验证，也可以扩展代码支持其他认证方式。
与Hadoop生态系统的集成
Apache Sentry可以与多个Hadoop组件一起工作。从本质上讲，您拥有存储授权元数据的Sentry Server，并提供API工具以安全地检索和修改此元数据。
注意：Sentry Server主要用于管理元数据。实际的授权决策由在Hive或Impala等数据处理应用程序中运行的策略引擎判断。每个组件都加载Sentry插件，其中包括用于处理Sentry服务的客户端和用于验证授权请求的策略引擎。
使用案例
1、Hive和Sentry
查询授权
Sentry Policy Engine 通过 Hook 函数插入 Hive ，HiveServer2在查询成功编译后执行 Hook 函数。
Hook 函数获取查询以读写模式访问的对象列表。Sentry Hive Binding 将此转换为基于SQL权限模型的授权请求。
策略操作
在查询编译期间，Hive调用Sentry的授权任务工厂，该工厂生成在查询处理期间执行的Sentry特定任务。
调用Sentry存储客户端，向 Sentry 服务发送 RPC 请求，以进行授权策略更改。
HCatalog 集成
Sentry通过 pre-listener hooks 集成到 Hive Metastore 中。Metastore 在执行元数据操作请求之前执行此 hooks 。Metastore Binding 为 Metastore/HCatalog 客户端的元数据修改请求创建 Sentry 授权请求。
2、Impala和Sentry
Impala中的授权处理与Hive中的授权处理类似。主要区别在于权限的缓存。Impala的Catalog服务管理缓存schema元数据并将其传播到所有Impala Daemon节点。此Catalog服务也缓存Sentry元数据。因此，Impala的授权在本地就可以实现，速度更快。
3、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以保持元数据更改同步。
例如，如果Bob运行从Sales表读取数据文件的Pig作业，Pig将尝试从HDFS获取文件句柄。此时，NameNode上的Sentry插件将确定该文件是Hive数据的一部分，并在文件ACL之上覆盖Sentry权限。因此，跟Hive执行SQL一样，HDFS会为该Pig客户端强制实施相同的权限检查。
4、Solr和Sentry
Sentry可以对各种Solr任务实施权限管控，包括访问数据和创建collection。无论用户尝试执行何种操作，Sentry都会进行权限管控。例如，不管查询是来自命令行，浏览器还是管理控制台，都会对collection中的数据进行相同的权限检查。
Sentry对Solr的权限控制信息可以保存到Sentry服务的数据库中，也可以以策略文件形式保存，该文件存储在HDFS中，比如：hdfs://ha-nn-uri/user/solr/sentry/sentry-provider.ini。
Solr集成Sentry不支持为多个服务配置同一个策略文件。如果选择使用策略文件而不是Sentry服务的数据库，则必须为每个启用Sentry的服务使用单独的策略文件。比如，如果Hive和Solr都使用策略文件授权，如果你把这2个服务的授权放到同一个策略文件中，将导致配置无效并且两个服务商的授权失败。
Sentry服务和策略文件都可以管理Solr权限。Cloudera建议您使用Sentry服务，这样可以更轻松地管理用户权限。
授权管理
Sentry Server 支持API以安全地操纵角色和特权，Hive和Impala都支持SQL语句本机管理权限。Sentry会认为运行HiveServer2和Impala服务的用户作为超级管理员，通常称为 hive 和 impala；如果要管理权限，必须使用超级管理员登录Sentry。可以使用Beeline或Impala shell执行以下示例语句：
GRANT ROLE Analyst TO GROUP finance_managers
禁用Hive CLI
要执行Hive查询，必须使用Beeline。Sentry不支持Hive CLI，因此必须禁用其对 Hive Metastore 的访问权限。如果Hive Metastore中有敏感数据，尤其重要。因此需要在在Hive Metastore主机上修改 core-site.xml 文件中的hadoop.proxyuser.hive.groups属性。
例如，让hive用户仅模拟hive和hue组成员的权限，请将该属性设置为：hive，hue。
<property>
<name>hadoop.proxyuser.hive.groups</name>
<value>hive,hue</value>
</property>
需要更多用户组可以访问Hive Metastore,可以在列表中添加用逗号分隔。
使用Hue管理Sentry权限
Hue中有一个安全模块可以提供界面化管理Sentry授权，这允许用户浏览和更改表权限。
参考来源：
Apache Sentry架构介绍
Apache Sentry详细讲解
最新版本：2.1
项目主页：
https://sentry.apache.org
https://docs.cloudera.com/documentation/enterprise/5-9-x/topics/sentry_intro.html
Apache Sentry™ is a system for enforcing fine grained role based authorization to data and metadata stored on a Hadoop cluster. it is a granular, role-based authorization module for Hadoop. Sentry provides the ability to control and enforce precise levels of privileges on data for authenticated users and applications on a Hadoop cluster. Sentry currently works out of the box with Apache Hive, Hive Metastore/HCatalog, Apache Solr, Impala, and HDFS (limited to Hive table data). it's designed to be a pluggable authorization engine for Hadoop components. It allows you to define authorization rules to validate a user or application's access requests for Hadoop resources. Sentry is highly modular and can support authorization for a wide variety of data models in Hadoop.
特性
用户身份和组映射
Sentry依靠底层身份验证系统(如Kerberos或LDAP)来识别用户。它还使用Hadoop中配置的组映射机制来确保Sentry看到与Hadoop生态系统的其他组件相同的组映射。假设有一个组织机构，用户Alice和Bob属于名为finance-department的Active Directory(AD)组。Bob同时也属于一个名为finance-managers的组。在Sentry中，首先创建角色，然后为这些角色授予权限。例如，您可以创建一个名为Analyst的角色，并将表Customer和Sales上的SELECT授予此角色。
基于角色的访问控制
基于角色的访问控制(RBAC)是一种强大的机制，用于管理典型企业中大量用户和数据对象的授权。添加或删除新数据对象，用户一直加入，移动或离开组织。RBAC使管理更容易。继续上面的例子，如果新员工Carol加入财务部门，需要做的就是将她添加到AD中的finance-managers组。这就可以实现Carol访问Sales和Customer表中的数据。
统一授权
Sentry的另一个重要方面是统一授权。访问控制规则一旦定义，就可以跨多个数据访问工具工作。
优缺点：
支持细粒度的hdfs元数据访问控制，对hive支持列级别的访问控制
通过基于角色的授权简化了管理，将访问同一数据集的不同特权级别授予多个角色
提供了一个统一平台方便管理与Kerberos集成
组件只支持hive,hdfs,impala 不支持hbase，yarn，kafka，storm等
架构
Apache Sentry是Hadoop的授权模块，它提供了为正确的用户和应用程序提供精确级别访问所需的基于角色的精细授权。
在Sentry诞生之前，对于授权有两种备选解决方案：粗粒度级的HDFS授权和咨询授权，但它们并不符合典型的规范和数据安全需求，原因如下：
粗粒度级的HDFS授权：安全访问和授权的基本机制被HDFS文件模型的粒度所限制。五级授权是粗粒度的，因为没有对文件内数据的访问控制：用户要么可以访问整个文件，要么什么都看不到。另外，HDFS权限模式不允许多个组对同一数据集有不同级别的访问权限。
咨询授权：咨询授权在Hive中是一个很少使用的机制，旨在使用户能够自我监管，以防止意外删除或重写数据。这是一种“自服务”模式，因为用户可以为自己授予任何权限。因此，一旦恶意用户通过认证，它不能阻止其对敏感数据的访问。
通过引进Sentry，Hadoop目前可在以下方面满足企业和政府用户的RBAC需求：
安全授权：Sentry可以控制数据访问，并对已通过验证的用户提供数据访问特权。
细粒度访问控制：Sentry支持细粒度的Hadoop数据和元数据访问控制。在Hive和Impala中Sentry的最初发行版本中，Sentry在服务器、数据库、表和视图范围提供了不同特权级别的访问控制，包括查找、插入等，允许管理员使用视图限制对行或列的访问。管理员也可以通过Sentry和带选择语句的视图或UDF，根据需要在文件内屏蔽数据。
基于角色的管理：Sentry通过基于角色的授权简化了管理，你可以轻易将访问同一数据集的不同特权级别授予多个组。
多租户管理：Sentry允许为委派给不同管理员的不同数据集设置权限。在Hive/Impala的情况下，Sentry可以在数据库/schema级别进行权限管理。
统一平台：Sentry为确保数据安全，提供了一个统一平台，使用现有的Hadoop Kerberos实现安全认证。同时，通过Hive或Impala访问数据时可以使用同样的Sentry协议。未来，Sentry协议会被扩展到其它组件。
Apache Sentry的目标是实现授权管理，它是一个策略引擎，被数据处理工具用来验证访问权限。它也是一个高度扩展的模块，可以支持任何的数据模型。当前，它支持Apache Hive和Cloudera Impala的关系数据模型，以及Apache中的有继承关系的数据模型。
Sentry提供了定义和持久化访问资源的策略的方法。目前，这些策略可以存储在文件里或者是能使用RPC服务访问的数据库后端存储里。数据访问工具，例如Hive，以一定的模式辨认用户访问数据的请求，例如从一个表读一行数据或者删除一个表。这个工具请求Sentry验证访问是否合理。Sentry构建请求用户被允许的权限的映射并判断给定的请求是否允许访问。请求工具这时候根据Sentry的判断结果来允许或者禁止用户的访问请求。
Sentry授权包括以下几种角色：
资源：可能是Server、Database、Table、或者URL(例如：HDFS或者本地路径)。Sentry1.5中支持对列进行授权。
权限：授权访问某一个资源的规则。
角色：角色是一系列权限的集合。
用户和组：一个组是一系列用户的集合。Sentry 的组映射是可以扩展的，默认情况下Sentry使用Hadoop的组映射(可以是操作系统组或者LDAP中的组)。Sentry允许你将用户和组进行关联，你可以将一系列的用户放入到一个组中。Sentry不能直接给一个用户或组授权，需要将权限授权给角色，角色可以授权给一个组而不是一个用户。
组件
Sentry Server
Sentry RPC服务器管理授权元数据。它支持安全检索和操作元数据的接口。在CDH5.13及更高版本中，您可以配置多个Sentry服务以实现高可用性。
Data Engine
这是一个数据处理应用程序，如Hive或Impala，需要授权访问数据或元数据资源。数据引擎加载Sentry插件，拦截所有访问资源的客户端请求并将其路由到Sentry插件进行验证。
Sentry Plugin
Sentry插件在数据引擎中运行。它提供了操作存储在Sentry服务器中的授权元数据的接口，包括授权策略引擎，该引擎使用从服务器检索的授权元数据来评估访问请求。
Policy metadata
存储权限策略数据，一般是外部存储db。
关键概念
Authentication: 验证凭据以识别用户
Authorization: 限制用户访问指定资源
User: 由认证系统识别的用户
Group: 由身份验证系统维护的一组用户- 由认证系统维护的一组用户
Privilege: 允许访问对象的指令或规则
Role: 一组Privilege，用于组合多个访问规则的模板
Authorization models: 定义要受授权规则约束的对象以及允许的操作粒度。例如，在SQL中，对象可以是数据库或表，操作是SELECT,INSERT和CREATE 等等。在Solr中，对象是索引，集合和文档， 访问模式是query，update等。
Sentry参与授权的角色
Resource: 资源是您要管理访问权限的对象
Privilege: 默认情况下，Sentry不允许访问任何资源，除非明确授予。权限本质上是授予对资源的访问权限的规则。
Role: 角色是一组Privilege。
Group: 组是用户的集合。Sentry组映射是可扩展的。默认情况下，Sentry利用Hadoop的组映射(可以是OS组或LDAP组)。Sentry允许您将角色与组关联，可以将多个用户组合到一个组中。
注意：Sentry仅支持基于角色的访问控制。无法直接向用户或组授予权限，需要在角色下组合权限。只能将角色授予组，而不能直接授予用户。
Sentry鸟瞰图
Binding
实现了对不同的查询引擎授权，是调用工具和Sentry授权之间的桥梁。Sentry将自己的Hook函数插入到各SQL引擎的编译、执行的不同阶段。这些Hook函数起两大作用：一是起过滤器的作用，只放行具有相应数据对象访问权限的SQL查询；二是起授权接管的作用，使用了Sentry之后，grant/revoke管理的权限完全被Sentry接管，grant/revoke的执行也完全在Sentry中实现；对于所有引擎的授权信息也存储在由Sentry设定的统一的数据库中。这样所有引擎的权限就实现了集中管理。
Policy Engine
这是Sentry授权的核心。判断从binding层获取请求权限与服务提供层已保存的权限描述是否匹配。
Policy Provider
用于为Policy Engine提供授权元数据的抽象，负责从存储库中读取出原先设定的访问权限。目前Sentry支持基于文件的存储和基于数据库的存储开箱即用。
File based provider
基于文件的提供者使用的是ini格式的文件保存元数据信息，这个文件可以是一个本地文件或者HDFS文件。策略文件包含一个包含组到角色映射的groups部分，roles部分包含特权映射的角色。但是基于文件的方式不易于使用程序修改，在修改过程中会存在资源竞争，不利于维护。下面是一个例子:
[groups]
# Assigns each Hadoop group to its set of roles manager = analyst_role, junior_analyst_role
analyst = analyst_role
admin = admin_role
[roles]
analyst_role = server=server1->db=analyst1, \
server=server1->db=jranalyst1->table=*->action=select, \
server=server1->uri=hdfs://ha-nn-uri/landing/analyst1, \
server=server1->db=default->table=tab2
# Implies everything on server1.
admin_role = server=server1
DB based provider
Sentry 策略存储和Sentry服务将角色保留为RDBMS中的特权和分组到角色映射，并提供编程API来创建，查询，更新和删除它。这使各种Sentry客户端能够同时安全地检索和修改权限。Sentry Policy Store可以使用多种数据库，例如MySQL、Postgres等等，它使用ORM库DataNucleus来完成持久化操作。Sentry Service支持Kerberos身份验证，也可以扩展代码支持其他认证方式。
与Hadoop生态系统的集成
Apache Sentry可以与多个Hadoop组件一起工作。从本质上讲，您拥有存储授权元数据的Sentry Server，并提供API工具以安全地检索和修改此元数据。
注意：Sentry Server主要用于管理元数据。实际的授权决策由在Hive或Impala等数据处理应用程序中运行的策略引擎判断。每个组件都加载Sentry插件，其中包括用于处理Sentry服务的客户端和用于验证授权请求的策略引擎。
使用案例
1、Hive和Sentry
查询授权
Sentry Policy Engine 通过 Hook 函数插入 Hive ，HiveServer2在查询成功编译后执行 Hook 函数。
Hook 函数获取查询以读写模式访问的对象列表。Sentry Hive Binding 将此转换为基于SQL权限模型的授权请求。
策略操作
在查询编译期间，Hive调用Sentry的授权任务工厂，该工厂生成在查询处理期间执行的Sentry特定任务。
调用Sentry存储客户端，向 Sentry 服务发送 RPC 请求，以进行授权策略更改。
HCatalog 集成
Sentry通过 pre-listener hooks 集成到 Hive Metastore 中。Metastore 在执行元数据操作请求之前执行此 hooks 。Metastore Binding 为 Metastore/HCatalog 客户端的元数据修改请求创建 Sentry 授权请求。
2、Impala和Sentry
Impala中的授权处理与Hive中的授权处理类似。主要区别在于权限的缓存。Impala的Catalog服务管理缓存schema元数据并将其传播到所有Impala Daemon节点。此Catalog服务也缓存Sentry元数据。因此，Impala的授权在本地就可以实现，速度更快。
3、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以保持元数据更改同步。
例如，如果Bob运行从Sales表读取数据文件的Pig作业，Pig将尝试从HDFS获取文件句柄。此时，NameNode上的Sentry插件将确定该文件是Hive数据的一部分，并在文件ACL之上覆盖Sentry权限。因此，跟Hive执行SQL一样，HDFS会为该Pig客户端强制实施相同的权限检查。
4、Solr和Sentry
Sentry可以对各种Solr任务实施权限管控，包括访问数据和创建collection。无论用户尝试执行何种操作，Sentry都会进行权限管控。例如，不管查询是来自命令行，浏览器还是管理控制台，都会对collection中的数据进行相同的权限检查。
Sentry对Solr的权限控制信息可以保存到Sentry服务的数据库中，也可以以策略文件形式保存，该文件存储在HDFS中，比如：hdfs://ha-nn-uri/user/solr/sentry/sentry-provider.ini。
Solr集成Sentry不支持为多个服务配置同一个策略文件。如果选择使用策略文件而不是Sentry服务的数据库，则必须为每个启用Sentry的服务使用单独的策略文件。比如，如果Hive和Solr都使用策略文件授权，如果你把这2个服务的授权放到同一个策略文件中，将导致配置无效并且两个服务商的授权失败。
Sentry服务和策略文件都可以管理Solr权限。Cloudera建议您使用Sentry服务，这样可以更轻松地管理用户权限。
授权管理
Sentry Server 支持API以安全地操纵角色和特权，Hive和Impala都支持SQL语句本机管理权限。Sentry会认为运行HiveServer2和Impala服务的用户作为超级管理员，通常称为 hive 和 impala；如果要管理权限，必须使用超级管理员登录Sentry。可以使用Beeline或Impala shell执行以下示例语句：
GRANT ROLE Analyst TO GROUP finance_managers
禁用Hive CLI
要执行Hive查询，必须使用Beeline。Sentry不支持Hive CLI，因此必须禁用其对 Hive Metastore 的访问权限。如果Hive Metastore中有敏感数据，尤其重要。因此需要在在Hive Metastore主机上修改 core-site.xml 文件中的hadoop.proxyuser.hive.groups属性。
例如，让hive用户仅模拟hive和hue组成员的权限，请将该属性设置为：hive，hue。
<property>
<name>hadoop.proxyuser.hive.groups</name>
<value>hive,hue</value>
</property>
需要更多用户组可以访问Hive Metastore,可以在列表中添加用逗号分隔。
使用Hue管理Sentry权限
Hue中有一个安全模块可以提供界面化管理Sentry授权，这允许用户浏览和更改表权限。
参考来源：
Apache Sentry架构介绍
Apache Sentry详细讲解
最新版本：2.1
项目主页：
https://sentry.apache.org
https://docs.cloudera.com/documentation/enterprise/5-9-x/topics/sentry_intro.html