云上基于Kerberos的大数据安全实践

1. 摘要

本文主要介绍E-MapReduce基于Kerberos的大数据安全实践，包括边界安全/认证/授权/审计/加密，其中重点介绍了身份认证，采用了阿里云和Intel合作开发的基于Kerberos插件式可扩展认证的HAS框架，方便用户与已经存在的用户认证系统相结合，使得安全管理人员不需要在用户账号系统和Kerberos的数据库之间迁移和同步，如将阿里云的RAM/LDAP等外部的身份认证系统接入Kerberos。

2. 什么是身份认证

身份认证(Authentication)是用于识别用户身份的过程，只有通过身份认证的用户才有可能访问某些服务。

它涉及三个主体，即用户、认证、服务，他们的关系如下:

2.1 生活中的身份认证

平时生活中有很多身份认证的场景:

• 储户首先在银行开户提供了相关的身份信息(身份证/手机号/密码等)，当去银行取钱时需要提供与开户时相同的身份信息[如身份证/银行卡/密码]， 银行对这些信息进行认证通过后才能提供取钱服务等;
• 乘客需要提供身份证去购买机票/火车票等,身份证认证通过后才能购票;
• 游乐场会对游客提供的票进行身份认证，只有游乐场发售的票才能通过认证，冒充的假票是无法进入游乐园;

上述几种身份认证的场景:

• 用户主体是储户/乘客/游客
• 认证主体有银行/航空/铁路公司/游乐场，他们对用户提供的身份信息进行认证，认证可以分为二方认证，即服务的提供者(如银行等)，还有
  第三方认证(如身份证认证即为第三方认证。银行/航空公司等需要调用政府提供的认证接口对身份证进行认证)
• 服务主体是取钱服务/购票服务/游玩服务等

身份认证在生活中非常普遍，它是很多系统/工程能够正常安全的运转的最基本保障。

2.2 大数据集群中的身份认证

身份认证在生活中无处不在，那大数据领域是否也需要身份认证呢？答案是肯定的。

大数据集群最基本的就是数据，以及用于计算的资源，是一个公司的宝贵财富，显然需要将它们好好管理起来，开放给相关用户使用，防止被窃取/被破坏等，这就涉及到大数据安全。

2.2.1 企业级大数据集群安全

一般在用户在访问大数据集群会经过如下几个维度的安全防护:

• 边界安全

如设置防火墙/VPC网络隔离/安全组控制端口等，特别是公有云环境上的集群，一定要注意相关服务的端口是否暴露在公网环境中;

• 认证

集群中的组件服务开启身份认证功能，只有用户提供了合法的身份信息才有可能访问服务，它是后续授权的基础，没有身份认证的授权是有漏洞容易被冒充的。

认证有很多形式，如服务组件自身提供了简单的用户名/密码认证方式，比较通用的是使用Kerberos协议，集群上启动的多个服务组件可以通过使用同一个第三方的Kerberos认证服务，对用户进行身份认证;

• 授权

通过身份认证的用户并不能访问服务的所有资源，需要通过授权机制对用户访问服务中实际的资源进行控制;

• 审计

用户对服务资源的访问，需要利用审计日志进行监控/跟踪，便于问题/风险的排查;

• 加密

涉及数据传输加密/数据存储加密，防止数据被窃取/窃取后被破解等。

2.2.2 大数据集群中的身份认证

上述的几种维度，身份认证处于第二道防护，而且内层的权限控制(Authorization)是依赖于身份认证，没有身份认证的权限控制是很容易被冒充的。
大数据集群中的身份认证作用如下:

• 服务身份认证
  大数据有很多组件服务，如HDFDS/YARN/HBase，这些服务会在集群的节点上启动相关服务进程，如NameNode/DataNode等。

如果某人新加一台机器并且配置启动DataNode加入了HDFS集群，则这台DataNode就会接受到数据，从而导致这台DataNode数据被别人非法获取了。

那如果HDFS服务以开启了身份认证的方式(如Kerberos)启动,则除非新增加的机器配置了有关身份认证的信息启动，否则无法加入集群。

• 用户身份认证

