Apache Sentry架构介绍

2019独角兽企业重金招聘Python工程师标准>>>

cdh版本的hadoop在对数据安全上的处理通常采用Kerberos+Sentry的结构。
kerberos主要负责平台用户的权限管理，sentry则负责数据的权限管理。

下面我们来依次了解一下：
Kerberos包含一个中心节点和若干从节点，所有节点的Kerberos认证信息都要与中心节点的规则配置文件/etc/krb5.conf保持一致。安全认证均需通过中心节点，配置了安全认证的用户可以登录到集群内的 机器。
Kerberos的配置文件有两个：
1、/var/kerberos/krb5kdc/kdc.conf:包括KDC的配置信息。默认放在 /usr/local/var/krb5kdc。或者通过覆盖KRB5_KDC_PROFILE环境变量修改配置文件位置。
2、/etc/krb5.conf:包含Kerberos的配置信息
Kerberos的管理对象称为principal（规则）, 与HDFS中的用户一一对应。一般我们将hdfs设置为principal的管理员，它可以创建删除其他的principal,还可以生成其他成员的keytab。keytab是每个principal对应的密钥文件，当kerberos认证使用keytab时，可以不需要输入密码，类似于SSH的信任机制。
当我们配置Kerberos的时候，系统会默认生成用户，格式一般为【用户名/hostname@domain_name】，一般情况下我们使用自己定义的用户，不要对系统生成的用户加以修改。
输入kadmin.local 进入Kerberos的交互命令行。
生成keytab: xst –k testuser.keytab testuser@HTHADOOP.COM,将对应的keytab拷贝至其他位置或服务器，则相应的节点则可以通过testuser的principal连接进HDFS.
登录到管理员账户: 如果在本机上，可以通过kadmin.local直接登录。其它机器的，先使用kinit进行验证。
kadmin.local  kinit admin/adminkadmin
增删改查账户:在管理员的状态下使用addprinc,delprinc,modprinc,listprincs命令。使用？可以列出所有的命令。
kamdin:addprinc -randkey hdfs/hadoop1kamdin:delprinc hdfs/hadoop1kamdin:listprincs命令
生成keytab:使用xst命令或者ktadd命令
kadmin:xst -k /xxx/xxx/kerberos.keytab hdfs/hadoop1
创建一个新的principal: addprinc testuser@HADOOP.COM,并输入密码
用户操作
查看当前的认证用户:klist
认证用户:kinit -kt /xx/xx/kerberos.keytab hdfs/hadoop1
删除当前的认证的缓存: kdestroy

Apache Sentry的目标是实现授权管理，它是一个策略引擎，被数据处理工具用来验证访问权限。它也是一个高度扩展的模块，可以支持任何的数据模型。当前，它支持Apache Hive和Cloudera Impala的关系数据模型，对hue的数据权限控制也有应用。
Sentry的管理对象有三个，数据库，角色，和组。数据库是在hive中创建的数据库，角色在impala中创建，而组是操作系统的用户组。
Sentry的权限管理操作，都通过impala语句完成。只有启动了sentry服务，impala服务才能正常运行。
使用impala-shell进入交互终端：
show roles列出所有的角色
show databases列出所有的数据库
create role test_role创建角色
drop role test_role删除角色
可以直接输入show命令会提示可以跟接的关键字
grant all on database ana_clientact to role admin_role 将一个数据库赋权给一个角色
revoke all on database from role admin_role取消权限
如果数据库中的是外部表，需要同时给角色赋予uri权限：
grant all on uri 'hdfs://192.168.2.121:8020/mydata' to role admin_role
列出某角色的权限：show grant role admin_role
将角色赋给一个组：grant role admin_role to group hive
完成以上操作以后，用户组即具有了相应数据库的操作权限。此时需要执行invalidate metadata操作，才会生效。
当一个新的操作系统用户加入这个用户组，用户即具有对应的数据库权限。反之，将用户从这个组中去掉，用户对数据库的操作权限即消失。
新建用户组时要保证集群内组和用户保持一致。

在HUE中配置权限
在HUE中，用户的权限是分为两个层次实现的，一个层次是HUE平台各模块的权限，这个通过HUE中组和权限实现的，另一个层次是HUE访问hive,impala数据库的权限，这个和sentry是统一的，HUE中的用户和操作系统中的用户一一映射，HUE通过寻找相同用户名的操作系统用户来确定对应的sentry权限。
这里需要注意一点，HUE中的组和操作系统的组没有关系，HUE中的组只绑定HUE平台自己的权限。

Apache Sentry 是Cloudera公司发布的一个Hadoop开源组件，截止目前还是Apache的孵化项目，它提供了细粒度级、基于角色的授权以及多租户的管理模式。Sentry当前可以和Hive/Hcatalog、Apache Solr 和Cloudera Impala集成，未来会扩展到其他的Hadoop组件，例如HDFS和HBase。

