上篇我们讨论了权限管控方案在目标，产品形态，实施方式方面的哲学问题，接下来，讨论一下技术方面的问题。你可能会想，如果不需要防止Hack的行为，那应该也不是什么很困难的事吧？
从基本的流程来说，确实如此，所以比如早几年前，我司从内部运营系统到到外部业务系统，各种大大小小的后台，一言不合，就会自己实现一套权限认证管理的方案。说到底，不就是两张表的事么，这有何难。。。
不过，当系统越来越多，环境越来越复杂时，你就会发现这件事并没有那么简单。抛开技术问题不谈，单从用户体验的角度来说，如果要在每个系统中都单独管理自己的用户账号和密码，那肯定疯掉了。所以，最起码你需要一个统一的用户账号体系。
然后，如果各个系统的权限申请，管理，审批流程都不一样，系统开发和用户学习的成本会不会很高？于是，你又会考虑除了账号密码以外，各个后台的权限管理模型也应该统一。
而具体落到大数据平台的环境下来讨论权限管理问题，相比多数以功能操作为导向的业务系统，通常又会更加复杂一些。因为大数据开发环境的特点，除了用户个人的操作权限管理，你还需要考虑：
所有这些因素都会大数据平台环境下的权限管控工作变得愈发的困难和复杂。
权限管理相关工作可以分为两部分内容，一是管理用户身份，也就是用户身份认证（Authentication），二是用户身份和权限的映射关系管理，也就是授权（Authorization）
前者，用户身份认证这一环节，在Hadoop生态系中常见的开源解决方案是 Kerberos+LDAP，而后者授权环节，常见的解决方案有Ranger，Sentry等，此外还有像knox这种走Gateway代理服务的方案。
下面简单介绍一下这些开源项目，目的不是为了讲解这些方案的实现原理，而是从整体架构流程的角度来看看他们的目标问题和解决思想，以及适用场景等，这样当你在选择或者开发适合自己平台的权限管理方案时，也可以做到知其然，知其所以然。
至于Hadoop生态系的各个组件比如HDFS/Hive/Hbase自身的权限管理模型，针对的是单一的具体组件，也是权限管控体系中的重要组成部分，但限于篇幅原因，本文就不加以讨论了
Kerberos是Hadoop生态系中应用最广的集中式统一用户认证管理框架。
其工作流程，简单的来说，就是提供一个集中式的身份验证服务器，各种后台服务并不直接认证用户的身份，而是通过kerberos这个第三方服务来认证。用户的身份和秘码信息在Kerberos服务框架中统一管理。这样各种后台服务就不需要自己管理这些信息并进行认证了，用户也不需要在多个系统上登记自己的身份和密码信息。
原理流程稍微多介绍一点（不想了解细节的可以跳过）
用户的身份首先通过密码向Kerberos服务器进行验证，验证后的有效性会在用户本地保留一段时间，这样不要用户每次连接某个后台服务时都需要输入密码。
然后，用户向Kerberos申请具体服务的服务秘钥，Kerberos会把连接服务所需信息和用户自身的信息加密返回给用户，而这里面用户自身信息进一步是用对应的后台服务的秘钥进行加密的，由于这个后台服务的秘钥用户并不知晓，所以用户也就不能伪装或篡改这个信息。
然后，用户将这部分信息转发给具体的后台服务器，后台服务器接收到这个信息后，用自己的秘钥解密得到经过Kerberos服务认证过的用户信息，再和发送给他这个信息的用户进行比较，如果一致，就可以认为用户的身份是真实的，可以为其服务。
核心思想
Kerberos最核心的思想是基于秘钥的共识，有且只有中心服务器知道所有的用户和服务的秘钥信息，如果你信任中心服务器，那么你就可以信任中心服务器给出的认证结果。
此外很重要的一点，从流程上来说，Kerberos不光验证的用户真实性，实际上也验证了后台服务的真实性， 所以他的身份认证是双向认证，后台服务同样是通过用户，密码的形式登记到系统中的，避免恶意伪装的钓鱼服务骗取用户信息的可能性。
应用Kerberos的难点在哪
Kerberos从原理上来说很健全，但是实现和实施起来是很繁琐的
为什么这么说呢，首先所有的后台服务必须针对性的接入Kerberos的框架，其次所有的客户端也必须进行适配，如果具体的后台服务提供对应的客户端接入封装SDK自然OK，如果没有，客户端还需要自己改造以适配Kerberos的认证流程。
其次，用户身份的认证要真正落地，就需要实现业务全链路的完整认证和传递。如果是客户端直连单个服务，问题并不大，但是在大数据平台服务分层代理，集群多节点部署的场景下，需要做用户身份认证的链路串联就没那么简单了。
举个例子，如果用户通过开发平台提交一个Hive脚本任务，该任务首先被开发平台提交给调度系统，再由调度系统提交给Hive Server，Hive Server再提交到hadoop集群上执行。那么用户信息就可能要通过开发平台／调度系统Master节点／调度系统Worker节点／Hive Server／Hadoop 这几个环节进行传递，每个上游组件都需要向下游组件进行用户身份认证工作
就算到了具体的后台服务内部。比如在Hadoop集群上运行的一个MR任务，这个认证关系链还需要继续传递下去。首先客户端向Yarn的RM节点提交任务，客户端需要和RM节点双向验证身份，然后RM将任务分配给NM节点启动运行，RM就需要把用户身份信息传给NM（因为NM节点上启动的任务会需要以用户的身份去读取HDFS数据）在NM节点上的任务以用户的身份连接HDFS NameNode获取元数据以后，下一步还需要从HDFS Datanode节点读取数据，也就再次需要验证用户身份信息。
上述的每个环节如果要支持基于Kerberos的身份验证，要么要正确处理秘钥的传递，要么要实现用户的代理机制。而这两者，实施起来难度都不小，也会带来一些业务流程方面的约束。
雪上加霜的是，这个过程中，还要考虑身份验证的超时问题，秘钥信息的保管和保密问题等等，比如MR任务跑到一半秘钥或Token过期了该怎么办，总不能中断任务吧？ 所以一套完整的链路实现起来绝非易事，这也是很多开源系统迟迟没有能够支持Kerberos的原因之一，而自己要在上层业务链路上完整的传递用户身份信息，也会遇到同样的问题。
最后是性能问题，集中式管理在某种程度上意味着单点，如果每次RPC请求都要完整的走完Kerberos用户认证的流程，响应延迟，并发和吞吐能力都会是个比较大的问题，所以比如Hadoop的实现，内部采用了各种Token和cache机制来减少对Kerberos服务的请求和依赖，并不是每一个环节步骤都通过Kerberos进行验证。
小结
总体来说，Kerberos是当前最有效最完善的统一身份认证框架，但是如果真的要全面实施，代价也很高，而从安全的角度来考虑，如果真的要防止恶意破坏的行为，在整个生产环境流程中，能被突破的环节其实也很多，光上Kerberos并不意味着就解决了问题，所以各大互联网公司用还是不用Kerberos，大家并没有一致的做法，即使All in Kerberos的公司，我敢说，除非完全不做服务化的工作，否则，整体链路方面也一定存在很多并不那么Kerberos的环节 ；）
最后，用户身份认证只是权限管理环节中很小的一部分，虽然技术难度大，但是从实际影响来看，合理的权限模型和规范的管理流程，通常才是数据安全的关键所在。所以，上不上Kerberos需要结合你的实际场景和安全需求加以考量。
Sentry和Ranger的目标都是统一的授权管理框架／平台，不光目标，这两个项目在思想和架构方面也大同小异，那么为什么会有两套如此类似的系统？当然是因为Cloudera和Hortonworks两家互相不鸟，必须各搞一套呗，目前看起来，Sentry借CDH用户基数大的东风，普通用户比较容易接受，但Ranger在功能完整性方面似乎略微占点上风。
相比用户身份认证，授权这件事情和具体服务的业务逻辑关联性就大多了，如果是纯SQL交互的系统，通过解析脚本等方式，从外部去管理授权行为有时是可行的，其它情况，通常都要侵入到具体服务的内部逻辑中才有可能实现权限的控制逻辑。
所以Sentry和Ranger都是通过Hook具体后台服务的流程框架，深度侵入代码，添加授权验证逻辑的方式来实现权限管控的，只不过具体的权限管理相关数据的存储，查询，管理工作实际是对接到外部独立的系统中承接实现的，进而实现各种存储计算集群权限的统一管理。
要Hook具体后台服务的流程框架，最理想的是原系统本身就提供插件式的权限管理方案可供扩展，否则就需要对原系统进行针对性的改造，另外各个系统自身既有的权限模型也未必能满足或匹配Sentry和Ranger所定义的统一权限管理模型，是否能改造本身就是个问题。
加上权限验证流程通过查询外部服务实现，因此在权限的同步，对原系统的性能影响等方面常常也需要小心处理或者针对性的优化。因此，统一的授权管理平台这一目标也是一个浩大的工程。所以至今无论Sentry还是Ranger都未能全面覆盖Hadoop生态系中常见的计算存储框架。
小结
总体来说，授权这件事，Hadoop生态系中的各个组件往往会有自己独立的解决方案，但是各自方案之间的连通性并不好。而统一的授权管理框架／平台的目标就是解决这个问题，但它们当前也不算很成熟，特别是在开放性和定制性上，往往也有一定局限性。
当然，要用一个框架彻底打通所有组件的权限管理工作，除了插件化，其它其实也没有特别好的方式，而插件化自然需要框架和具体组件的双向合作努力。只能说就当前发展阶段而言，这一整套方案尚未足够成熟，没到完美的程度，也没有事实统一的标准。所以无论是Sentry还是Ranger，当前的实现如果刚好适合你的需求自然最好，如果不适合，那还需要自己再想办法，且看他们将来的发展吧。
最后来说一下Knox项目，它的思想是通过对Hadoop生态系的组件提供GateWay的形式来加强安全管控，你可以近似的认为他就是一个Rest／HTTP的服务代理/防火墙。
所有用户对集群的Rest／HTTP请求都通过Knox代理转发，既然是代理，那么就可以在转发的过程中做一些身份认证，权限验证管理的工作，因为只针对Rest／HTTP服务，所以他并不是一个完整的权限管理框架
使用Gateway的模式有很大的局限性，比如单点，性能，流程等等，不过对于Rest／HTTP的场景倒也算是匹配。它的优势是通过收拢Hadoop相关服务的入口，可以隐藏Hadoop集群的拓扑逻辑，另外，对于自身不支持权限认证管理的服务，通过Gateway也能自行叠加一层权限管控。
如果去阅读各种开源组件的权限架构相关文档，谈到权限模型时，你往往会看到各种各样的名词称谓，比如RBAC，ACL，POSIX， SQL Standard 等等。
严格来说，这些概念的内容并不是对等的，或者说他们描述的问题有时候并不是同一个范畴的内容，不适合直接拿来对比。
但是，实际环境中，各个系统在为他们的权限模型或者思想概念起名的时候，往往也并不真的完全和这些名词的所谓学术或标准上的定义相匹配，所以我在这里讨论这些概念的时候，也不打算追求绝对的精确，只是借这些名词，泛泛的谈一下其背后的思想，目标以及在平台建设过程中值得我们关注的点。
首先来看RBAC模型，RBAC从标准规范的角度来看，绝对是一个复杂的标准，但是实际情况下，各种开源系统在讨论RBAC的时候，通常重点指的就是权限和用户之间需要通过角色的概念进行一次二次映射，目的是为了对同类权限或同类用户进行归类，减少需要维护的映射关系的数量。至于RBAC理论层面上各种层级的约束，条件，规范等等，其实谈得很少。
而在其它模型中，也或多或少有组/角色的概念，只是比如：组的涵盖范围，是否允许存在多重归属，能否交叉，能否嵌套，是否允许用户和权限直接挂钩等具体规则上有所区别。不过基本上，如果你要宣称自己是一个RBAC模型的话，那么基本上还是要重点强调角色模型和映射关系的建设。而在其它模型中，组/角色的概念相对来说可能并没有那么突出或者重要。
然后谈POSIX的权限模型，谈这个，当然是因为HDFS的文件权限模型，很长一段时间以来，只支持POSIX标准文件的权限管理模型，即一个文件对应一个OWNER和一个GROUP，对OWNER和GROUP以及其它用户配置RWAC这样的读写通过管理等权限。
POSIX模型很直白，很容易理解，实现也简单，但POSIX模型最大的问题是文件的共享很难处理。因为要将权限赋予一拨人，只能通过单一固定的组的概念，你无法针对不同的人群和不同的文件进行分组授权，所以很难做到精细化的授权管理。
为了解决权限多映射精细管理问题，HDFS又引入了ACL模型，Access Control List，故名思意，就是针对访问对象，有一个授权列表。那么对不同对象给不同用户赋予不同的权限也就不成问题了。当然，HDFS的ACL模型也不是范本，事实上各种系统中所谓的ACL模型，具体设计都不尽相同，唯一可能共通的地方就是：对访问对象赋予一个授权列表这个概念，而不是像POSIX这样固定分类的授权模式。
ACL模型理论上看起来很理想，但在HDFS集群这个具体场景中，麻烦的地方在于如果集群规模比较大，授权列表的数量可能是海量的，性能，空间和效率上都可能成为问题，而事实上，ACL对象精细化的管理也并不那么容易。当然这些也并不能算是ACL模型自身的问题，更多的是具体的实现和上层业务规划方面的问题。
最后所谓的SQL标准的权限模型，从模型的角度来说和ACL模型并没有什么本质的区别，只不过是在类SQL语法的系统中，模仿了Mysql等传统数据库中标准的授权语法来与用户进行交互。具体的实现例子，比如Hive Server2中支持的SQL标准授权模型
了解了相关的解决方案和思路，在我们自己的大数据平台的权限管理方案的实施过程中，不管是全面使用开源方案，还是局部混搭，又或者是完全自行构建，我们都可以从身份认证与授权管理，集中式管控与Gateway边界管理等角度来拆解，思考和分析问题，寻找适合自身业务场景的整合方案。
我司的整体思路，是尽可能通过构建产品化的大数据开发平台，将各种集群以服务的形式对外提供，换句话说，类似于上述Gateway的思想（但不是knox这种http代理），尽可能让用户通过开发平台来提交任务，管理数据，而不是直接通过API连接集群。
当所有的用户都通过开发平台来和集群进行交互时，开发平台就具备了统一的用户身份认证和权限管理的基础前提条件。当然实际情况并没有那么理想，不管是出于技术原因，实现代价原因，程序效率性能原因，还是业务流程原因，总会有些业务流程和任务无法通过开发平台来统一管控。这时候就需要结合其它方案来弥补了。
以HDFS集群的文件读写的权限认证为例，大部分涉及到HDFS文件读写的任务，比如Hive/Presto/SparkSQL等相关任务，如果我们管控了这些任务作业的提交入口，相关的集群由我们提供，那么多数权限管控工作我们都是能够在开发平台层面完成管控的。
但还有很大一部分需要读写HDFS数据的业务，自身并不运行在大数据开发平台提供的服务上。比如内网的简历系统需要存取简历，商家的证照文件需要备份，广告的算法模型，特征数据需要在各个子系统间传输等等，这些业务的程序可能是自行开发的，调用入口也并不在大数据开发平台上，所以开发平台也就很难对其进行用户身份认证。
而Hadoop的客户端，除了Kerberos方案，剩下的Simple认证方案，实际上并不真正识别用户的身份（比如你只需要通过环境变量设置宣称自己是用户A，Hadoop就允许你操作用户A的数据）。那么不上Kerberos就没法处理了么？
也不完全如此，如果用户的需求是简单的文件存储工作，那么我们可以考虑通过对象存储服务的方式来支持，用户身份的认证在对象存储服务中实现，由对象存储服务代理用户在HDFS集群上进行文件读写操作。但如果用户就是需要灵活的Posix模式的文件读写服务，那显然，就要在HDFS自身服务方面动脑筋了。是封装客户端还是改造服务端，取决于具体的安全需求程度和实现代价
基于服务端的改造通常对用户的透明性好一些，安全性也更强一些（因为别人可以不用你封装好的客户端。当然，也可以在服务端加上客户端的ID识别之类的工作来加强防范）。比如，如果我们相信业务方自己不会滥用账号，我们的目的只是防止各个业务方之间无意的互相干扰和误操作，那么在服务端进行用户身份和IP来源的绑定鉴定（即特定用户只能由特定IP的机器使用），结合Hadoop自身的Posix文件权限管理模式，基本就能达到目的。当然，服务端的管控还可以想到更多的其它方案，这就需要结合你的业务环境，运维成本和技术代价等进行判断选择了。
首先，Ranger等方案，主要依托大数据组件自身的方案，Hook进执行流程中，所以管控得比较彻底，而开发平台边界权限管控，前提是需要收拢使用入口，所以论绝对安全性，如果入口收不住，那么不如前者来得彻底。不过通常来说，为用户提供统一的服务入口，不光是安全的需要，也是开发平台提高自身服务化程度和易用性的必要条件。
其次，底层权限统一管控平台，因为依托的是大数据组件自身的方案，并不收拢用户交互入口，所以身份认证环节还是需要依托类似Kerberos这样的系统来完成。而开发平台服务方式，收拢了入口，就可以用比较简单方式自行完成身份认证，如前所述，相比涉及到三方交互的分布式身份认证机制，通常实现代价会更低一些。
再次，大数据组件自身的权限方案，权限验证环节通常发生在任务实际执行的过程中，所以流程上基本都是在没有权限的时候抛出一个异常或返回错误，因此不太可能根据业务场景做更加灵活的处理。
而开发平台服务方式，权限的验证如果可以做到在执行前阶段（比如通过语法分析获得）进行，那么流程上就可以灵活很多，可以结合业务相关信息提供更丰富的调控手段。
例如，业务开发过程中，在代码编辑或保存时就可以进行相关权限验证和提示，避免在半夜任务实际执行时才发现问题。也可以定期批量审计脚本任务，或者根据业务重要程度对缺乏权限的情况进行区别对待：提示，警告，阻断等等。简单的说，就是你想怎么做就怎么做。而Ranger等基于底层组件进行Hook的权限架构方案，一来没有相关业务信息无法做出类似决策，二来考虑通用性，很多平台环境相关业务逻辑不可能也不适合绑定进来。
当然，这两种方案并不是互斥的，如何定义你的产品，如何拆分各种需求，对你选择权限管控方案也有很大的影响。更常见的情况是，你会需要一个混合体，取长补短，弥补各自的不足之处。
小结
总体来说，在开发平台上进行边界权限管控，并不是因为这种方式更安全，而是因为它更灵活，与业务和流程的兼容适配性更好，对底层组件自身权限管控能力的依赖性也更小。甚至还可以根据业务逻辑针对性定制权限管控策略，但是因为自身通常并不深度Hook具体组件内部执行逻辑，所以部分场景可能无法有效的进行管控（比如二进制代码任务无法从外部解析其读写逻辑），就需要和底层组件权限管控方案结合起来实施。
以上就是本篇文章【深入探讨大数据权限管理方案-从哲学到技术】的全部内容了，欢迎阅览 ！ 文章地址：http://sicmodule.kub2b.com/quote/205.html 资讯 企业新闻 行情 企业黄页 同类资讯 首页 网站地图 返回首页 企库往资讯移动站 http://changmeillh.kub2b.com/ , 查看更多