Keberos安全认证学习

最新推荐文章于 2025-03-22 12:15:22 发布

JY_He

最新推荐文章于 2025-03-22 12:15:22 发布

阅读量1.5k

点赞数 1

CC 4.0 BY-SA版权

分类专栏： kerberos

本文链接：https://blog.youkuaiyun.com/JY_He/article/details/89925152

本文深入探讨Kerberos网络认证协议，包括其角色概念、认证过程和在Hadoop安全机制中的应用。Kerberos通过TGT（Ticket Granting Ticket）和会话密钥确保用户和服务间安全通信。在Hadoop中，Delegation Tokens作为轻量级认证机制，用于减轻KDC的压力。理解Kerberos ticket和Hadoop token的生命周期对于管理认证至关重要。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

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

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

图 1.1 Kerberos认证

Kerberos角色概念：

AS（Authentication Server）：认证服务器。KDC的一部分。通常会维护一个包含安全个体及其秘钥的数据库，用于身份认证
KDC（Key Distribution Center）：密钥分发中心。，是一个提供票据（tickets）和临时会话密钥（session keys）的网络服务。KDC服务作为客户端和服务器端信赖的第三方，为其提供初始票据（initial ticket）服务和票据授予票据（ticket-granting ticket）服务，前半部分有时被称为AS，后半部分有时则被称为TGS。
TGT（Ticket Granting Ticket）：票据授权票据，票据的票据。包含客户端ID、客户端网络地址、票据有效期以及client/TGS会话密钥（TGT是和Server无关的）
TGS（Ticket Granting Server）：票据授权服务器。KDC的一部分，根据客户端传来的TGT发放访问对应服务的票据
SS（Service Server）：特定服务提供端
Principal：被认证的个体。(client principal/server principal: 分别表示客户端和服务器的名字,命名规则：主名称+实例+领域。例如：admin/admin@ZELDA.COM）
Ticket：票据，客户端用它访问对应服务。包含：用户名，IP，时间戳，有效期，会话秘钥
Session key：会话密钥，指两个安全个体之间使用的临时加密秘钥，其时效性取决于单点登录的会话时间长短
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请求访问某个服务的票据。

客户端在获得自己和KDC的SK1之后，生成自己的A uthentication以及要访问的Server名称，并使用Session Key进行加密，连同TGT一同发送给KDC；
KDC中的TGS首先检查KDC数据库中是否存在所需服务，若存在则使用自己的Master Key对TGT进行解密，提取客户端信息（Client Info）和SK1，然后，使用这个SK1解密Authenticator获得Client Info，对两个Client Info进行对比，进行身份验证。
若验证通过，TGS则使用SK1对客户端和服务端