特性

Apache Sentry为Hadoop使用者提供了以下便利：

• 能够在Hadoop中存储更敏感的数据
• 使更多的终端用户拥有Hadoop数据访问权
• 创建更多的Hadoop使用案例
• 构建多用户应用程序
• 符合规范（例如SOX，PCI，HIPAA，EAL3）

在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架构图，图片来自《 Apache Sentry architecture overview 》。

Sentry的体系结构中有三个重要的组件：一是Binding；二是Policy Engine；三是Policy Provider。

Binding

Binding实现了对不同的查询引擎授权，Sentry将自己的Hook函数插入到各SQL引擎的编译、执行的不同阶段。这些Hook函数起两大作用：一是起过滤器的作用，只放行具有相应数据对象访问权限的SQL查询；二是起授权接管的作用，使用了Sentry之后，grant/revoke管理的权限完全被Sentry接管，grant/revoke的执行也完全在Sentry中实现；对于所有引擎的授权信息也存储在由Sentry设定的统一的数据库中。这样所有引擎的权限就实现了集中管理。

Policy Engine

这是Sentry授权的核心组件。Policy Engine判定从binding层获取的输入的权限要求与服务提供层已保存的权限描述是否匹配。

Policy Provider

Policy Provider负责从文件或者数据库中读取出原先设定的访问权限。Policy Engine以及Policy Provider其实对于任何授权体系来说都是必须的，因此是公共模块，后续还可服务于别的查询引擎。

基于文件的提供者使用的是ini格式的文件保存元数据信息，这个文件可以是一个本地文件或者HDFS文件。下面是一个例子：

1. [groups]

2. # Assigns each Hadoop group to its set of roles

3. manager = analyst_role, junior_analyst_role

4. analyst = analyst_role

5.  

6. admin = admin_role

7. [roles]

8. analyst_role = server=server1->db=analyst1, \

9. server=server1->db=jranalyst1->table=*->action=select, \

10. server=server1->uri=hdfs://ha-nn-uri/landing/analyst1, \

11. server=server1->db=default->table=tab2

12. # Implies everything on server1.

13. admin_role = server=server1

14.  

基于文件的方式不易于使用程序修改，在修改过程中会存在资源竞争，不利于维护。Hive和Impala需要提供工业标准的SQL接口来管理授权策略，要求能够使用编程的方式进行管理。

Sentry策略存储和服务将角色和权限以及组合角色的映射持久化到一个关系数据库并提供编程的API接口方便创建、查询、更新和删除。这允许Sentry的客户端并行和安全地获取和修改权限。

Sentry策略存储可以使用很多后端的数据库，例如MySQL、Postgres等等，它使用ORM库DataNucleus来完成持久化操作。Sentry支持kerberos认证，也可以扩展代码支持其他认证方式。

使用

和Hive集成

Sentry策略引擎通过hook的方式插入到hive中，hiveserver2在查询成功编译之后执行这个hook。

这个hook获得这个查询需要以读和写的方式访问的对象，然后Sentry的Hive binding基于SQL授权模型将他们转换为授权的请求。

策略维护：

策略维护包括两个步骤。在查询编译期间，hive调用Sentry的授权任务工厂来生产会在查询过程中执行的Sentry的特定任务行。这个任务调用Sentry存储客户端发送RPC请求给Sentry服务要求改变授权策略。

和HCatalog集成

Sentry通过pre-listener hook集成到Hive Metastore。metastore在执行metadata维护请求之前执行这个hook。metastore binding为提交给metastore和HCatalog客户端的metadata修改请求创建一个Sentry授权请求。

一、Sentry CDH配置
安装Sentry
使用Cloudera Manager来安装，非常简单，需要注意的是安装前要在/opt/cloudera/parcels/CDH/jars目录下放入MySQL的驱动包。

添加服务 –> Sentry

 

Sentry Database Create:

#为Sentry建数据库sentry
mysql>create database sentry DEFAULT CHARSET utf8 COLLATE utf8_general_ci;
1
2

Sentry集成其它组件
Sentry 集成其它组件

补充：

添加 Hive, Impala, HUE, HUE 默认超级管理员组到 Sentry admin 组

在 Clouder Manager 对 Sentry 进行配置，修改 Admin Group，添加hive，impala， hue，admin(hue的默认超级管理员)，重启 Sentry 服务。

添加admin组的原因是，我们使用admin登录Hue，然后对角色权限进行控制。当然使用上面添加的hive、impala、hue也可以。

二、Sentry授权步骤
1.在所有节点的机器上创建用户和组

