12、kerberos&LDAP 安全密钥管理技术

1.Kerberos&LDAP 简介

（1）Kerberos 是安全认证的概念，该系统设计上采用客户端/服务器结构与 DES、 AES 等加密技术，并且能够进行相互认证，即客户端和服务器端均可对对方进行身份认证。可以用于防止窃听、防止 reply 攻击、保护数据完整性等场合，是一种应用对称密钥体制进行密钥管理的系统。

Kerberos 基本概念：

票据授权票据 (TGT Ticket-Granting Ticket) ：用于应用程序与 KDC(Key Distribution Center 密钥分发中心)服务器建立安全会话的票据，票据授权票据存在有效期，当票据授权票据失效后，应用侧需要重新建立与 KDC 服务器的安全会话。会话有效期为 24 小时，不可配置。

服务票据(STServiceTicket)：用于应用程序与服务端建立安全会话的票据，服务票据存在有效期，当服务票据失效后，应用侧需要重新建立与服务端的安全会话。默认有效期为 5 分钟，不可配置。

（2） Ldap(LightweightDirectoryAccessProtocol)，轻量目录访问协议，提供被称为目录服务的信息服务，特别是基于 X.500（构成全球分布式的目录服务系统的协议）的目录服务。Ldap 运行在 TCP/IP 或其他面向连接的传输服务之上。 Authentication 解决的是“如何证明某个人确确实实就是他或她所声称的那个人”的问题。对于如何进行 Authentication，我们采用这样的方法：如果一个秘密（secret）仅仅存在于 A 和 B，那么有个人对 B 声称自己就是 A，B 通过让 A 提供这个秘密来证明这个人就是他或她所声称的 A。这个过程实际上涉及到 3 个重要的关于 Authentication 的方面：

（1）Secret 如何表示。

（2）A 如何向 B 提供 Secret。

（3）B 如何识别 Secret。

基于这 3 个方面，我们把 KerberosAuthentication 进行最大限度的简化：整个过程涉及到 Client 和 Server，他们之间的这个 Secret 我们用一个 Key （KServer-Client）来表示。Client 为了让 Server 对自己进行有效的认证，向对方提供如下两组信息：

代表 Client 自身 Identity 的信息，为了简便，它以明文的形式传递。将 Client 的 Identity 使用 KServer-Client 作为 PublicKey、并采用对称加密算法进行加密。由于 KServer-Client 仅仅被 Client 和 Server 知晓，所以被 Client 使用 KServer-Client 加密过的 ClientIdentity 只能被 Client 和 Server 解密。同理，Server 接收到 Client 传送的这两组信息，先通过 KServer-Client 对后者进行解密，随后将机密的数据同前者进行比较，如果完全一样，则可以证明Client 能过提供正确的 KServer-Client，而这个世界上，仅仅只有真正的 Client和自己知道 KServer-Client，所以可以对方就是他所声称的那个人。Keberos 大体上就是按照这样的一个原理来进行 Authentication 的。但是 Kerberos 远比这个复杂。

2.LDAP 文件结构

LDAP 信息模型是基于条目来组织的，一个条目是一组属性的集合，有一个全球唯一的识别名（DN,DomainName）。

DN 用于标识条目。每个条目的属性有一个类型和一个或多个值。该类型通常是可记忆的字符串，如“cn”就是标识通用名称，或者“电子邮件”就是电子邮件地址。该类型值的语法依赖于属性类型。

树也可以根据互联网域名组织。这种命名方式目前在业界非常普遍，因为它允许使用 DNS 为目录服务定位。

 

3.用户属性

用户是作为管理 FusionInsight 的一个基本实体，又称之为帐号。用户包含如下的附属信息：用户名，密码，用户类别，用户归属组，用户归属角色，用户电话号码，用户邮箱，用户基本描述。

（1） 用户类别分为人机用户和机机用户，做出这样的区分主要是从用户使用的场景考虑的（API 接口使用，还是界面交互使用）。其中创建人机用户类别的用户时，需要输入指定的密码，而创建机机用户类别的帐号时，不需要指定密码，由 Kerberos 通过安全算法生成随机密钥。

（2） 用户在 FusionInsight 系统中又分为默认用户和非默认用户

