给大数据集群配认证，Kerberos 服务几乎是绕不开的一关。它是由 MIT 在上世纪 80 年代雅典娜项目中诞生的网络认证协议，当前广泛部署的是第 5 版（RFC 4120），核心思路是：借助一个可信第三方 KDC 发放加密票据，让通信双方在不传输密码的前提下互相证明身份。选型结论可以先记住一句话——企业内网、Windows 域、Hadoop 集群这类封闭环境选 Kerberos；面向互联网的 Web 应用和 API 选 JWT/Token 一类的令牌方案。一个大数据平台项目里，HDFS、Hive、Spark 之间的互信就靠它撑着，理解它的票据机制，才能解释为什么它比简单密码认证更耐打，也比 JWT 更适合内网。
一次认证要走完的三次交换
Kerberos 服务端的核心是 KDC（密钥分发中心），由认证服务器 AS 和票据授权服务器 TGS 两部分组成。认证全程三次通信，密码从不上网络：
- 客户端向 AS 发起请求，AS 校验身份后返回两张东西：一张用 KDC 密钥加密的 TGT（票据许可票据），以及一份用用户密钥加密的会话密钥；
- 客户端拿着 TGT 向 TGS 申请目标服务的票据，TGS 校验通过后签发服务票据（Service Ticket）；
- 客户端把服务票据连同认证符交给目标服务器，服务器解密校验通过后放行，可选地回送确认信息完成双向认证。
拿到 TGT 后，用户在有效期内访问多个服务都不必重复输密码，这就是单点登录能力的来源。TGT 有生命周期限制，常见配置在 10 小时上下，到期可续期或重新认证。
# 客户端获取与查看票据
kinit hadoopuser@EXAMPLE.COM # 输入密码，换取 TGT
klist # 查看当前持有的票据与有效期
# 服务端注册主体并导出 keytab（Hadoop 场景）
kadmin.local -q "addprinc -randkey hdfs/node1.example.com@EXAMPLE.COM"
kadmin.local -q "xst -k /etc/security/keytabs/hdfs.keytab hdfs/node1.example.com@EXAMPLE.COM"这套命令对应的是”用户换 TGT、服务用 keytab”两条凭据路径，keytab 文件相当于服务的长期密钥，权限要收紧到服务账号可读。
三种认证方案横向对比
选型前先把三种常见方案放在同一张表里看。Kerberos 靠对称加密与可信第三方，简单密码认证靠口令本身，JWT 靠签名令牌，三者的安全边界完全不同：
| 维度 | Kerberos | 简单密码认证 | JWT/Token |
|---|---|---|---|
| 凭据形态 | 加密票据（二进制结构） | 明文口令 | 签名令牌（三段式字符串） |
| 密码是否上网络 | 不传输 | 每次认证传输或不重传但易被重放 | 不传输，传令牌 |
| 双向认证 | 原生支持 | 通常只单向 | 需额外机制 |
| 单点登录 | 域内天然支持 | 不支持 | 可配合 SSO 实现 |
| 部署复杂度 | 高（KDC、SPN、时间同步） | 低 | 中（签发与校验体系） |
| 适用网络 | 内网可信环境 | 局部小系统 | 互联网、跨域、移动端 |
表格之外的几个判断点同样关键：Kerberos 要求所有参与者与 KDC 网络可达且时钟同步，时间偏差容忍通常在 5 分钟左右，时钟漂移是线上故障的高发原因；JWT 无状态、自包含，服务端不需要集中存储会话，代价是签发后的令牌难以主动撤销，通常要靠短有效期加刷新机制兜底；简单密码认证实现成本低，但抗重放与抗窃听能力弱，生产系统一般只作为其他方案的底层凭据来源。
TGT 与服务票据的区别
Kerberos 里的两类票据经常被混为一谈，其实分工明确。TGT 是”入场凭证”，服务票据才是”某个具体服务的门票”，前者只交给 TGS 看，后者交给真正的业务服务：
| 对比项 | TGT（票据许可票据） | 服务票据（Service Ticket） |
|---|---|---|
| 签发方 | AS 认证服务器 | TGS 票据授权服务器 |
| 加密密钥 | KDC/TGS 的密钥 | 目标服务的密钥 |
| 使用对象 | 只提交给 TGS | 提交给目标业务服务 |
| 作用 | 换取各类服务票据，免重复认证 | 获取单个服务的访问授权 |
这样设计的直接收益是：用户密码只在最初认证环节派生密钥使用，后续所有请求都靠票据与会话密钥完成，泄露面被大幅压缩。
按场景选方案，别一刀切
三类典型场景对应的选型路径比较固定：
| 场景 | 推荐方案 | 理由 |
|---|---|---|
| Windows 域 / 企业内网 | Kerberos | AD 域控制器即 KDC，桌面到服务器的集成认证开箱即用 |
| Hadoop / 大数据集群 | Kerberos | 各组件共享同一 KDC 信任体系，服务间互认靠 principal 与 keytab |
| 互联网 Web 与开放 API | JWT/Token | 跨网络可达性好，无状态扩展，移动端友好 |
| 内部小工具、demo | 简单密码认证 | 成本低，风险面可控 |
实际企业里两套方案往往并存：域内机器走 Kerberos，对外应用在边界处通过 SAML 或 OIDC 与之桥接。落地时重点盯三件事——用 NTP 保证全网时钟同步、确保服务 principal（SPN）注册唯一不冲突、keytab 文件定期轮换并限制读取权限。做到这三点，Kerberos 服务的运维负担基本可控。
常见问题（FAQ）
Q1：Kerberos 和 JWT 到底怎么选？
内网域环境、组件互认选 Kerberos；互联网应用、API 与移动端选 JWT，二者常并存。
Q2：kinit 认证失败最常见的原因是什么？
时钟不同步。先核对客户端与 KDC 的时间偏差，再检查密码、网络可达性与 principal 拼写。
Q3：TGT 过期后必须重新输密码吗？
不一定。票据在可续期窗口内可用 kinit -R 续期，长期任务建议用 keytab 免密认证。
