在进行讲解以前,先带你们学习下hadoop关于hdfs本身的安全如何实现的---------------------------shell
名词:数据库
ACL-访问控制列表(Access Control List,ACL)安全
ARBAC-基于角色的权限访问控制(Role-Based Access Control)服务器
全部安全体系的了解,大数据平台安全体系的四个层次提及:外围安全、数据安全、访问安全以及访问行为监控,以下图所示;网络
在这四个安全的层次中,第三层同上层业务的关系最为直接:应用程序的多租户,分权限访问控制都直接依赖这一层的技术实现。架构
普通Hadoop集群中的各个组件一般使用不一样模型进行权限管理。框架
这就意味着为三个组件受权须要登陆三个系统,使用三种不一样的模型受权,为权限运维形成不小的难度。基本上就是访问安全,并无其余安全的防御。。。。运维
问题背景:ide
Hadoop在企业中普遍地应用,愈来愈多的业务场景要求大数据访问控制的粒度也再也不局限在文件级别,而是更加细致地约束文件内部的数据哪些只能被读,哪些彻底不容许被访问。对于基于SQL的大数据引擎来讲,数据访问不止要到表粒度,更要精确到行列级别。函数
安全组件的来源背景:
Hive是早期将高级查询语言SQL引入Hadoop平台的引擎之一,早期的Hive服务器进程被称做Hiveserver1;Hiveserver1既不支持处理并行的多个链接,又不支持访问受权控制;后来这两个问题在Hiveserver2上被解决,Hiveserver2可以使用grant/revoke语句来限制用户对数据库、表、视图的访问权限,行列权限的控制是经过生成视图来实现的;但Hiveserver2的受权管理体系被认为存在问题,那就是任何经过认证登录的用户都可以为本身增长对任何资源的访问权限。也就是说Hiveserver2提供的不是一种安全的受权体系,Hiveserver2的受权体系是为防止正经常使用户误操做而提供保障机制;不是为保护敏感数据的安全性而设计的。然而这些更多的是某些公司的说辞,事实上Hiveserver2自身的安全体系也在逐步完善,上述问题也在快速修复中。
但受权管理其实不止是Hive须要,其余的查询引擎也迫切须要这些技术来完善和规范应用程序对数据的访问。对于细粒度受权管理的实现,很大一部分功能在各引擎之间是能够公用的,所以独立实现的受权管理工具是很是必要的。
在这样的背景下,Cloudera公司的一些开发者利用Hiveserver2中现有使用价值的受权管理工具Sentry,下图是Sentry与Hiveserver2中的受权管理模型的对比:
Sentry的不少基本模型和设计思路都来源于Hiveserver2,但在其基础之上增强了RBAC的概念。在Sentry中,所有相应的权限。权限à角色à用户组à用户,这一条线的映射关系在Sentry中显得尤其清晰,这条线的映射显示了一条权限如何能最后被一个用户所拥Hadoop自身的用户-组映射来实现的。有集中配置,易于修改的好处。
Sentry将Hiveserver2中支持的数据对象从数据库/表/视图扩展到了服务器,URI以及列粒度。虽然列的权限控制能够用视图来实现,可是对于多用户,表数量巨大的状况,视图的方法会使得给视图命名变得异常复杂;并且用户原先写的针对原表的查询语句,这时就没法直接使用,由于视图的名字可能与原表彻底不一样。
目前Sentry1.4可以支持的受权级别还局限于SELECT,INSERT,ALL这三个级别,但后续版本中已经可以支持到与Hiveserver2现有三个重要的组件:一是Binding;二是Policy Engine;三是Policy Provider。
Binding实现了对不一样的查询引擎受权,Sentry将本身的Hook函数插入到各SQL引擎的编译、执行的不一样阶段。这些Hook函数起两大做用:一是起过滤器的做用,只放行具有引擎的受权信息也存储在由Sentry设定的统一的数据库中。这样所有引擎的权限就实现了集中管理。
Policy Engine断定输入的权限要求与已保存的权限描述是否匹配,Policy Provider负责从文件或者数据库中读取出原先设定的访问权限。Policy Engine以及Policy Provider其实对于任何受权体系来讲都是必须的,所以是公共模块,后续还可服务于别的查询引擎。
Guardian 5.0在原有安全解决方案的基础上提供了更加完整的功能以及方便的操做,包括用户认证、受权、配额管理以及资源控制。用户认证经过LDAP以及KERBEROS协议,确保只有通过身份甄别的用户才能访问系统,受权保证只有被赋予权限的用户才能够访问系统资源,配额管理与资源负责控制用户使用的资源大小,三个部分一同保证TDH平台大数据安全。
Guardian 5.0的框架共分为四层:
Guardian底层使用改进的ApacheDS方案,使用同一套用户统一LDAP/Kerberos认证方式,避免OpenLDAP使用Kerberos认证,从而加速LDAP认证效率。另外,Guardian优化了ApacheDS原生的数据存储,使读写效率提高10倍以上。同时还提供了Master-Slave的HA方案,保证用户数据安全和可靠性。
架构第二层是独立的服务Guardian Server,实现完整的ARBAC模型支持,提供了用户友好的Web UI和密码策略等功能支持。Guardian Server对用户认证受权进行了统一化,从Web服务到Hadoop底层使用同一套用户,同一套受权机制;同时开放了LDAP接口、REST API和LoginService,供第三方应用经过Guardian用户进行认证和受权的整合。
第三层使用插件的形式,为TDH各个组件提供认证、受权、组映射以及配额管理,使得TDH组件可使用统一的用户、组和权限管理模型。
架构顶层是与Guardian对接的各类TDH服务,受到Guardian的安全保护。
在Guardian的保护下,全部的应用服务均可以借助Kerberos实现数据加密,或者经过LDAP实现身份验证。各云产品和组件获得租户级别的资源管理,其多租户资源管理模块能够按照租户的方式管理资源,并经过一个图形化工具为用户提供权限配置以及资源配置接口。同时实现HDFS和全部数据库对象的细粒度访问控制。
Guardian引入了加强后的ARBAC(Administrative Role Based Access Control)模型,统一了各个组件的权限管理,使用户使用统一的Web UI或者REST API进行受权,同时也兼容了SQL、HBase shell受权方式,大幅度简化了运维。
Guardian为各个组件提供了完整统一的RBAC的权限管理,包括HDFS、YARN、Inceptor、Hyperbase、Workflow以及Midas服务;支持服务管理员的动态设置,实现服务管理员职责的精细划分,有很高的灵活度和可操做性;对于特定的服务,提供了一些粒度的权限管理,同时提供比表级更细粒度的权限管理,如行级权限管理,知足用户各个层面的权限管理需求。
Guardian配合Inceptor Scheduler提供了对于Inceptor细粒度的资源控制,能够针对用户的不一样权限和优先级,设置合理的资源分配方式。资源管理配置界面支持设置用户容许提交的队列,每一个队列可使用的CPU数量,队列的权重,以及用户可提交的SQL数量上限。同时对HDFS配额、Yarn队列、Inceptor数据库及表的配额以及Discover用户配额提供配置接口。
Guardian实现了标准的LDAP和KERBEROS认证协议,并将全部组件的权限信息都统一集中存储在ApacheDS,使得即便服务处于异常状态甚相当闭,用户仍然能够正常的对服务设置访问权限和配额,成功实现了资源管理与具体的服务之间的解耦。Guardian 5.0还提供了友好的日志系统和报错信息,便于下降运维难度。