1. 默认用户指的是 FusionInsight 系统安装，运行所需要的用户，对客户不可见，完全是系统自运行所需要而由系统自行创建，例如 HDFS 业务运行所依赖的 hdfs 用户。
2. 非默认用户指的是由客户创建或者二次开发应用创建，对客户可见，在用户管理系统的界面上可以直接看到该用户及附属信息，例如通过用户管理界面创建一个 test 用户，此时可以看到该用户的附属信息。

（3） 从安全认证的角度去划分用户的类别，又可以将用户分为服务端用户和客户端用户。

1. 服务端用户：指的是集群某个服务的运行用户，例如 HDFS 服务运行依赖的 hdfs/hadoop.hadoop.com 用户。
2. 客户端用户：指的是进行安全认证的客户端应用程序运行使用的用户，例如某个应用程序需要访问 HDFS 服务，那么该业务流程需要先进行 Kerberos 认证，那么此时就需要使用一个客户端用户去进行 Kerberos 认证，例如该用户为 test，即为客户端用户。

密码策略：

用户属性还有一个关键的因素，即用户密码策略，密码策略指定了该用户的密码属性信息，包含最短密码长度，密码组成的字符种类，密码校验失败的锁定时长等信息。

对于人机用户和机机用户的密码策略是有区别的，人机用户的密码策略包含了密码的过期时间，默认为 90 天，而机机用户由于没有显示的密码（系统随机生成），因此其密码策略不包含过期时间，即永久有效。 keytab 文件是由服务端 Kerberos 生成。内容为该用户的密码通过 AES-128/AES-256 加密生成的密文文件。

使用场景：

集群内某个服务需要使用 keytab 进行运行时安全认证使用，例如 hdfs 启动依赖 keytab 文件，启动前进行安全认证。客户进行二次开发的应用程序需要使用 keytab 进行集群业务访问前的安全认证，例如查询 hdfs 目录或者 put 数据前，需要使用该 keytab 通过 kerberos 认证。 keytab 需由使用者保密以确保安全，避免泄露给其他人。

4.Kerberos 认证流程

 

（1） 当某一个用户需要通过客户端访问服务端的某一个服务的时候，首先客户端会向认证服务器发送 KRB_AS_REQ 信息进行认证

（2） 认证服务器会验证客户端的用户身份（例如按照用户名密码的验证方式），验证通过之后，认证服务器会给客户端返回一个 TGT 票据授权票和会话秘钥，客户端将信息解密之后获取到 TGT 和会话秘钥，用于和 TGS 建立信任的联系。并且用于请求 ST 服务票据

（3） 下一步客户端会向 TGS 票据授权服务器发送请求，信息中携带了客户端用户的名称、域名、时间戳等信息

（4） 票据授权服务器在收到请求、验证身份之后，会给该服务端应用分配一个ST 服务票据，里面包含了客户端的应用名称，IP 地址，域名和票据的存活期。

（5） 客户端会将自己的 ST 发送给服务端请求对应的服务，服务端验证 ST 通过之后就可以进行正常的访问。如果客户端需要服务端进行响应，那么服务端会返回 KRB_AP_REP 信息。

通过以上的介绍，我们基本上了解了整个 Kerberosauthentication 的整个流程：整个流程大体上包含以下 3 个子过程：

Client 向 KDC 申请 TGT（TicketGrantingTicket）。

Client 通过获得 TGT 向 DKC 申请用于访问 Server 的 Ticket。 Client 最终向为了 Server 对自己的认证向其提交 Ticket。

不过上面的介绍离真正的 KerberosAuthentication 还是有一点出入。Kerberos整个认证过程通过 3 个 sub-protocol 来完成。这个 3 个 Sub-Protocol 分别完成上面列出的 3 个子过程。这 3 个 sub-protocol 分别为：

AuthenticationServiceExchangeTicketGrantingServiceExchangeClient/Serv erExchange 下图简单展示了完成这个 3 个 Sub-protocol 所进行 MessageExchange。

通过让被认证的一方提供一个仅限于他和认证方知晓的 Key 来鉴定对方的真实身份。而被这个 Key 加密的数据包需要在 Client 和 Server 之间传送，所以这个

