Kerberos和Apache Sentry干货实践（上）

好大夫在线是一家互联网医疗公司，医疗数据的安全性关乎重大。而现阶段的大数据平台并没有原生的安全认证，Cloudera公司的开源大数据平台CDH在内网实践中，也仅由网络防火墙来解决安全问题。在对数据安全要求极高的医疗领域场景下，这样的安全保障是不够的，它无法保证内网人员对数据访问权限的严格控制，这一缺点如果被人潜入内部利用则会发生灾难。

背景

医疗行为本身决定了患者和医生都不可能隐瞒或者造假，即医疗数据具有普遍的真实性和隐私性，并存在极高的质量和价值。同时，医疗数据覆盖范围广，既是个体的生物学数据，又包含了疾病传播、地区流行病发展等数据，一旦数据泄漏将会带来严重影响。因此，使用网络安全认证和权限管理来对数据资产进行安全加固势在必行。

好大夫在线大数据部门，通过前期的调研和验证，最终决定把Kerberos和Apache Sentry集成到大数据集群上，用于加固数据安全，防止数据的泄漏。

Kerberos是什么？

Kerberos提供了大数据组件之间的身份认证，简单说就是，当A组件去访问B组件时， B能够确认来访的A就是真的A，而不是被其他CDEF冒充的，A也能确认自己要访问的B就是真的B，而不是被路由到其他的恶意组件上。

Kerberos 由 MIT 创建，是一种计算机网络安全协议，用于在不可信网络（例如 Internet）上的两个或多个可信主机之间对服务请求进行身份验证，解决网络安全问题。

该协议的名称源于希腊神话中传说中的三头犬 Kerberos，在此协议的架构中 Kerberos 的三个头分别代表了客户端，服务器和密钥分发中心（KDC）。KDC 用作受信任的第三方身份验证服务。

它使用对称密钥加密手段验证客户端 - 服务器应用程序，使用密钥加密技术对受信任的第三方验证用户的身份。

这意味着未加密的密码不会在网络上传输，客户端可以通过不安全的网络连接向服务器证明其身份，之后，他们还可以加密所有通信，以确保在开展业务时的私密性和数据完整性。

Kerberos 在可靠审核和身份验证功能的安全系统中大量使用。还可以用于 Posix 以及 Active Directory，NFS 和 Samba 的身份验证。

为什么要用 Kerberos？

互联网本身就是一个不安全的环境。Internet 中使用的许多协议都不提供任何安全性。恶意黑客通过嗅探网络来偷取用户的密码。因此，通过网络发送未使用加密密码的应用程序极易受到攻击。

更糟糕的是，客户端 / 服务器应用程序依靠客户端程序认为正在使用该客户端程序的用户的身份是安全可靠的。

Kerberos 工作流程中涉及的主要概念

1、主体（Principal）

在 Kerberos 系统中，客户端和服务器都有一个唯一的名字即 Principal，组件间相互访问使用 Principal 相互识别身份。每一个主体（Principal）都有自己的密码，且只有主体本身和密钥分发中心 KDC 知道。Principal 由三个部分组成：primary, instance 以及 realm，其组成形式为 primary/instance@realm：

• primary：可以是 OS 中的 username，也可以是 service name；
• instance：用于区分属于同一个 user 或者 service 的多个 principals，该项为 optional；
• realm：类似于 DNS 中的 domain，一个集群内的机器拥有相同的 realm。

Kerberos 中的 Principal 分两种。一种叫用户，例如在 dev 用户对应的 Kerberos 主体叫做 dev@CDH.COM。另一种叫做服务，如 cdh1 机器上的 Impala 服务, 对应在 Kerberos 中的主体为 impala/cdh1@CDH.COM。

2、密钥分发中心 KDC（key distribution center）

KDC 包含身份验证服务器（AS）和票证授予服务器（TGS）两部分。

KDC 只做两件事：身份验证和票证授予，AS 模块用于给所有用户主体（Principal）授予 TGT, TGS 模块用于验证访问发起方的 TGT，并授予被访问主体的 Ticket。

身份验证服务器 AS（authentication service）：AS 执行所需的客户端身份验证。如果身份验证成功完成，则 AS 向客户端颁发一个称为 TGT（票证授予票证）的票证。此票证可确保其他服务器对客户端进行身份验证。

