Hadoop生态圈-构建企业级平台安全方案

　　　　　　　　　　　　　　Hadoop生态圈-构建企业级平台安全方案

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　作者：尹正杰

版权声明：原创作品，谢绝转载！否则将追究法律责任。

　　能看到这篇文章的小伙伴，估计你对大数据集群的部署对于你来说应该是手到擒来了吧。我之前分享过关于“离线方式部署Cloudera Manager5.15.1”和“离线方式部署Ambari2.6.0.0”的笔记。不管你的集群是使用CDH还是HDP亦或是使用的Apache Hadoop部署的，但是这样一套出事状态的服务只能被成为学习或者实验环境，他们还不足以担当起企业级大数据平台的重任。为什么这么说？因为这套初始状态的服务在安全防护方面几乎是空白的。

　　当平台用户使用量少的时候我们可能不会在一集群安全功能的缺失，因为用户少，团队规模小，相对容易把控，开发人员直接也彼此了解。这时候只需要做好团队内部或是企业通过一些列行政管理手段就能管理好集群的安全问题。但是别忘了我们的平台定位可是作为一个单一的大数据来支持企业内部所有应用的。正所谓人上一百，形形色色。当平台用户达到一定数量之后其素质难免会参差不齐，大数据平台面对的也不再是一个小团队了。这时候考团队自觉或是单纯地通过规章制度都很难再起到有效的作用。作为一个企业级平台，安全问题不容小觑。

一.浅谈企业级大数据平台面临的安全隐患

　　接下来会描述企业级大数据平台面临的一些安全隐患，大数据平台只有将这些安全隐患解决，才能真正拿到生产环境中去使用。安全性是我们平台必备的能力。

1>.缺乏统一的访问控制机制

　　大数据平台的底层技术栈由Hadoop生态中众多子系统组成，这些系统都会提供一些基于HTTP协议的原生系统服务，这些服务可能是Web UI控制台或是RESTful服务接口。例如HDFS会提供Hbase Master UI，我们避免不了会和这些原生系统服务打交道。默认情况下，这些系统服务是没有设置访问控制的，这意味着任何人只要知道了服务的URL地址，就能任意使用控制台或调用RESful即可，这是十分严重的安全隐患。

　　通常我们会有两种方法解决方案应对这个问题：

　　　　第一：借助局域网的防火墙屏蔽这些系统服务的访问端口，以此来阻断对这些系统的访问；

　　　　第二：开启这些系统自身的访问认证功能，例如HDFS和YARN都可以开启认证模块；

　　综上所述，在访问控制机制这块的确有对应的解决方案，但是这两种解决方案都不完美。防火墙的控制粒度粗犷，没有办法做到用户级别细粒度的访问控制。而系统自带的认证模块也存在问题，多个子系统之间的认证和用户相互独立，各自为政。

2>.缺乏统一的资源授权

　　单一集群架构的大数据平台在我们提供了资源整合的同时，也带来了一些隐患。因为现在平台中的数据和服务等一切可用资源都集中在一起了，从物理上并不在完全隔绝，平台用户可以不受限制的访问任意的数据和服务，例如可以查询数据仓库（Hive）中所有的数据或是删除文件系统（HDFS）上的任意目录。这种隐患十分可怕！用户应该只能访问到自己的数据，不同用户和不同应用之间的数据存储需要隔离，用户对数据的访问和操作需要通过授权之后才能进行。

　　为了避免这些隐患，我们需要开启Hadoop系统的授权模块。HDFS，Hive和HBase等系统自身都实现了基于用户的授权策略，但他们也存在着同样的问题，多个系统之间各自为政，却饭统一的授权界面，管理起来十分方便。

3>.缺乏Hadoop服务安全保障

　　Hadoop相关的系统都是由一系列分布式服务组成的，它们在运行的过程中会进行大量的通讯。默认情况下这些交互的信息是没有加密的，系统之间也不会验证这些信息来源是否可靠。这就为服务安全埋下了又一个隐患，因为这些交互信息可能被假冒或者篡改。

二.初级安全方案

　　不说不知道，一说吓一跳！我们刚刚搭建好的Hadoop集群有这么多的安全隐患啊，不过大家也不要惊慌，这些问题并不是没有办法解决。

1>.访问控制

　　大数据平台需要解决第一个问题，是保护平台中Hadoop集群原生WebUI控制台和RESTful服务。我们通过引入一种使用HTTPS协议的代理网关系统来解决这个问题，具体思路如下：

　　　　第一：通过防火墙将集群内Hadoop系统相关的端口全部屏蔽，只保留代理网关的访问端口；

　　　　第二：用户对大数据平台内所有Hadoop系统原生WebUI控制台和RESTful服务的访问都经过网关进行代理访问，访问协议从HTTP升级到HTTPS；

　　　　第三：当用户通过代理网关访问的时候要求在网关处进行用户认证，只有认证通过的用户才能继续访问；

　　这样，对大数据平台内部的Hadoop系统基于Http协议的原生Web UI控制台和RESTful服务就实现来基于用户粒度的访问控制。这方案重点在于统一的代理网关系统，详情请参考：Knox网关的应用案例。

2>.数据授权与管理

　　我们需要解决的第二个问题呀，是保护大数据平台中的资源安全，这些资源包括数据资源（例如HDFS，Hive和HBase系统中的数据）和系统资源（例如YARN的任务队列）。HDFS，Hive和Hbase等系统虽然拥有各自的的权限管理功能，但他们太过分散且配置方式原始，不利于管理。所以我们需要引入一个授权系统，它需要集成所有子系统的权限管理功能并提供一个授权的界面，详情请参考：Ranger数据安全管理框架。