Key 不能是一个 Long-termKey，而只可能是 Short-termKey，这个可以仅仅在 Client 和 Server 的一个 Session 中有效，所以我们称这个 Key 为 Client 和 Server 之间的 SessionKey（SServer-Client）。

现在我们来讨论 Client 和 Server 如何得到这个 SServer-Client。在这里我们要引入一个重要的角色： KerberosDistributionCenter-KDC 。 KDC 在整个 KerberosAuthentication 中作为 Client 和 Server 共同信任的第三方起着重要的作用，而 Kerberos 的认证过程就是通过这 3 方协作完成。顺便说一下，Kerberos起源于希腊神话，是一支守护着冥界长着 3 个头颅的神犬，在 keberos Authentication 中，Kerberos 的 3 个头颅代表中认证过程中涉及的 3 方：Client、 Server 和 KDC。

对于一个 WindowsDomain 来说，DomainController 扮演着 KDC 的角色。KDC 维护着一个存储着该 Domain 中所有帐户的 AccountDatabase （一般地，这个 AccountDatabase 由 AD 来维护），也就是说，他知道属于每个 Account 的名称和派生于该 AccountPassword 的 MasterKey。而用于 Client 和 Server 相互认证的 SServer-Client 就是有 KDC 分发。下面我们来看看 KDC 分发 SServer-Client 的过程。

通过下图我们可以看到 KDC 分发 SServer-Client 的简单的过程：首先 Client 向 KDC 发送一个对 SServer-Client 的申请。这个申请的内容可以简单概括为“我是某个 Client，我需要一个 SessionKey 用于访问某个 Server”。KDC 在接收到这个请求的时候，生成一个 SessionKey，为了保证这个 SessionKey 仅仅限于发送请求的 Client 和他希望访问的 Server 知晓，KDC 会为这个 SessionKey 生成两个 Copy，分别被 Client 和 Server 使用。然后从 Accountdatabase 中提取 Client 和 Server 的 MasterKey 分别对这两个 Copy 进行对称加密。对于后者，和 SessionKey 一起被加密的还包含关于 Client 的一些信息。

KDC 现在有了两个分别被 Client 和 Server 的 MasterKey 加密过的 SessionKey，这两个 SessionKey 如何分别被 Client 和 Server 获得呢？也许你马上会说，KDC直接将这两个加密过的包发送给 Client 和 Server 不就可以了吗，但是如果这样做，对于 Server 来说会出现下面两个问题：