票证授权票证 TGT（ticket granting ticket）：由 KDC 的 AS 发放；获得这样一张票据后，以后申请其他应用的服务票据（ST）时，就不需要向 KDC 提交身份认证信息，TGT 具有一定的有效期，就像是 Kerberos 进行用户登陆（Kinit）以后票证具有一个固定时间的有效期，过了有效期需要不断的去 renew 来续约，续约到期需要重新提交身份认证信息。

票证授予服务 TGS（ticket granting service）：TGS 以票证授权票证（TGT）为依据，生成服务票证 ST。

服务票证 ST(service ticket)：由 KDC 的 TGS 发放，任何一个应用（application）都需要一张有效的服务票据才能访问；如果能正确接受 ST，说明客户端（client）和服务器（server）之间的信任关系已经被建立，通常是一张数字加密的证书。

Kerberos 工作流程

Step 1: 初始客户端身份验证请求。用户（Principal）从身份验证服务器（AS）索取票证授予票证（TGT），该请求包括客户端 ID。

Step 2: KDC 验证客户端的凭据。AS 检查数据库中的客户端和 TGS 的可用性。如果 AS 找到两个值，它将使用用户的密码哈希值生成客户端 / 用户密钥。然后，AS 计算 TGS 密钥，并创建由客户端 / 用户密钥加密的会话密钥（SK1）。然后，AS 会生成一个包含客户端 ID，客户端网络地址，时间戳，生存期和 SK1 的 TGT。然后，TGS 密钥对票证进行加密。

Step 3: 客户端解密消息。客户端使用 客户端 / 用户 密钥对消息解密并提取 SK1 和 TGT，从而生成用于验证客户端 TGS 的身份验证器。

Step 4: 客户端使用 TGT 请求访问。客户端通过将提取的 TGT 和创建的身份验证器发送到 TGS，向提供服务的服务器请求票证。

Step 5: KDC 为文件服务器创建票证。TGS 使用 TGS 密钥解密从客户端收到的 TGT 并提取 SK1。TGS 解密身份验证器，并检查其是否与客户端 ID 和客户端网络地址匹配。TGS 还使用提取的时间戳来确保 TGT 尚未过期。如果该过程成功进行了所有检查，则 KDC 会生成一个服务会话密钥（SK2），该密钥在客户端和目标服务器之间共享。最后，KDC 创建一个服务票证，其中包括客户端 ID，客户端网络地址，时间戳和 SK2，使用从数据库获得的服务器密钥对该票证进行加密。客户端收到一条消息，其中包含服务票证和 SK2，均用 SK1 加密。

Step 6: 客户端使用文件票证进行身份验证。客户端使用 SK1 解密消息并提取 SK2。此过程将生成一个新的身份验证器，其中包含用 SK2 加密的客户端网络地址，客户端 ID 和时间戳，并将其和服务票证发送到目标服务器。

Step 7: 目标服务器接收解密和身份验证。目标服务器使用服务器的密钥来解密服务票证并提取 SK2。服务器使用 SK2 解密身份验证器，执行检查以确保身份验证器中的客户端 ID 和客户端网络地址与服务票证相匹配。服务器还会检查服务票证，看它是否已过期。满足检查要求后，目标服务器将向客户端发送一条消息，以验证客户端和服务器之间是否已通过身份验证。若验证通过，用户就可以进行安全会话。

上述原理是不是已经有点晕了呢，没关系，举个例子就明白了：

假设小明要去游乐场玩，首先需要在大门口检查游客的身份 (即检查小明的 ID 和 PASS), 如果小明通过验证，游乐场的门卫 (AS) 则会提供给小明一张门卡 (TGT)。

这张卡片的用处就是告诉游乐场的各个场所的服务员，小明是通过正门进来，而不是后门偷爬进来的，同时这张卡片也是小明进入游乐场游玩需要的第一把钥匙。

现在小明有了这张卡，但是小明来游乐场拿这张卡是不能玩游乐项目的。这时小明想玩过山车，过山车的服务员 (client) 拦下小明，向小明要过山车的 (ST) 票据，小明说他只有一个门卡 (TGT), 那小明只要把 TGT 放在一旁的票据授权机 (TGS) 上刷一下。票证授权机 (TGS) 就会根据小明现在所在的过山车项目，给小明一张过山车的门票 (ST), 这样小明有了过山车的票据，验证通过后小明就可以畅通无阻的游玩了。

