KDC 多机房 HA 架构演进

KDC 基本概念

KDC 是秘钥分发中心（Key Distribution Center）的简称，是密码系统中重要的组成部分，目的是降低交换秘钥时固有的风险。KDC 实现 Kerberos 帐号的认证和授权。KDC 是独立于 Client 和 Server 端的第三方认证中心，可以在开放网络环境下进行 Client 和 Server 端的相互认证。

图 1 KDC 组织结构图

KDC 主要组成部分：

AS：认证服务，主要是发放 TGT 给 Client 端

TGS：票据授权服务，发放 ST 给 Client 端

DATABASE：数据库，存放 kerberos 账号信息

Kerberos 是一种使用对称加密算法的计算机网络授权协议，用于在非安全网络环境中，对个人通信以安全的方式进行身份认证。同时它也是 MIT 开发的一种 C/S 架构的秘钥管理系统，可以实现客户端和服务端的相互认证。目前被广泛使用的 V5 版本。主要概念如下：

1）TGT：ticket-granting ticket，票据授权票据，由 AS 发放。

2）ST：服务票据，由 TGS 发放。

3）Principal：Kerberos 主体，如服务或帐号。

4）Realm：Kerberos 在管理上的划分，在 KDC 中所负责的一个域数据库。这个数据库存放该网络范围内的所有 Principal 和它们的密钥。

5）SS：服务提供端。

Kerberos 解决的问题

1）避免秘钥在网络中传输；

2）避免用户的密码存储在客户端机器上；

3）实现了客户端和服务端的相互认证；

4）认证信息管理是集中的，驻留在认证服务器上。应用程序服务器不得包含其用户的身份验证信息。这对于获得以下结果是至关重要的：管理员可以通过在一个位置上进行操作来禁用任何用户的帐户，而不必在提供各种服务的多个应用服务器上进行操作。

在 Hadoop1.0.0 后引入了 Kerberos 认证机制，解决了 Hadoop 生态的安全问题：

1）防止了用户伪装成 Datanode，Tasktracker，去接受 JobTracker，Namenode 的任务指派；

2）Kerberos 对可信任的客户端提供认证，确保他们可以执行作业的相关操作。防止用户恶意冒充 Client 提交作业的情况。

认证原理

Client 认证过程

图 2 Client 认证过程示意图

1）Client 将 TGT 和要请求的服务信息发送给 KDC，KDC 中的 TGS 会生成一个 Session Key 用于 Service 和 Client 端的认证。然后 KDC 将这个 Session Key 和用户名、用户地址（IP）等信息生成 Ticket（这些信息用于后续 Service 和 Client 的身份认证）发送给 Client 端，由 Client 转发给 Service。KDC 使用它和 Service 端共享密钥加密刚才的 Ticket，然后发送给 Client。为了使 Client 和 Service 共享之前的 Session Key（KDC 为 Client 和 Service 创建的），KDC 会使用 Client 和 KDC 之间的共享密钥加密 Session Key 和 Ticket 返回给 Client；

2）Client 将收到的 Session Key 解密出来，然后将自己的用户名，用户地址（IP）打包成 Authenticator 用 Session Key 加密和 Ticket 一块发送给 Service。

3）Service 收到 Ticket 后利用它与 KDC 之间的密钥将 Ticket 中的信息解密出来，从而获得 Session Key 和用户名，用户地址（IP）等信息。然后再用 Session Key 将 Authenticator 解密从而获得用户名，用户地址（IP）将其与之前 Ticket 中解密出来的用户名，用户地址（IP）做比较从而验证 Client 的身份。

4）如果 Service 认证成功，将结果会返回给 Client。

2

常用认证方法

1）kinit [email protected]

2）kinit –k –t /path/to/Principal.keytab [email protected]

3

Ticket 生命周期

每当主体获取包括票证授予票证 (TGT) 在内的票证时，都会将票证的生命周期设置为以下生命周期值中的最小值：

• 通过 kinit 的 -l 选项指定的生命周期值，前提是使用 kinit 获取票证。缺省情况下，kinit 使用 krb5.conf 中设置的值。
• kdc.conf 文件中指定的最长生命周期值 (max_life)。
• Kerberos 数据库中为提供票证的服务主体指定的最长生命周期值。如果使用 kinit，则服务主体为 krbtgt/realm。
• Kerberos 数据库中为请求票证的用户主体指定的最长生命周期值。(addpol)

KDC 多机房架构演进过程

初期我们使用 Hadoop 集群，由于当时公司规模较小且单机房，所以考虑 Kerberos 规划的时候，只要能实现单机房 HA 就可以满足业务需求。于是调研采用 Keepalive 通过漂移 VIP 的方式达到高可用。KDC 主 Server 使用 kdb5_util dump 将数据库文件备份至一个目录，然后利用 Rsync 同步该目录到 KDC 备 Server 的 Domain 目录，再使用 kdb5_util load 加载数据库文件到 KDC 中。每次有新增帐号时，Rsync 会增量同步至 KDC 备 Server。Hadoop 所有请求都是通过请求内网域名，解析到 Keepalive 的 VIP 方式访问 KDC 服务（如图 3）。

图 3 KDC 单机房 HA 方案示意图

