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 凭证来源（集群级共享）：

1. Keytab（推荐）

   • 适合长期作业
   • Flink 组件可自动续 TGT（更省心）

2. Credential cache（kinit 生成）

   • 可以不用 keytab，但缓存有过期时间
   • 缓存更新完全由用户负责（容易踩坑）
   • 需要确保缓存文件在执行认证的节点/容器可用

3. 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时：

1. 如果配置了security.kerberos.login.keytab+security.kerberos.login.principal→keytab 登录
2. 否则如果security.kerberos.login.use-ticket-cache=true→使用 credential cache 登录
3. 其他情况 → 使用启动 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（裸机/静态集群）

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

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

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

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

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

1. 在客户端侧准备好flink-conf.yaml的安全配置
2. keytab 在客户端节点存在，路径与security.kerberos.login.keytab一致
3. 提交部署后，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 路线）：

# Kerberos 基础材料security.kerberos.login.principal:flink@YOUR.REALMsecurity.kerberos.login.keytab:/path/to/flink.keytabsecurity.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 FSsecurity.kerberos.access.hadoopFileSystems:hdfs://nn1:8020;hdfs://nn2:8020# ZooKeeper SASL（如需要）zookeeper.sasl.service-name:zookeeperzookeeper.sasl.login-context-name:Client

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