三.Hadoop服务安全方案

　　现在我们将视线再次指向Hadoop服务，因为到目前为止，大数据平台到Hadoop相关服务还未收到任何保护，仍然存在被内部伪装攻击的隐患。这一隐患十分严重，它直接威胁到平台底层最核心到系统。

　　Hadoop服务到安全问题由来已久，因为他在设计之初并没考虑过安全部分。这导致用户在提交任务到时候可以随意伪造身份，或是恶意程序伪装成服务进程对集群造成破坏。随着时间对推移，行业内对安全意识越来越高，Hadoop生态顺应潮流也逐渐补充完善来自己对安全模型。

　　我们对设计思路是引入Kerberos认证机制。通过Kerberos协议，就能够使用Kerberos用户代替服务器本地对Linux用户，从而让大数据平台对Hadoop相关服务全部使用Kerberos用户通过它对认证中心进行认证，以大幅提升平台对安全性。详情请参考我的笔记：开启Ambari的Kerberos安全选项。

四. 单点登录与用户管理

　　如果你已经将第二步和第三步的工作都做完了的话，大数据平台可以说已经小有所成了 ，在通过一系列的安装配置之后，已经成功搭建起了一套Hadoop集群，它包括HDFS，Hive，Spark，Hbase和YARN等主流技术组件，并且各个组件也已经相互集成，与此同时，通过使用Knox网关和LADP服务，实现了对基于HTTP协议的RESTful服务和Web UI管理控制台的访问控制功能；通过使用Ranger服务，实现了对数据资源的授权以及多种操作的审计功能；通过使用Ranger服务，实现了使用Kerberos协议保证和Hadoop服务的安全。目前大数据平台相关服务的安全性相比初始状态也已经明显的提升，但是我们还不能停住急哦啊不，因为平台还是不够完善。之前的安全方案可谓说是用头疼医头脚疼医脚的方式在解决问题，他们虽然都能解决相应单个问题的症状，但是如果吧这些方案都放在一起，就发现又会产生新的问题，例如：

1>.多个系统需要登录

　　首先，通过Knox代理网关访问相关服务页面的时候是需要登录认证的，其次是在使用Ranger进行数据授权的时候也需要通过它的Web UI管理控制台登录，再加上Ambari的Web UI管理控制台，现在大数据平台至少有三套独立的系统需要用户登录，用户会面对多次登录的困扰，这无疑会严重降低平台的易用性和可用性。　

2>.存在多套用户

　　Knox代理网关使用的是IPA附带的LDAP服务中存储的用户，而Ranger使用的则是从Hadoop集群中同步过来的扩展用户，这些用户存储在Ranger自己的关系型数据库中。还有来自Ambari的内部用户，这些用户也存储在Ambari自己的关系型数据库中。除此之外还有Hadoop集群服务的用户，这些用户都是各自服务器的本地用户，这些用户都是各自服务器的Linux本地用户。大数据平台至少拥有四套独立的用户存储，这无疑会对平台的运维和使用造成不小的难题。

　　不解决上述问题，平台任然是可用的，因为他们并不会影响到平台提供的基本能力和安全性。这些问题不致命，但却会严重影响大数据平台的易用性和可用性，降低用户体验并增加维护成本。在这些难题没有解决之前，大数据平台只能称为可用，而不能称之为好用。

3>.集成单点登录

　　首先，我们来分析一下多套系统登录的问题，目前大数据平台存在三大系统，他们分别是Knox，Ranger和Ambari。这其中，Knox代理着各种Hadoop组件原生Web UI和RESTful服务。Ranger提供了权限和分配与管理，而Ambari则管理集群的方方面面。

　　这三大系统都有一个共同的特点，那就是它们使用的都是HTTP协议。可以看出，这是一个典型的设计单点登录的问题。通过集成一个基于HTTP协议的单点登录就可能解决这个问题，此处难点在于如何将这些子系统集成进单点登录系统的体系中去。

　　现在有一个集成的大致思路：

　　　　3.1>.首先需要引入一个单点登录系统，这里选择CAS（详情请参考我的笔记：点登录框架之CAS（Central Authentication Service）部署）。

　　　　3.2>.接着将Knox代理网关与CAS集成，这样访问Knox网关代理的各种Web UI和RESTful服务的时候，所有的服务请求都会被统一的重定向到CAS系统的登录页面进行认证。

　　　　3.3>.然后在去设置Ranger和Ambari的登录策略，让这两个系统委托Knox代理万贯的认证服务进行登录验证。因为在第2步骤中，已经将Knox代理网关与CAS进行了集成，所以Ranger和Ambari以Knox代理为桥梁间接实现了与CAS的集成。当用户访问Ranger或者Ambari当Web管理控制台时，都会重定向到CAS到登录页面进行登录验证。

　　　　3.4>.最后将CAS的认证方式指向IPA附带的LADP服务，这样一来用户可以直接使用Kerberos用户进行登录。这是为什么呢？还记得在介绍IPA中用户管理的特性吗？通过IPA创建一个Kerberos用户的时候，他会自动创建一个Kerberos用户的时候，它会自动在LDAP服务中创建一个完全一样的用户，包括用户名和密码。

　　至此，Knox，Ranger，和Ambari被集成到CAS，成为单点登录系统中的客户端程序。在用户访问这些使用HTTP协议的系统时，请求都会被统一拦截并重定向到CAS系统的登录页面进行单点登录，在任意系统登录之后可以免登录直接进入到其他系统。各系统通过Knox代理网关这样一个中间桥梁服务与CAS单点登录服务集成以实现但带你登录功能。