当然如果小明玩完过山车后，想去游乐场的跳楼机玩，那小明一样只需要带着那张门卡 (TGT)，到对应的跳楼机票证授权机 (TGS) 上刷一下，得到跳楼机的票据 (ST) 就可以玩跳楼机了。

但是当小明离开游乐场后，这张门卡（TGT）就作废了，因为小明的 TGT 已经过期了，再想做任何事都会被拒绝，除非重新申请拿到门卡（TGT）。

Kerberos 是如何在大数据平台使用的？

a) 因为要使用超过 128 位的加密密钥，那么必须使用非受限管辖区域策略文件 local_policy.jar，US_export_policy.jar，所以需要在部署 Kerberos 服务的机器上替换 JRE 的加密 jar 包，可自行去 Oracle 官网下载；

b) Kerberos 的集群节点可以被 DNS 解析或者在 hosts 中配置所有节点的映射关系；

c) 在其中一台机器上安装 KDC：yum -y install krb5-server krb5-libs krb5-auth-dialog krb5-workstation openldap-clients；

d) 剩余机器上安装 Kerberos 的客户端：yum -y install krb5-libs krb5-workstation；

e) 安装完成后，修改 KDC 所在机器的 krb5.conf，主要修改的内容已加注释说明：

[logging]
 default = FILE:/var/log/krb5libs.log
 kdc = FILE:/var/log/krb5kdc.log
 admin_server = FILE:/var/log/kadmind.log

[libdefaults]
 default_realm = CDH.COM #域名要保持一致
 dns_lookup_realm = false
 dns_lookup_kdc = false
 ticket_lifetime = 24h #票证的声明周期
 renew_lifetime = 2d #票证的最大续期时间
 forwardable = true

[realms]
 CDH.COM = {
  kdc = cdh1
  admin_server = cdh1
 }

[domain_realm]
 .cdh1.com = CDH.COM
 cdh1.com = CDH.COM

[kdc]
 profile=/var/kerberos/krb5kdc/kdc.conf

f) 修改 kdc.conf，主要修改内容已加注释说明：

[kdcdefaults]
 kdc_ports = 88
 kdc_tcp_ports = 88

[realms]
 CDH.COM = { #与 krb5.conf 的域名保持一致
  #master_key_type = aes256-cts #不使用默认的加密
  max_renewable_life= 2d #最大续期时间
  acl_file = /var/kerberos/krb5kdc/kadm5.acl
  dict_file = /usr/share/dict/words
  admin_keytab = /var/kerberos/krb5kdc/kadm5.keytab
  supported_enctypes = aes256-cts:normal aes128-cts:normal des3-hmac-sha1:normal arcfour-hmac:normal des-hmac-sha1:normal des-cbc-md5:normal des-cbc-crc:normal
 }

g) 修改 kadm5.acl，添加管理员权限：/admin@CDH.COM

h) 创建数据库：kdb5_util create -r CDH.COM -s；

i) 创建管理员账户及密码然后启动 Kerberos；

j) 分发 krb5.conf 到其他相同路径的 Kerberos 客户端节点上；

k) CDH 集群配置开启 Kerberos：

全选后点继续：

下一步导入 KDC Account Manager 凭据 命令完成后，点击继续：

默认配置，点击继续：

自动重启集群中的所有服务，校验是否启用成功，并对各角色进行授信：

至此，大数据集群各组件的 Kerberos 认证就完成了！

那么 Kerberos 就一定安全可靠么？

Kerberos 仍然是当今可用的最佳安全访问协议，该协议足够灵活，可以采用更强大的加密算法来帮助抵御新的威胁，如果用户实施了良好的密码选择策略，那么安全级别也会更高。

好了，至此 Kerberos 的背景、原理及搭建过程大致结束。下一篇中，我们将继续讲述 Apache Sentry 相关知识，以及其如何和 Kerberos 一起来进行访问权限控制的，感兴趣的小伙伴欢迎持续关注 Kerberos。

作者介绍：

张博雅：好大夫在线大数据开发工程师，涉猎技术包括分布式实时离线计算，数据仓库建设，数据安全等，喜欢研究解决大数据组件相关问题。

马大芳：好大夫在线大数据开发工程师，专注大数据领域，主要关注 Kafka/Spark/HBase 等开源组件，热爱技术和探索。

好大夫在线创立于 2006 年，是一家互联网医疗平台。已收录国内 10496 家正规医院的 69.2 万名医生信息。其中，23 万名医生在平台上实名注册，直接向患者提供线上医疗服务。