Apache Sentry详细讲解

超、凢脫俗 2021-12-04 01:21 644阅读 0赞

1.  #### Sentry 简介 ####
    
    Apache Sentry是Cloudera公司发布的一个Hadoop开源组件，2016年3月从Incubator毕业，成为Apache顶级项目。  
    Sentry是一个基于角色的粒度授权模块，提供了对Hadoop集群上经过身份验证的用户提供了控制和强制访问数据或数据特权的能力。它可以和Hive/Hcatalog、Apache Solr 和Cloudera Impala等集成，未来可以扩展到其他Hadoop生态系统组件，如HDFS和HBase。  
    Sentry旨在成为可插拔授权引擎的Hadoop组件。允许定义授权规则以验证用户或应用程序对Hadoop资源的访问请求。Sentry是高度模块化的，可以支持Hadoop中各种数据模型的授权。
2.  #### Sentry 特性. ####
    
    1.  **用户身份和组映射**
        
        Sentry依靠底层身份验证系统（如Kerberos或LDAP）来识别用户。它还使用Hadoop中配置的组映射机制来确保Sentry看到与Hadoop生态系统的其他组件相同的组映射。
        
        假设有一个组织机构，用户Alice和Bob属于名为finance-department的Active Directory（AD）组。Bob同时也属于一个名为finance-managers的组。在Sentry中，首先创建角色，然后为这些角色授予权限。例如，您可以创建一个名为Analyst的角色，并将表Customer和Sales上的SELECT授予此角色。
    2.  **基于角色的访问控制**
        
        基于角色的访问控制（RBAC）是一种强大的机制，用于管理典型企业中大量用户和数据对象的授权。添加或删除新数据对象，用户一直加入，移动或离开组织。RBAC使管理更容易。
        
        继续上面的例子，如果新员工Carol加入财务部门，您需要做的就是将她添加到AD中的finance-managers组。这就可以实现Carol访问Sales和Customer表中的数据。
    3.  **统一授权**
        
        Sentry的另一个重要方面是统一授权。访问控制规则一旦定义，就可以跨多个数据访问工具工作。
3.  #### Sentry 架构 ####
    
    Apache Sentry是Hadoop的授权模块，它提供了为正确的用户和应用程序提供精确级别访问所需的基于角色的精细授权。
    
    ![20190719134332787.png][]
    
    ##### 组件 #####
    
    1.  **Sentry Server**  
        Sentry RPC服务器管理授权元数据。它支持安全检索和操作元数据的接口。在CDH5.13及更高版本中，您可以配置多个Sentry服务以实现高可用性。
    2.  **Data Engine**  
        这是一个数据处理应用程序，如Hive或Impala，需要授权访问数据或元数据资源。数据引擎加载Sentry插件，拦截所有访问资源的客户端请求并将其路由到Sentry插件进行验证。
    3.  **Sentry Plugin**  
        Sentry插件在数据引擎中运行。它提供了操作存储在Sentry服务器中的授权元数据的接口，包括授权策略引擎，该引擎使用从服务器检索的授权元数据来评估访问请求。
    4.  **Policy metadata**  
        存储权限策略数据，一般是外部存储db。
    
    ##### 关键概念 #####
    
    1.  **Authentication**: 验证凭据以识别用户
    2.  **Authorization**: 限制用户访问指定资源
    3.  **User**: 由认证系统识别的用户
    4.  **Group**: 由身份验证系统维护的一组用户- 由认证系统维护的一组用户
    5.  **Privilege**: 允许访问对象的指令或规则
    6.  **Role**: 一组Privilege，用于组合多个访问规则的模板
    7.  **Authorization models**: 定义要受授权规则约束的对象以及允许的操作粒度。例如，在SQL中，对象可以是数据库或表，操作是SELECT,INSERT和CREATE 等等。在Solr中，对象是索引，集合和文档， 访问模式是query，update等。
    
    ##### Sentry参与授权的角色 #####
    
    1.  **Resource**: 资源是您要管理访问权限的对象
    2.  **Privilege**: 默认情况下，Sentry不允许访问任何资源，除非明确授予。权限本质上是授予对资源的访问权限的规则。
    3.  **Role**: 角色是一组Privilege。
    4.  **Group**: 组是用户的集合。Sentry组映射是可扩展的。默认情况下，Sentry利用Hadoop的组映射(可以是OS组或LDAP组)。Sentry允许您将角色与组关联，可以将多个用户组合到一个组中。
        
        **注意:**  
        Sentry仅支持基于角色的访问控制。无法直接向用户或组授予权限，需要在角色下组合权限。只能将角色授予组，而不能直接授予用户。
    
    ##### Sentry鸟瞰图 #####
    
    ![Sentry鸟瞰图][Sentry]
    
    1.  **Binding**  
        实现了对不同的查询引擎授权，是调用工具和Sentry授权之间的桥梁。Sentry将自己的Hook函数插入到各SQL引擎的编译、执行的不同阶段。这些Hook函数起两大作用：一是起过滤器的作用，只放行具有相应数据对象访问权限的SQL查询；二是起授权接管的作用，使用了Sentry之后，grant/revoke管理的权限完全被Sentry接管，grant/revoke的执行也完全在Sentry中实现；对于所有引擎的授权信息也存储在由Sentry设定的统一的数据库中。这样所有引擎的权限就实现了集中管理。
    2.  **Policy Engine**  
        这是Sentry授权的核心。判断从binding层获取请求权限与服务提供层已保存的权限描述是否匹配。
    3.  **Policy Provider**  
        用于为Policy Engine提供授权元数据的抽象，负责从存储库中读取出原先设定的访问权限。目前Sentry支持基于文件的存储和基于数据库的存储开箱即用。
    4.  **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
    5.  **DB based provider**
        
        Sentry 策略存储和Sentry服务将角色保留为RDBMS中的特权和分组到角色映射，并提供编程API来创建，查询，更新和删除它。这使各种Sentry客户端能够同时安全地检索和修改权限。
        
        ![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzIxNTI1MA_size_16_color_FFFFFF_t_70][]
        
        Sentry Policy Store可以使用多种数据库，例如MySQL、Postgres等等，它使用ORM库DataNucleus来完成持久化操作。  
        Sentry Service支持Kerberos身份验证，也可以扩展代码支持其他认证方式。