随着公司的发展，集群规模不断扩大。短短两年国内外就新增了近 10 个机房，各机房之间都是通过专线互相访问。由于 Hadoop 集群是对内部用户使用，不推荐跨机房访问和部署。所以我们在各个机房部署了 HDFS、HBase、Zookeeper 等服务，它们共享一套 Kerberos Principal。但是这样的架构存在问题，一旦 Kerberos 服务器所在机房到其他机房的专线出现故障，Hadoop 相关的服务都会不可用。只能等专线恢复，Hadoop 服务才会可用。如果专线故障事件较长，那就需要紧急在故障机房部署 KDC Server。这在一定程度上增加了运维成本。于是，我们调研采用多机房策略，在每个机房都部署一套 KDC 系统，各个机房的 KDC 数据库使用 Rsync 同步。简单实现了 KDC Server 的多机房 HA（如图 4）。

图 4 KDC 多机房 HA 方案示意图

每个机房上线了一套 KDC Server，使用 Keepalive VIP 的方式进行访问。利用 Rsync 每天同步主机房的 KDC 数据库到各个机房的 KDC Server。并且使用内网 DNS 解析，使得本机房的 Hadoop 服务访问本机房的 KDC 服务。

随着业务的不断增长，每天都有大量的服务访问 KDC，并且每天都有新增 Kerberos Principal 的需求，越来越多的操作需要手动满足。于是，2015 年年初，通过调研我们上线了新版的 KDC 服务（如图 5），解决了之前版本存在的一些问题，并且上线了 Kerberos 的管理系统。新版 KDC 服务引入了 Mysql 主从 HA 方案、LVS LB 方案；海外 AWS 引入了 ELB 方案；Principal 申请规范化、自动化；Principal 和 LDAP 帐号结合；管理系统使用 HTTPS+CAS 方式以及使用 TCP 协议。

图 5 现 KDC 多机房 HA 方案示意图

当前 KDC 多机房系统具有一下特点：

KDCServer 负载均衡

通过调研，我们放弃了 Hadoop Service 直接访问 kerberos vip 的方式，而是选择同机房走同机房 LVS 或 LB（或国外 ELB）进行内网域名解析。当 LVS 或 LB（或国外 ELB）后端一台 kerberos Server 出现故障时，LVS 会将所有的流量切到另外一台 kerberos server，保证同机房内使用 kerberos 服务正常，达到高可用。目前国内外上线的机房近 10 个机房上线。

数据同步

数据同步从两方面来说：

1）KDC 主机房数据库，使用 mysql 双主的方式同步，将生成的记录保存到 MySQL 中。MySQL 采用双主的同步方式，KDC 平台操作生成的新数据会写进 MySQL 数据库，当 Webserver 检测到 MySQL 中有新数据生成，利用 Kadmin 创建对应的 Principal；

2）为了保证各个机房的 KDC 数据库同步，我们使用 Rsync 同步主机房的 Kerberos 数据库到各个机房。一旦有新增数据，Rsync 捕捉到就会同步到各个机房数据库。另外每个机房部署两台 KDC Server，Rsync Server 使用了 Keepalive VIP 的方式，当 KDC 主机器宕机后，VIP 就会漂移到另外一台 KDC Server 上，Rsync Client 会以 VIP 所在的 KDC 主机器为 Rsync Server 进行数据同步，保证 KDC 服务的高可用。

Principal 规范化、流程化

前期所有的 Principal 的增、删、改、查都是运维工程师手动操作，由于业务的不断增长，每天都有大量的这种需求，占用了运维工程师大量时间。于是，我们开发并上线了 Kerberos 管理系统，实现了 Principal 的规范化、自动化，将运维工程师抽离出来了。用户第一次登陆系统时，会创建对应的个人 Kerberos 帐号。如果要申请新的 Principal，只需要在平台上提交申请，后台就会发送邮件给管理员，管理员审批不通过会被打回，用户重新提交即可；管理员通过后，WebServer 就会提交申请请求，后台通过调用 KDC Admin 生成对应的 Kerberos Principa 和所需的密码和 keytab 文件。同时，用户自己也可以方便的管理自己拥有的 Kerberos Principal，修改密码、导出 keytab 文件和查看自己拥有权限的 Kerberos Principal。

Kerberos Principal 和 LDAP 帐号结合

由于服务的 Kerberos Principal 并不是某个人独占，一般都是同项目组的人共有。但是不同的人对 Principal 的权限不同，于是我们引入了公司的 LDAP 帐号，与 Kerberos Principal 结合。一般申请某个 Principal 的人就是该 Principal 的 Owner，同时他也可以对这个 Principal 增、删 Owner 和更改权限。另外，也可以转让 Principal 的管理权限给其他人。假如某个 Principal 的 Owner USER1 要离职了，USER1 可以授权 USER 为该 Principal 的管理员。这些都极大地方便了 Kerberos Principal 的管理。

监控全覆盖

我们从三个层面对 KDC 服务做了全方位监控：

1）利用进程监控工具对 KDC 服务、MySQL 和 WebServer 进程监控，一旦进程异常退出，进程管理工具就会自动拉起服务；

2）模拟 Kerberos 用户真实环境，创建了测试帐号，在各个机房访问 KDC 服务，并将对返回值监控；

3） 基础监控：利用监控系统对服务端口、内存和磁盘等进行监控。

日志记录

对 Kerberos Principal 的所有操作都有日志记录，日志中包括查看有权限帐号、导出 keytab 文件、重置密码以及帐号的增、删、改、查其拥有人权限等，这样我们可以方便的定位问题。另外，我们对 MySQL 到 KDC 的 Replicate 的操作也进行了记录，来获取帐号的增、删方面的信息。

总结

Hadoop 集群引入 Kerberos 服务，使得集群内部的节点之前是互相信任的，防止了恶意的使用和篡改 Hadoop 集群信息，确保了 Hadoop 集群的安全性。但是，使用 Kerberos 对于集群内节点时间同步要求比较高，一旦时间相差太大就会造成认证失败。