Kerberos凭据生命周期由ticket_lifetime和renewable_lifetime等参数协同控制，需平衡安全与业务连续性：ticket_lifetime建议设为≥任务最长执行时间+缓冲（如12h），renewable_lifetime建议设为7d，并确保启用renewable=true及客户端主动续期。
kerberos 凭据生命周期不是固定不变的，而是由一组可配置的时间策略协同控制，核心在于平衡安全边界与业务连续性。关键不在于“设多长”，而在于让票据既能支撑真实业务时长，又不超出最小必要权限窗口。
ticket_lifetime 决定单次票据可用时长
这是 TGT 或服务票据从签发起的有效期，默认常为 10 小时。若系统中存在运行超 8 小时的 ETL 任务或 BI 分析会话，该值必须 ≥ 任务最长执行时间 + 缓冲（建议至少设为 12 小时）。低于实际需求会导致任务中途因 krb5krb_err_expired 中断；过高则扩大攻击窗口。它直接写在 /etc/krb5.conf 的 [libdefaults] 段中，单位支持 h（如 12h）或秒（如 43200）。
renewable_lifetime 控制凭据可续期总时长
该参数定义用户在不输密码的前提下，最多能将票据“延长”多久。例如设为 7d，配合 ticket_lifetime=12h，意味着用户登录一次后，7 天内每天可自动续期一次，维持有效票据链。它必须 ≤ KDC 策略允许的最大续期时限（max renew time），否则续期请求会被拒绝。启用前需确认 renewable = true，否则续期功能不生效。
客户端需主动触发刷新，而非完全依赖自动机制
Kerberos 不会后台静默续期。典型做法是：
- 在任务脚本开头调用
kinit -R（续期当前票据）或kinit -k -t keytab（用密钥表重获票据） - 对长期运行进程（如 Flink 作业、调度 Agent），每 8–10 小时安排一次
kinit -R定时任务 - 应用层捕获
GSSException或KrbException中的过期错误码，在异常处理分支中执行票据刷新
服务端也要适配票据时效逻辑
微服务或 Hadoop 组件不能假设票据永不过期：
- REST/gRPC 客户端应实现“401 → 刷新票据 → 重试请求”闭环
- Spark/YARN 应用需在
spark.kerberos.renewal.interval等参数中显式配置刷新节奏 - 日志中持续出现
401 Unauthorized或Cannot authenticate using GSS，往往是服务端未集成续期逻辑的明确信号
不复杂但容易忽略。