4.  #### Sentry与Hadoop生态系统的集成 ####
    
    ![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzIxNTI1MA_size_16_color_FFFFFF_t_70 1][]
    
    Apache Sentry可以与多个Hadoop组件一起工作。从本质上讲，您拥有存储授权元数据的Sentry Server，并提供API工具以安全地检索和修改此元数据。
    
    **注意:**  
    Sentry Server主要用于管理元数据。实际的授权决策由在Hive或Impala等数据处理应用程序中运行的策略引擎判断。每个组件都加载Sentry插件，其中包括用于处理Sentry服务的客户端和用于验证授权请求的策略引擎。
5.  #### Hive和Sentry ####
    
    1.  **查询授权**
        
        Sentry Policy Engine 通过 Hook 函数插入 Hive ，HiveServer2在查询成功编译后执行 Hook 函数。
        
        ![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzIxNTI1MA_size_16_color_FFFFFF_t_70 2][]
        
        Hook 函数获取查询以读写模式访问的对象列表。Sentry Hive Binding 将此转换为基于SQL权限模型的授权请求。
    2.  **策略操作**
        
        1.  在查询编译期间，Hive调用Sentry的授权任务工厂，该工厂生成在查询处理期间执行的Sentry特定任务。
        2.  调用Sentry存储客户端，向 Sentry 服务发送 RPC 请求，以进行授权策略更改。  
            ![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzIxNTI1MA_size_16_color_FFFFFF_t_70 3][]
    3.  **HCatalog 集成**
        
        Sentry通过 pre-listener hooks 集成到 Hive Metastore 中。Metastore 在执行元数据操作请求之前执行此 hooks 。Metastore Binding 为 Metastore/HCatalog 客户端的元数据修改请求创建 Sentry 授权请求。
        
        ![20190719134622719.png][]
6.  #### Impala和Sentry ####
    
    Impala中的授权处理与Hive中的授权处理类似。主要区别在于权限的缓存。Impala的Catalog服务管理缓存schema元数据并将其传播到所有Impala Daemon节点。此Catalog服务也缓存Sentry元数据。因此，Impala的授权在本地就可以实现，速度更快。  
    ![在这里插入图片描述][2019071914503343.png]
7.  #### Sentry-HDFS同步 ####
    
    Sentry-HDFS授权主要针对Hive仓库数据 - 也即Hive或Impala中表的数据。Sentry与HDFS的集成的真正目标是将相同的授权检查扩展到从任何其他组件（如Pig，MapReduce或Spark）访问Hive仓库数据。基于这一点可以利用HDFS已有的ACL功能，但与Sentry无关的表将保留其旧ACL。  
    ![在这里插入图片描述][20190719145102864.png]  
    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客户端强制实施相同的权限检查。
8.  #### 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服务，这样可以更轻松地管理用户权限。
9.  ##### 授权管理 #####
    
    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授权。这允许用户浏览和更改表权限。

参考:

[https://cwiki.apache.org/confluence/display/SENTRY/Sentry+Tutorial\#SentryTutorial-SentryComponents][https_cwiki.apache.org_confluence_display_SENTRY_Sentry_Tutorial_SentryTutorial-SentryComponents]  
[https://blogs.apache.org/sentry/][https_blogs.apache.org_sentry]  
[https://cwiki.apache.org/confluence/display/SENTRY/Home][https_cwiki.apache.org_confluence_display_SENTRY_Home]

[20190719134332787.png]: /images/20211203/4f039c587cdd490a841220c62b9cd7cc.png
[Sentry]: /images/20211203/d458a734db7e4ebca278180408614cd5.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzIxNTI1MA_size_16_color_FFFFFF_t_70]: /images/20211203/0b084f990c4349d783677c843010a633.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzIxNTI1MA_size_16_color_FFFFFF_t_70 1]: /images/20211203/52c06fbe69a64efa8fad74f84b2d82a2.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzIxNTI1MA_size_16_color_FFFFFF_t_70 2]: /images/20211203/c7966022720f4be4858e4d2fac19c9e7.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzIxNTI1MA_size_16_color_FFFFFF_t_70 3]: /images/20211203/2db9df7fd9354f2991368ac266d0673f.png
[20190719134622719.png]: /images/20211203/b665bd47a83946ac9e54694869336131.png
[2019071914503343.png]: /images/20211203/016d81507cb14dd9baaa61c3492c66a8.png
[20190719145102864.png]: /images/20211203/24738c681f354576b633bba3fe597c0d.png
[https_cwiki.apache.org_confluence_display_SENTRY_Sentry_Tutorial_SentryTutorial-SentryComponents]: https://cwiki.apache.org/confluence/display/SENTRY/Sentry+Tutorial#SentryTutorial-SentryComponents
[https_blogs.apache.org_sentry]: https://blogs.apache.org/sentry/
[https_cwiki.apache.org_confluence_display_SENTRY_Home]: https://cwiki.apache.org/confluence/display/SENTRY/Home