有了权限控制，如设置某人不能访问HDFS中某些数据/不能提交作业到yarn，这样不就保护相关数据/资源了，还需要身份认证干嘛？

大数据组件中基于user/group等做权限控制，而且user是来自客户端，即只要客户端这边使用某个user去访问服务，那么服务就用该user进行权限校验。
所以客户端这边基本上零成本可以冒充相关权限的用户，如HDFS的超级账号。

有了身份认证之后，就可以防止用户冒充，即只有提供了合法身份信息，通过了身份认证之后的用户，才能访问集群。

3. 什么是Kerberos

Kerberos是一种网络认证协议，它使用对称加密的技术实现网络中的身份认证。

• Kerberos以第三方服务的方式提供身份认证，即独立于相关的服务组件;
• Kerberos协议有很多实现版本，如MIT Kerberos/Azure AD，以及下面介绍的由阿里云和Intel合作开发Intel开发的HAS;
• 多个组件服务可以使用同一个第三方的Kerberos服务，实现SSO(Single Sign On，单点登录)，即只要用户通过Kerberos认证获取到TGT后，可以使用该TGT访问多个组件服务，类似购买到游乐场票后可以使用该票在游乐场里面玩多个项目;
• 很多大数据服务组件都默认集成了Kerberos，均可以开启Kerberos身份启动服务。

3.1 参考文档:

Kerberos
转载CSDN博客，介绍的比较详细

3.2 Kerberos原理

当一个用户需要访问某个被Kerberos保护的服务时，Kerberos认证过程可以分为两个阶段(其中第一个阶段是第二个阶段的基础):

3.2.1 Kerberos服务端程序(Authentication Server,AS)对用户的身份认证

这个过程类似于去游乐场首先需拿身份证购票，用户提供了身份证，游乐场对身份证信息进行认证，然后提供票据给游客，游客可以凭票进入游乐园。

同理，当用户去访问某个以Kerberos方式启动的组件服务时，首先需要拿着自己的身份信息去Kerberos服务端进行认证，获取到TGT(票据)。

上图中的身份信息，如提前管理员在Kerberos服务端注册的用户名(principal)/密码，管理员将principle/密码提供给某个用户使用，该用户后续就使用用户名/密码来作为身份信息，去Kerberos的AS进行身份认证，然后获取TGT。

备注:用户端实际传输到AS的并不会直接传输密码，而是使用客户端对称加密信息，Kerberos服务端对称解密的方式来进行身份认证。

3.2.2 服务对用户的身份认证

这个过程类似于游客进入游乐园后，游玩某个项目时需拿这个购买的票据给工作人员进行认证，有效的票(如是否过期,是否是假票等)才能玩相关项目。

上图中用户拿着第一阶段获取到的TGT(票据)以及要访问服务的名称等信息，去请求Kerberos服务端的Ticket-Granting Service，TGS会返回给用户一个SGT(Service Granting Tickect，SGT使用组件服务以Kerberos方式启动时在Kerberos服务端注册的身份信息/密钥进行加密，所以SGT只有组件服务才能使用对称密钥进行解密)，然后用户拿着SGT以及用户的Authenticator(封装了用户名等信息)去请求组件服务，组件服务会对称解密SGT信息并完成对用户的Authenticator进行认证，如果通过认证则用户成功访问组件服务的相关资源。

备注: 第一阶段获取的TGT可以缓存在客户端(有失效时间)，只要TGT未失效，用户都可以直接使用该TGT直接走第二阶段访问服务，而且可以访问多个组件服务(SSO)。

3.3 大数据组件+Kerberos部署

大数据组件(如HDFS/YARN/HBase/Hive/Kafka/Spark等等)基本上都默认支持Kerberos身份认证。

它们在启动之前需要在Kerberos的服务端注册相关的principal并导出keytab文件，然后在服务的配置文件中开启身份认证并配置principal/keytab路径等(如在core-site.xml/yarn-site.xml等文件中)，最后启动的服务即支持Kerberos的身份认证，后续用户需要通过Kerberos认证才能正常访问服务。

一般大数据集群服务组件的Kerberos的部署方式如下：

如上图所示，

