0633-6.2.0-什么是Apache Sentry
0633-6.2.0-什么是Apache Sentry
Apache Sentry是Hadoop中的一个基于角色的细粒度授权组件。Sentry可以在Hadoop集群上对通过身份认证的用户和应用程序控制数据访问权限。Sentry开箱即用的支持Hive，Hive Metastore/HCatalog，Solr，Impala，HDFS(仅限Hive表数据)，Kafka和Kudu(通过Impala)。
Sentry旨在成为Hadoop各组件的可插拔授权引擎。它允许您定义授权规则以验证用户或应用程序对Hadoop资源的访问请求。Sentry是高度模块化的，可以支持Hadoop中各种数据模型的授权。
1
架构概述
1.1
Sentry组件
授权过程涉及三个组件：
- Sentry Server
Sentry的RPC服务管理授权元数据。它支持安全检索和操作元数据的接口。在CDH5.13及更高版本中，您可以配置多个Sentry服务以实现高可用性。
- Data Engine
这是一个数据处理应用程序，比如Hive或Impala，它们需要授权访问数据或元数据资源。数据引擎(data engine)加载Sentry插件，拦截所有客户端访问资源的请求并将其路由到Sentry插件进行验证。
- Sentry Plugin
Sentry plugin在data engine中运行。它提供了操作存储在Sentry Server中的授权元数据的接口，包括授权策略引擎，该引擎使用从服务器检索的授权元数据来评估访问请求。
1.2
关键概念
- Authentication - 验证凭据以识别用户
- Authorization - 限制用户访问指定的资源
- User - 由认证系统识别的用户
- Group - 由认证系统维护的一组用户
- Privilege - 允许访问对象的指令或规则
- Role - 一组privilege，用于组合多个访问规则的模板
- Authorization models - 定义要受授权规则约束的对象以及允许的操作粒度。例如，在SQL中，对象可以是数据库或表，操作是SELECT，INSERT和CREATE。在Solr中，对象是indexes，configs，collections和documents；访问模式包括query和update。
1.3
用户身份和组映射
Sentry依赖底层的身份认证系统，比如Kerberos或LDAP来识别用户。它还使用Hadoop中配置的组映射(group mapping)机制来确保Sentry看到与Hadoop生态系统的其他组件相同的组映射(group mapping)。
假设有一个组织机构，用户Alice和Bob属于名为finance-department的Active Directory（AD）组。Bob同时也属于一个名为finance-managers的组。在Sentry中，首先创建角色，然后为这些角色授予权限。例如，您可以创建一个名为Analyst的角色，并将表Customer和Sales上的SELECT授予此角色。
1.4
基于角色的访问控制
基于角色的访问控制(Role-based access control, RBAC)是一种典型的用于管理企业中大量用户和数据对象授权的强大机制。经常发生的新数据对象添加或删除，用户加入，移动或离开。RBAC可以使这些管理更加容易。我们继续继续上章提到的例子，如果新员工Carol加入财务部门，您需要做的就是将她添加到AD中的finance-managers组。这就可以实现Carol访问Sales和Customer表中的数据。
2
Sentry与Hadoop生态系统的集成
如上图所示，Apache Sentry可以与多个Hadoop组件一起工作。从本质上讲，您拥有存储授权元数据的Sentry Server，并提供API工具以安全地检索和修改此元数据。
请注意，Sentry Server主要用于管理元数据。实际的授权决策由在Hive或Impala等数据处理应用程序中运行的策略引擎判断。每个组件都加载Sentry插件，其中包括用于处理Sentry服务的客户端和用于验证授权请求的策略引擎。
2.1
Hive和Sentry
举一个例子来说明Hive获取客户端以特定模式访问对象的请求。如果Bob提交以下Hive查询：
select * from production.salesHive将识别用户Bob正在请求对Sales表的SELECT访问。此时，Hive将要求Sentry插件验证Bob的访问请求。该插件将检索Bob与Sales表相关的权限，策略引擎将确定该请求是否有效。
Sentry服务和策略文件都可以管理Hive权限。Cloudera建议您使用Sentry服务，这样可以更轻松地管理用户权限。
2.2
Impala和Sentry
Impala中的授权处理与Hive中的授权处理类似。主要区别在于权限的缓存。Impala的Catalog服务管理缓存schema元数据并将其传播到所有Impala Daemon节点。此Catalog服务也缓存Sentry元数据。因此，Impala的授权在本地就可以实现，速度更快。
2.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客户端强制实施相同的权限检查。
2.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服务，这样可以更轻松地管理用户权限。
2.5
授权管理
Sentry Server支持API以安全地操纵角色和权限。Hive和Impala都支持SQL语句管理权限。Sentry会认为运行HiveServer2和Impala服务的用户为超级管理员，通常为hive和impala。如果要管理权限，必须使用超级管理员登录Sentry。您可以使用Beeline或Impala shell来执行以下示例语句：
GRANT ROLE Analyst TO GROUP finance_managers2.5.1
禁用Hive CLI
要执行Hive查询，您必须使用Beeline。Sentry不支持Hive CLI，因此必须禁用其对Hive Metastore的访问权限。如果Hive Metastore中有敏感数据，尤其需要注意这一点。因此需要在Cloudera Manager配置Hive服务的Hive Metastore Access Control and Proxy User Groups Override属性。例如，让hive用户仅模拟hive和hue组成员的权限，请将该属性设置为：hive，hue。