由于一个 Server 会面对若干不同的 Client,而每个 Client 都具有一个不同的SessionKey。那么 Server 就会为所有的 Client 维护这样一个 SessionKey 的列表，这样做对于 Server 来说是比较麻烦而低效的。由于网络传输的不确定性，可能出现这样一种情况：Client 很快获得 SessionKey，并将这个 SessionKey 作为 Credential 随同访问请求发送到 Server，但是用于 Server 的 SessionKey 确还没有收到，并且很有可能承载这个 SessionKey 的永远也到不了 Server 端，Client 将永远得不到认证。为了解决这个问题，Kerberos 的做法很简单，将这两个被加密的 Copy 一并发送给 Client，属于 Server 的那份由 Client 发送给 Server。通过上面的过程，Client 实际上获得了两组信息：一个通过自己 MasterKey 加密的 SessionKey，另一个被 Sever 的 MasterKey 加密的数据包，包含 SessionKey和关于自己的一些确认信息。通过第一节，我们说只要通过一个双方知晓的 Key 就可以对对方进行有效的认证，但是在一个网络的环境中，这种简单的做法是具有安全漏洞，为此,Client 需要提供更多的证明信息，我们把这种证明信息称为Authenticator，在 Kerberos 的 Authenticator 实际上就是关于 Client 的一些信息和当前时间的一个 Timestamp（关于这个安全漏洞和 Timestamp 的作用，我将在后面解释）。在这个基础上，我们再来看看 Server 如何对 Client 进行认证：Client 通过自己的 MasterKey 对 KDC 加密的 SessionKey 进行解密从而获得 SessionKey，随后创建 Authenticator（ClientInfo+Timestamp）并用 SessionKey 对其加密。最后连 同 从 KDC 获 得 的 、 被 Server 的 MasterKey 加 密 过 的 数 据 包（ClientInfo+SessionKey）一并发送到 Server 端。我们把通过 Server 的 MasterKey 加密过的数据包称为 SessionTicket。当 Server 接收到这两组数据后，先使用他自己的 MasterKey 对 SessionTicket 进行解密，从而获得 SessionKey。随后使用该 SessionKey 解密 Authenticator，通过比较 Authenticator 中的 ClientInfo 和 SessionTicket 中的 ClientInfo 从而实现对 Client 的认证。

 Kerberos 实际上一个基于 Ticket 的认证方式。Client 想要获取 Server 端的资源，先得通过 Server 的认证；而认证的先决条件是 Client 向 Server 提供从 KDC获得的一个有 Server 的 MasterKey 进行加密的 SessionTicket（SessionKey +ClientInfo）。可以这么说，SessionTicket 是 Client 进入 Server 领域的一张门票。而这张门票必须从一个合法的 Ticket 颁发机构获得，这个颁发机构就是 Client 和 Server 双方信任的 KDC，同时这张 Ticket 具有超强的防伪标识：它是被 Server 的 MasterKey 加密的。对 Client 来说，获得 SessionTicket 是整个认证过程中最为关键的部分。我们今天所讲的 Client 获得 Ticket 的过程也和通过认股权证购买股票的过程类似。如果我们把 Client 提供给 Server 进行认证的 Ticket 比作股票的话，那么 Client 在从 KDC 那边获得 Ticket 之前，需要先获得这个 Ticket 的认购权证，这个认购权证在 Kerberos 中被称为 TGT：TicketGrantingTicket，TGT 的分发方仍然是 KDC。我们现在来看看 Client 是如何从 KDC 处获得 TGT 的：首先 Client 向 KDC 发起对 TGT 的申请，申请的内容大致可以这样表示：“我需要一张 TGT 用以申请获取用以访问所有 Server 的 Ticket”。KDC 在收到该申请请求后，生成一个用于该Client 和 KDC 进行安全通信的 SessionKey（SKDC-Client）。为了保证该 Session Key 仅供该 Client 和自己使用，KDC 使用 Client 的 MasterKey 和自己的 Master Key 对生成的 SessionKey 进行加密，从而获得两个加密的 SKDC-Client 的 Copy。对于后者，随 SKDC-Client 一起被加密的还包含以后用于鉴定 Client 身份的关于 Client 的一些信息。最后 KDC 将这两份 Copy 一并发送给 Client。这里有一点需要注意的是：为了免去 KDC 对于基于不同 Client 的 SessionKey 进行维护的麻烦，就像 Server 不会保存 SessionKey（SServer-Client）一样，KDC 也不会去保存这个 SessionKey（SKDC-Client），而选择完全靠 Client 自己提供的方式。当 Client 收到 KDC 的两个加密数据包之后，先使用自己的 MasterKey 对第一个Copy 进行解密，从而获得 KDC 和 Client 的 SessionKey（SKDC-Client），并把该 Session 和 TGT 进行缓存。有了 SessionKey 和 TGT，Client 自己的 MasterKey将不再需要，因为此后 Client 可以使用 SKDC-Client 向 KDC 申请用以访问每个Server 的 Ticket，相对于 Client 的 MasterKey 这个 Long-termKey，SKDC-Client是一个 Short-termKey，安全保证得到更好的保障，这也是 Kerberos 多了这一步的关键所在。同时需要注意的是 SKDC-Client 是一个 SessionKey，他具有自己的生命周期，同时 TGT 和 Session 相互关联，当 SessionKey 过期，TGT 也就宣告失效，此后 Client 不得不重新向 KDC 申请新的 TGT，KDC 将会生成一个不同SessionKey 和与之关联的 TGT。同时，由于 ClientLogoff 也导致 SKDC-Client 的失效，所以 SKDC-Client 又被称为 LogonSessionKey。接下来，我们看看 Client 如何使用 TGT 来从 KDC 获得基于某个 Server 的 Ticket。在这里我要强调一下，Ticket 是基于某个具体的 Server 的，而 TGT 则是和具体的 Server 无关的，Client 可以使用一个 TGT 从 KDC 获得基于不同 Server 的Ticket。我们言归正传，Client 在获得自己和 KDC 的 SessionKey（SKDC-Client）之后，生成自己的 Authenticator 以及所要访问的 Server 名称的并使用 SKDC-Client 进行加密。随后连同 TGT 一并发送给 KDC。KDC 使用自己的 MasterKey 对 TGT 进行解密，提取 ClientInfo 和 SessionKey（SKDC-Client），然后使用这个 SKDC-Client 解密 Authenticator 获得 ClientInfo，对两个 ClientInfo 进行比较进而验证对方的真实身份。验证成功，生成一份基于 Client 所要访问的 Server的 Ticket 给 Client

