Keberos安全认证学习

因为，最近要做大数据组件的安全认证，需要涉及到kerberos这个组件，记录相关资料，后续查看。

Kerberos 是一种网络认证协议，它采用了传统的共享密钥的方式，实现了在网络环境不一定保证安全的环境下，client和server之间的通信，适用于client/server模型。用户只需输入一次身份验证信息，就可凭借此验证获得的票据授予票据（ticket-granting ticket）访问多个接入Kerberos的服务。

                                              

                                                                          图 1.1 Kerberos认证

Kerberos角色概念：

1. AS（Authentication Server）：认证服务器。KDC的一部分。通常会维护一个包含安全个体及其秘钥的数据库，用于身份认证
2. KDC（Key Distribution Center）：密钥分发中心。，是一个提供票据（tickets）和临时会话密钥（session keys）的网络服务。KDC服务作为客户端和服务器端信赖的第三方，为其提供初始票据（initial ticket）服务和票据授予票据（ticket-granting ticket）服务，前半部分有时被称为AS，后半部分有时则被称为TGS。
3. TGT（Ticket Granting Ticket）：票据授权票据，票据的票据。包含客户端ID、客户端网络地址、票据有效期以及client/TGS会话密钥（TGT是和Server无关的）
4. TGS（Ticket Granting Server）：票据授权服务器。KDC的一部分，根据客户端传来的TGT发放访问对应服务的票据
5. SS（Service Server）：特定服务提供端
6. Principal：被认证的个体。(client principal/server principal: 分别表示客户端和服务器的名字,命名规则：主名称+实例+领域。例如：admin/[email protected]）
7. Ticket：票据，客户端用它访问对应服务。包含：用户名，IP，时间戳，有效期，会话秘钥
8. Session key：会话密钥，指两个安全个体之间使用的临时加密秘钥，其时效性取决于单点登录的会话时间长短
9. Keytab：以文件的形式呈现，存储了一个或多个Principal的长期的key。用途和密码类似，用于kerberos认证登录（让用户不需要明文的存储密码，和程序交互时不需要人为交互来输入密码）

认证过程

 开启安全认证后的认证方式有两种：

• 使用密码认证：

使用用户密码通过kinit认证， 获取到的TGT存在本地凭证缓存当中， 供后续访问服务认证使用。一般在交互式访问中使用。

• 使用 keytab 认证：

用户通过导出的keytab 可以免密码进行用户认证， 后续步骤一致。一般在应用程序中配置使用。

Kerberos的认证过程可细分为三个阶段：初始验证、获取服务票据和服务验证：

第一阶段主要是客户端向KDC中的AS发送用户信息，以及请求TGT。

• 客户端向KDC发送自己身份，即提供用户名密码（避免频繁使用用户名密码，可以使用keytab这个密码本）；
• AS收到请求后，随机生成一个密码Session Key，简称为SK1（使用客户端的Master Key和自己的Master Key进行加密），并返回给客户端两条消息：a）一个给客户端，b）另一个给TGS
• 客户端通过自己的Master Key对第一部分进行解密获得SK1之后，以及TGS的密钥加密的TGT 。

TGT大体又包含以下的内容：

• SK1:只在一段时间内有效的Short-term Key
• End time: TGT到期的时间。
• Client name & realm: 简单地说就是Domain name\Client;

                                

                                                                          1.2初始验证流程图

第二阶段客户端拿到之前获得的TGT（一个TGT可以从KDC获得基于不同Server的Ticket）向KDC中的TGS请求访问某个服务的票据。

1. 客户端在获得自己和KDC的SK1之后，生成自己的A       uthentication以及要访问的Server名称，并使用Session Key进行加密，连同TGT一同发送给KDC；
2. KDC中的TGS首先检查KDC数据库中是否存在所需服务，若存在则使用自己的Master Key对TGT进行解密，提取客户端信息（Client Info）和SK1，然后，使用这个SK1解密Authenticator获得Client Info，对两个Client Info进行对比，进行身份验证。
3. 若验证通过，TGS则使用SK1对客户端和服务端的会话密钥进行加密，该会话秘钥是KDC新生成的随机密钥，用于客户端与服务端的通信加密，这里简称KS2;
4. 使用服务端的密钥加密客户端访问服务端的票据（Ticket，包含用户ID、用户网络地址、票据有效期和SK2），之所以使用服务端的密钥加密，因为该Ticket是给服务验证的，且需要经过客户端传给服务端，且不能让客户端看到；
5. 客户端收到消息后，尝试通过SK1解密KDS发送的消息，得到客户端和服务端的会话密钥SK2。

注意：这里KDC不直接发送给服务的主要原因是：怕网络延迟的场景下，KDC同时将消息发送给客户端和服务端，无法确保同时到达服务端，在极端情况下KDC与服务端网络临时不通，导致客户端访问客户端验证失败，而实际上客户端是具有访问服务端权限的。

第三阶段拿到票据(Ticket)后再到该服务的提供端验证身份，然后使用建立的加密通过和服务通信。

1. 客户端向服务端发送两条消息：1）客户端-服务端票据；2）通过SK2加密的会话密钥（Authenticator，包含用户ID和时间戳）；
2. 服务端收到消息后，尝试用自己的密钥解密第一条消息，即客户端对服务端进行验证（真正拥有正确密钥的服务端才能正确解密，从Ticket中获取SK2），然后再用SK2解密第二条消息，和TGS一样，对分别来自Ticket和Authenticator中的用户ID进行验证，如果验证通过则返回确认消息，并且用SK2加密新时间戳；
3. 客户端尝试用SK2解密时间戳，得到新时间戳验证其正确性，通过验证客户端与服务端就达到了信任。（后续的通信都采用SK2加密，就好客户端与服务端比建立一个加密通道）

 

                    

                                                               图1.3 获取服务票据和服务验证流程图

对于TGT和Ticket给出了巧妙的比喻：TGT类似于护照，Ticket则是签证，而访问特定的服务则好比出游某个国家。与护照一样，TGT可标识你的身份并允许你获得多个Ticket（签证），每个Ticket对应一个特定的服务，TGT和Ticket同样具有有效期，过期后就需要重新认证。

其中，TGT具有有效期，如果过期就会失效，此后Client不得不重新向KDC申请新的TGT，KDC将会生成一个不同Session Key和与之关联的TGT。整个认证流程图如下图所示：

 

                                      

                                                                     图1.4 Kerberos认证流程

Hadoop安全机制

Hadoop在1.0.0版本之后引入Kerberos认证机制，即用户跟服务通信以及各个服务之间通信均用Kerberos认证，在用户认证后任务执行、访问服务、读写数据等均采用特定服务发起访问token，让需求方凭借token访问相应服务和数据：

1. 用户先向KDC请求TGT，做初始验证；
2. 用户通过TGT向KDC请求访问服务的Ticket；
3. 客户端通过ticket向服务认证自己，完成身份认证；
4. 完成身份认证后，客户端向服务请求若干token供后续任务执行时认证使用；
5. 后续任务执行使用token与服务进行认证

这里，Delegation Token是Hadoop自身实现的一种轻量级认证机制（Kerberos是三方认证协议，而Delegation Tokens只涉及到两方。）为了避免所有任务都要需要使用TGT通过Kerberos来进行认证，对KDC造成网络拥塞，系统瓶颈。当然，Delegation Token也具有有效期，需要周期性的更新以保证其有效性。考虑到高可用性，Delegation Tokens会被server进行持久化。HDFS NameNode将Delegation Tokens持久化到元数据中。

Server和Client在处理Delegation Tokens时会有不同的职责：

server端的Delegation Tokens

1. 发布Delegation Tokens，并保存用以验证；
2. 响应更新Delegation Tokens请求；
3. 当client端执行删除操作或token过期时，移除token；
4. 通过验证client提供的Tokens和Server端存储的token是否一致，来对client进行认证

Hadoop中Delegation Tokens的生成和验证主要依赖于HMAC机制。Delegation Token主要由两部分组成：public部分和private部分，并以形式。

1. public部分信息用于token识别，以identifier对象形式存在，作为key；
2. private部分由DelegationTokenInformation类来表示，作为value。

server端可以配置更新周期（renew-interval，默认24小时），以及Delegation Token的过期时间。过期的Delegation Tokens不能用于认证，且server端专门有一个后台线程用于将过期token移除。

server token的public部分和private部分主要包含如下表所示：

Kind	The kind of token (HDFS_DELEGATION_TOKEN, or kms-dt). The token also contains the kind, matching the identifier’s kind.
Owner	The user who owns the token.
Renewer	The user who can renew the token
Real User	Only relevant if the owner is impersonated. If the token is created by an impersonating user, this will identify the impersonating user.  For example, when oozie impersonates user joe, Owner will be joe and Real User will be oozie.
Issue Date	Epoch time when the token was issued
Max Date	Epoch time when the token can be renewed until
Sequence Number	UUID to identify the token
Master Key ID	ID of the master key used to create and verify the token

                                                           表1 server token public部分组成内容

 

renewDate	Epoch time when the token is expected to be renewed.   If it’s smaller than the current time, it means the token has expired
password	The password calculated as HMAC of Token Identifier using master key as the HMAC key.   It’s used to validate the Delegation Token provided by the client to the server.
trackingId	A tracking identifier that can be used to associate usages of a token across multiple client sessions.  It is computed as the MD5 of the token identifier

                                                          表2 server token private部分组成内容

client端的Delegation tokens

1. 从server端请求一个新的Delegation Tokens，请求同时可以指定token的更新者（renewer）;
2. 更新Delegation Tokens（如果client将自己指定为renewer），亦或请求别的组件更新token（指定的renewer）
3. 向server发送取消Delegation Tokens的请求
4. 提供Delegation Tokens供server进行认证;

client token包含以下内容：

identifier	The token identifier matching the public information part at the server side.
password	The password matching the password at the server side.
kind	The kind of token (e.g. HDFS_DELEGATION_TOKEN, or kms-dt), it matches the identifier’s kind.
service	The name of the service (e.g. ha-hdfs: for HDFS, : for KMS).
renewer	The user who can renew the token (e.g. yarn).

Kerberos ticket 生命周期

Kerberos ticket 有两种生命周期，ticket lifetime (票据生命周期) 和 renewable lifetime (可再生周期)。    

• 当ticket lifetime结束时，该ticket将不再可用；
• 如果renewable lifetime>ticket lifetime，那么在票据生命周期内都可以对其进行续约，直到达到可再生周期上限；
• 当时间达到renewable lifetime后，ticket lifetime结束后将不能继续续期，续期时将会报错”KDC can't fulfill requested option while renewing credentials”，之后需要重新申请新的ticket；
• 可再生周期与keytab无关，如果没有key和principle，keytab内容不会改变。

客户端配置项：krb5.conf

• ticket_lifetime = 1d -- ticket 的生命周期
• renew_lifetime = 7d --设置可续约的时长

1.    在登录后的一天后可以对ticket进行续期，直到第一次登录的7天后将不再允许续约；

2.    在一天内没有进行续期，将无法进行续期；

3.    对ticket进行一次续期后，ticket_lifetime恢复到24h

服务端配置项：kdc.conf

• max_life -- ticket 的默认生命周期，默认为 24h
• max_renewable_life -- ticket 允许被 renew 的最长时期，默认为0

kdc.conf配置的更改对新建的principal会立即生效，旧的不会生效，如果需要对旧的principal生效，需要modprinc指令修改：

modprinc -maxlife 670s -maxrenewlife 700s admin/[email protected]

Hadoop token生命周期

Hadoop token生命周期配置在hdfs-site.xml文件中：

配置项	默认值
dfs.namenode.delegation.key.update-interval	86400000	The update interval for master key for delegation tokens in the namenode in milliseconds.
dfs.namenode.delegation.token.max-lifetime	604800000	The maximum lifetime in milliseconds for which a delegation token is valid
dfs.namenode.delegation.token.renew-interval	86400000	The renewal interval for delegation token in milliseconds

 

凭证过期处理策略

当凭证过期之后，对安全认证的服务的后续访问则会失败。有两种方式可以解决凭证过期的问题：

1. 扩大 ticket_lifetime 和 renew_lifetime 时限；
2. 定期重新进行kinit 认证更新凭证。

Hadoop 将 Kerberos 认证部分进行了一定的封装到 UserGroupInformation 这个类。

UserGroupInformation 在 JAAS 框架上封装了 Hadoop 的用户信息， 更确切地说是对 Subject 做了一层封装。JAAS 是 Java 认证和授权服务（Java Authentication and Authorization Service）的缩写， 主要包含以下几个实体:

• Subject

Subject 是一个不可继承的实体类，它标志一个请求的来源， 包含相关的凭证标识(Principal) 和 公开和私有的凭据(Credential)。

• Principal

凭证标识，认证成功后，一个 Subject 可以被关联多个Principal。

• Credential

凭据，有公有凭据以及私有凭据

JAAS认证依赖LoginContext，客户端通过一个LoginContext对象与JAAS相互作用，这个LoginContext对象提供了一种开发应用程序的方式，它不依赖于底层的认证技术，主要描述了用于验证对象(subjects)的方法。

在安全模式下，UGI 支持不同LoginContext 配置，均是通过 HadoopConfiguration 类动态产生：

     1）hadoop-user-kerberos

使用kerberos缓存凭证登陆的配置， useTicketCache 置为 true

    2）hadoop-keytab-kerberos

使用keytab登陆的配置， useKeyTab 置为 true

免于每次输入密码，采用基于keytab 的Kerberos认证方式，调用 loginUserFromKeytab方法 完成登录，后续可以定时执行：

UserGroupInformation.getLoginUser().reloginFromKeytab()

尝试重新登录。

参考链接：

https://blog.csdn.net/wenwen360360/article/details/78913347

https://ieevee.com/tech/2016/06/07/kerberos-1.html

https://www.cnblogs.com/wuyuxiang/p/5166677.html

https://blog.csdn.net/lovebomei/article/details/79807484

https://blog.csdn.net/co_zjw/article/details/81974845

https://blog.cloudera.com/blog/2017/12/hadoop-delegation-tokens-explained/#4

https://www.cnblogs.com/zhzhang/p/5692249.html