Flink Kerberos 安全接入整体机制、三大安全模块、Standalone/K8s/YARN 部署与 Token 续期策略

1、目标：Flink 为什么要做 Kerberos？

Flink Kerberos 安全基础设施的核心目标有三类：

作业通过 connector 安全访问数据源（典型 Kafka）
认证到 ZooKeeper（如果 ZooKeeper 启用了 SASL）
认证到 Hadoop 组件（HDFS、HBase、YARN 等）

生产里的流式作业往往跑"天/周/月"。因此必须确保 作业生命周期内始终能认证成功 。在这点上，Keytab 是首选：因为 keytab 在这个时间尺度上不会过期；而 credential cache（kinit 生成的缓存）会过期，维护成本更高；delegation token 也有生命周期与续期逻辑。

2、凭证方式怎么选：Keytab vs kinit 缓存 vs Delegation Tokens

Flink 当前支持三种 Kerberos 凭证来源（集群级共享）：

Keytab（推荐）
- 适合长期作业
- Flink 组件可自动续 TGT（更省心）
Credential cache（kinit 生成）
- 可以不用 keytab，但缓存有过期时间
- 缓存更新完全由用户负责（容易踩坑）
- 需要确保缓存文件在执行认证的节点/容器可用
Hadoop Delegation Tokens
- Flink 1.17 起加入（实验性）
- 对 Hadoop 服务（HDFS/HBase）可获取 token 让非本地进程访问
- 文档提示：用户提供的 tokens 不会自动续期，且可能被 Flink 覆盖（运维上要谨慎）

重要限制：一个 Flink 集群内所有作业共享同一套 Kerberos 凭证配置 。

如果你想让某个作业用另一套 keytab，正确方式不是"按 job 配"，而是 起一个新 Flink 集群（K8s/YARN 下多集群并存很常见）。

3、Flink Security 的内部架构：三大 Security Module

Flink 通过在启动时安装"安全模块"（org.apache.flink.runtime.security.modules.SecurityModule）来把 Kerberos 能力注入到进程中。你文档里主要讲了三个模块：

3.1 Hadoop Security Module（UGI）

使用 Hadoop 的 UserGroupInformation (UGI) 建立 进程级 login user
该 login user 用于与 Hadoop 交互：HDFS、HBase、YARN 等

它的登录优先级顺序（非常关键）：

当 hadoop.security.authentication=kerberos 时：

如果配置了 security.kerberos.login.keytab + security.kerberos.login.principal → keytab 登录
否则如果 security.kerberos.login.use-ticket-cache=true → 使用 credential cache 登录
其他情况 → 使用启动 Flink 的 OS 账号身份（不具备 Kerberos 票据）

3.2 JAAS Security Module（动态 JAAS）

给 ZooKeeper、Kafka 以及任何依赖 JAAS 的组件提供动态 JAAS 配置
使这些组件能复用 Flink 配置的 Kerberos 凭证

注意：如果用户提供了静态 JAAS 文件（JVM 标准方式），静态配置会覆盖动态配置 。这在排障时很常见：你以为 Flink 的动态 JAAS 生效了，其实被 java.security.auth.login.config 指向的文件覆盖了。

3.3 ZooKeeper Security Module

配置 ZooKeeper 的进程级安全参数：
- service name（默认 zookeeper）
- JAAS login context（默认 Client）

对应配置项通常是：

zookeeper.sasl.service-name
zookeeper.sasl.login-context-name

4、部署模式差异：Standalone vs Native K8s vs YARN

4.1 Standalone（裸机/静态集群）

步骤是"每台机器都得有材料"：

在所有集群节点的 flink-conf.yaml 添加安全配置
确保 keytab 文件在所有节点上都存在，且路径与 security.kerberos.login.keytab 一致
正常启动 Flink 集群

要点：Standalone 没有"自动分发"，所以 keytab/krb5.conf 的分发与权限要你自己保证。

4.2 Native Kubernetes & YARN（客户端提交部署）

步骤是"客户端给材料，Flink 帮你带进容器"：

在客户端侧准备好 flink-conf.yaml 的安全配置
keytab 在客户端节点存在，路径与 security.kerberos.login.keytab 一致
提交部署后，keytab 会从客户端自动拷贝到 Flink 容器/pod

此外还需要 Kerberos 配置文件 krb5.conf：

可以使用集群环境自带的
或由 Flink 上传：配置 security.kerberos.krb5-conf.path，Flink 会把这个文件拷进 containers/pods
这对 K8s/YARN 很关键，因为容器里看不到宿主机的 krb5.conf

5、仅使用 kinit 缓存：能跑，但维护成本高

使用 credential cache 前需要知道：

credential cache 类型很多，常见是 FILE（需要保证缓存文件在认证发生的节点可读）
credential cache 一般由 kinit 生成
与 keytab 最大区别：缓存会过期，保持更新是用户责任
可以不带 keytab 也跑 Kerberos 集群，但要把缓存"铺到"认证发生的地方（多节点/多容器下非常麻烦）

因此：除非你们安全策略禁止 keytab，或只是短期实验，否则不建议把生产流式作业压在 credential cache 上。

6、长跑作业最关键：TGT Renewal（票据续期）

原则：

每个使用 Kerberos 的组件都要自己负责 TGT 的续期
当提供 keytab 时，组件会自动续 TGT
当使用 credential cache 时，续期由用户负责（最常见的生产故障源）

所以生产上最稳的组合仍然是：keytab + principal + 自动 relogin （后面 SSL 页也给了 security.kerberos.relogin.period 这种配置项）。

7、Delegation Tokens：Hadoop 侧的"替身凭证"

Flink 1.17 引入 delegation token（实验性）。作用是：当非本地进程要访问 Hadoop 服务时，用 token 代替 Kerberos 交互，减少频繁的 Kerberos 往返。

Flink 可以为这些服务获取 token：

HDFS 和其他 Hadoop FS
HBase（要求 classpath 有 HBase，且 hbase.security.authentication=kerberos）

获取 token 的目录范围包括：

Hadoop 默认 filesystem
security.kerberos.access.hadoopFileSystems 指定的文件系统列表
YARN staging 目录

另外还支持自定义 token provider（SPI）：

实现 org.apache.flink.runtime.security.token.DelegationTokenProvider
通过 META-INF/services 配置被 ServiceLoader 发现

运维提醒：文档明确提到"用户提供的 tokens 不会续期且可能被 Flink 覆盖"，所以如果你们依赖外部系统下发 token，需要非常谨慎地定义边界和刷新策略。

8、一份"最小可用"的 Kerberos 配置骨架（按你文档语义整理）

下面不是完整参数表，而是你落地时一定会用到的骨架（keytab 路线）：

yaml 复制代码

# Kerberos 基础材料
security.kerberos.login.principal: flink@YOUR.REALM
security.kerberos.login.keytab: /path/to/flink.keytab
security.kerberos.krb5-conf.path: /path/to/krb5.conf   # K8s/YARN 场景常用
security.kerberos.login.use-ticket-cache: false

# 需要让 Kerberos 凭证对哪些 JAAS 上下文可见（示例）
security.kerberos.login.contexts: Client,KafkaClient

# 若访问多个 Kerberos 保护的 Hadoop FS
security.kerberos.access.hadoopFileSystems: hdfs://nn1:8020;hdfs://nn2:8020

# ZooKeeper SASL（如需要）
zookeeper.sasl.service-name: zookeeper
zookeeper.sasl.login-context-name: Client

你们真实环境里 principal、realm、keytab 路径、HDFS namenode 地址、KafkaClient context 名称都会不同，但结构就是这样。