• 集群以Kerberos的方式启动了HDFS/YARN等服务
• 同一个集群内启动的多个组件服务共用一个Kerberos服务
• 示例中以Gateway的方式使用组件服务的客户端工具访问集群服务，用户也可以写java代码，在代码中设置Kerberos相关的配置，访问集群服务

备注:
如果用户有两个Kerberos服务，每个Kerberos服务上都启动了各自的组件服务，需要进行相关的跨域的配置，实现跨域的服务互访。

4. 什么是HAS

前面介绍了Kerberos的认证，HAS(Hadoop Authentication Service)是Kerberos协议的一种实现，由阿里云和Intel合作开发，它的底层是基于Apache Kerbygithub，它相对于MIT Kerberos的实现增加了可插拔认证的方式，即HAS框架可以以插件的方式接入多种外部的现成的身份认证系统，如阿里云的RAM、LDAP等。

4.1 HAS插件式认证特点

• 不需要提前在Kerberos服务端录入用户的身份信息
• 一个HAS服务端可以支持多种方式的认证，服务端会根据客户端的参数来选择某种认证插件进行认证
• 可以实现身份信息的统一管理，多个系统只需要维护一份身份信息即可

如RAM的身份信息可以用于访问阿里云的产品(如ECS/OSS等)，如果将RAM以插件的方式接入HAS，则RAM的身份信息也可以用于访问HDFS/YARN/HBase等；

如Hue/Knox等系统也可以与Kerberos共享一套LDAP来管理用户信息。

• HAS也支持类似MIT Kerberos的使用方式，兼容MIT Kerberos客户端工具，如kinit/klist等
• HAS支持跨域

4.2 HAS框架

HAS的插件式认证主要体现在3.2.1节的Kerberos认证的第一个阶段。

它的实现框架如下:

从上述可以看出，如果要将某个现成的外部身份认证系统接入HAS，则只需要实现两个插件，即客户端插件和服务端插件。

• 客户端插件获取需要进行认证的身份信息，身份信息来自外部身份认证系统
• 服务端插件对客户端请求的身份信息进行认证，认证过程是通过调用外部身份认证系统进行认证，HAS获取认证结果，返回TGT

备注:

• 当客户端获取到TGT后，后续流程完全按照3.2.2节的组件服务对用户的认证流程，未做任何改造。
• HAS除了图中插件的方式，还默认支持类似MIT Kerberos的认证方式，即在Kerberos服务端提前录入用户principal/密码等信息，也支持MIT Kerberos的客户端工具，如kinit/klist等

4.3 参考文档

HAS-插件式Kerberos认证框架

5. E-MapReduce安全实践

E-MapReduce产品在2.2.1节提到的企业级大数据集群安全的几个维度都有相应的功能支持。

• 边界安全

创建集群时候可选择vpc网络
集群有安全组控制开放端口
用户也可根据需求在集群节点上面设置iptables

• 认证

组件服务配置Kerberos非常复杂，而且又很多组件需要配置。

E-MapReduce产品中只需要在创建集群页面打开高安全模式，创建出来的集群中的组件都会配置好以Kerberos的方式启动，打开身份认证，非常的方便。

E-MapReduce中的Kerberos使用的上面介绍的HAS框架，E-MapReduce实现了RAM/LDAP/EMR三种插件认证方式，即可以使用RAM的AccessKey、LDAP的用户信息、以及从E-MapReduce的控制台执行计划提交作业访问启动了Kerberos的安全集群。

a) 兼容MIT Kerberos使用文档

b) RAM+HAS使用文档

c) LDAP+HAS使用文档

d) 执行计划+HAS使用文档

• 授权

E-MapReduce集群的开源组件可按照组件的官方文档进行相关的权限配置。

可以在E-MapReduce控制台的集群配置管理页面方便的进行配置并重启各项服务，无需登录集群操作。

权限配置详见E-MapReduce 授权文档

a) HDFS授权
b) YARN授权
c) Hive授权
d) HBase授权

• 审计

E-MapReduce集群默认开启了HDFS/HBase的audict log， 其它相关组件后续会陆续开启。

• 加密

用户可选择启动使用HDFS的数据加密KMS服务。

有兴趣或者有需求的用户可以关注一下E-MapReduce的安全相关的功能，有问题及时联系和反馈。