2.在hue建用户和组，这里的用户和组要求和第一部linux的用户和组是一样

3.登录管理员用户，给其他用户付权限

4.建role，和给role付权限

如下图，点击Sentry进入编辑页面，选上test1用户

点击右侧的 addrole

填角色名称，角色所属的组，和角色的权限

5.用对应的test1登录，可以看到自己权限的数据表

四、linux加用户组
# groupadd  g1

# useradd   u1

# usermod -g   g1 u1

impala授权

SHOW CREATE table hue.auth_permission;
ALTER TABLE hue.auth_permission DROP FOREIGN KEY content_type_id_refs_id_id value;
DELETE FROM hue.django_content_type;
ALTER TABLE hue.auth_permission ADD FOREIGN KEY (content_type_id) REFERENCES django_content_type (id);

为HDFS定义URI时，还必须指定NameNode。例如：
GRANT ALL ON URI文件：/// path / to / dir TO <role>
GRANT ALL ON URI hdfs：// namenode：port / path / to / dir TO <role>
GRANT ALL ON URI hdfs：// ha -nn-uri / path / to / dir TO <role>
管理用户的权限示例
在此示例中，SQL语句授予 entire_server 角色服务器中的数据库和URI的所有特权。

CREATE ROLE whole_server;
GRANT ROLE whole_server TO GROUP admin_group;
GRANT ALL ON SERVER server1 TO ROLE whole_server;

具有特定数据库和表的权限的用户
如果用户具有特定数据库中特定表的权限，则用户可以访问这些内容，但不能访问其他内容。他们可以在输出中看到表及其父数据库 显示表格 和 显示数据库， 使用 适当的数据库，并执行相关的行动（选择 和/或 插）基于表权限。要实际创建表需要所有 数据库级别的权限，因此您可以为用户设置单独的角色，以设置架构以及对表执行日常操作的其他用户或应用程序。
CREATE ROLE one_database;
GRANT ROLE one_database TO GROUP admin_group;
GRANT ALL ON DATABASE db1 TO ROLE one_database;

CREATE ROLE instructor;
GRANT ROLE instructor TO GROUP trainers;
GRANT ALL ON TABLE db1.lesson TO ROLE instructor;

# This particular course is all about queries, so the students can SELECT but not INSERT or CREATE/DROP.
CREATE ROLE student;
GRANT ROLE student TO GROUP visitors;
GRANT SELECT ON TABLE db1.training TO ROLE student;

使用外部数据文件的权限
通过数据插入数据时 负载数据 语句，或从普通Impala数据库目录之外的HDFS位置引用，用户还需要对与这些HDFS位置对应的URI的适当权限。

在这个例子中：

该 external_table 角色可以插入并查询Impala表， external_table.sample。
该 STAGING_DIR角色可以指定HDFS路径/用户/ Cloudera的/ external_data与负载数据声明。当Impala查询或加载数据文件时，它会对该目录中的所有文件进行操作，而不仅仅是单个文件，因此任何Impala都可以位置 参数指的是目录而不是单个文件。
CREATE ROLE external_table; 
GRANT ROLE external_table TO GROUP cloudera; 
GRANT ALL ON TABLE external_table.sample TO ROLE external_table; 

CREATE ROLE staging_dir; 
GRANT ROLE staging TO GROUP cloudera; 
GRANT ALL ON URI'hdfs：//127.0.0.1：8020 / user / cloudera / external_data'TO ROLE staging_dir;

将管理员职责与读写权限分开
要创建数据库，您需要该数据库的完全权限，而对该数据库中的表的日常操作可以在特定表上使用较低级别的权限执行。因此，您可以为每个数据库或应用程序设置单独的角色：可以创建或删除数据库的管理角色，以及只能访问相关表的用户级角色。

在此示例中，职责分为3个不同组中的用户：
CREATE ROLE training_sysadmin;
GRANT ROLE training_sysadmin TO GROUP supergroup;
GRANT ALL ON DATABASE training1 TO ROLE training_sysadmin;

CREATE ROLE instructor;
GRANT ROLE instructor TO GROUP cloudera;
GRANT ALL ON TABLE training1.course1 TO ROLE instructor;

CREATE ROLE visitor;
GRANT ROLE student TO GROUP visitor;
GRANT SELECT ON TABLE training1.course1 TO ROLE student;

server=server_name->db=database_name->table=table_name->action=SELECT
server=server_name->db=database_name->table=table_name->action=ALL

server=impala-host.example.com->db=default->table=t1->action=SELECT
server=impala-host.example.com->db=*->table=audit_log->action=SELECT
server=impala-host.example.com->db=default->table=t1->action=*

转载于:https://my.oschina.net/hblt147/blog/2987614