5.Kerberos 架构

Kerberos1 对 Ldap 中数据的操作方式：访问 Ldap1（主备两个实例）和 Ldap2（主备两个实例），是采用负荷分担访问，数据的写操作只能在 Ldap2（主实例）上。数据的读操作可以在 Ldap1 或者 Ldap2 上。Kerberos2 对 Ldap 中数据的操作方式：只能访问 Ldap2（包含主备两个实例），数据的写操作只能在 Ldap2（主实例）。

登录操作详解：

在 WebUI 登陆流程中，主要是对接 cas 使用，实现单点登陆。在组件登陆 Kerberos 流程中，主要是提供作业的安全认证。

部署 Ldap1 和 Ldap2 是为了提升可靠性，避免 oms 或者集群中部署 Ldap 的节点故障后，无法登陆 Manager 进行基本的运维操作。这两个非角色关系（非集群中的服务-角色的概念），只是一个归属于 oms 管理(Ldap1)，作为进程存在；一个归属集群管理，作为一个组件存在(Ldap2)。

Manager：FusionInsightManager

ManagerWS ： FusionInsightHDWebBrowserKerberos1 ： 部 署 在 oms 中 的kerberos(管理平面)服务。Ldap1：部署在 oms 中的 ldap(管理平面)服务。Kerberos2：部署在集群中的 kerberos(业务平面)服务。Ldap2：部署在集群中的ldap(管理平面)服务。非角色关系：非集群中的服务-角色的概念,仅仅是 oms 内的进程。 4.14.2 是 2 个并行执行的流程。

 6.Kerberos 和 LDAP 的交互

 

Kerberos 作为认证服务器中心，向集群内所有服务以及客户的二次开发应用提供统一的认证服务。Ldap 作为用户数据存储中心，存储了集群内用户的信息，包含密码，附属信息等。统一认证的过程中，Kerberos 的所有数据，包含用户的密码，用户的附属信息（例如用户归属组信息）均需要从 Ldap 获取。每一次的认证业务，Kerberos 均需要从 Ldap 中获取用户信息。

7.Kerberos 和 LDAP 的特性

（1）信息存储功能 Ldap 作为 FusionInsight 的基础组件主要提供用户数据存储功能，其中包含集群内的默认用户（例如 admin 用户），客户创建的用户（例如通过 UI 界面创建一个用户）。存储了用户的两个关键信息，分别是 Kerberos 信息和 Ldap 信息。①Kerberos 信息主要包含用户的用户名，密码信息，对 Kerberos 提供认证查询功能，即密码的校验功能。②Ldap 信息主要包含用户的附属信息，例如：用户类别，用户组信息，角色信息，邮箱等。对外提供鉴权功能，即权限的识别，例如该用户是否具有访问 HDFS 某个文件目录的权限。（2）集群内服务认证Kerberos 服务在 FusionInsight 集群中是一个基础组件模块，在安全模式下，所有的业务组件都需要依赖 Kerberos 服务（组件），业务组件（如 HDFS）在对外提供业务的过程中，均需要先通过 Kerberos 的认证服务，如果无法通过 Kerberos 认证，将无法获取该业务组件的任何业务服务。LdapServer 作为 Kerberos 的数据存储模块，与其他所有的业务组件（除 Kerberos服务）均不直接交互。FusionInsight 安全模式集群内任意服务间的相互访问都是基于 Kerberos 安全方案架构实现。集群内某个服务（如 HDFS）prestart 的时候，会预先去 Kerberos 中获取该服务对应的服务名称 sessionkey（keytab，主要是提供给应用程序进行身份认证使用），在后续任意其他服务（如 YARN）需要去 HDFS 中执行增/删/改/查数据时，必须获取到对应的 TGT 和 ST，用于本次的安全访问。