在实时计算领域，Apache Flink 是当之无愧的流处理引擎之王。然而，生产环境的流式作业往往需要运行数天甚至数月，Kerberos 安全认证便成为不可回避的挑战。本文将深入剖析 Flink Kerberos 的整体机制、三大安全模块，并重点讲解在 容器化部署（Kubernetes、Docker）以及 YARN 环境下的最佳实践，助你轻松应对长期作业的票据续期问题。

Flink 为何需要 Kerberos？

Flink 引入 Kerberos 安全基础设施，核心目标在于解决三类认证需求：

  • 数据源安全访问：作业通过 connector 安全访问 Kafka 等外部系统
  • ZooKeeper 认证：当 ZooKeeper 启用 SASL 时，Flink 需认证连接
  • Hadoop 组件认证：包括 HDFS、HBase、YARN 等核心服务

生产中的流式作业通常以“天/周/月”为周期运行，因此必须确保作业在整个生命周期内始终能认证成功。在这方面，Keytab 是首选方案：keytab 在长时间尺度上不会过期，而 credential cache（由 kinit 生成）会过期，维护成本更高；delegation token 虽有生命周期，但可通过自动续期来应对。

凭证方式选择：Keytab vs kinit 缓存 vs Delegation Tokens

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

  • ✅ Keytab（推荐）：适合长期作业，Flink 组件可自动续 TGT，省心省力
  • ⚠️ Credential cache（kinit 生成）：可以不用 keytab，但缓存有过期时间，且更新完全由用户负责，容易踩坑
  • Hadoop Delegation Tokens：Flink 1.17 起加入（实验性），对 Hadoop 服务可获取 token，让非本地进程访问

重要限制：一个 Flink 集群内所有作业共享同一套 Kerberos 凭证配置。若想让某个作业用另一套 keytab，正确方式是起一个新 Flink 集群（在 K8s 或 YARN 下多集群并存很常见）。

️ Flink Security 内部架构：三大 Security Module

Flink 通过在启动时安装“安全模块”（org.apache.flink.runtime.security.modules.SecurityModule）来将 Kerberos 能力注入到进程中。主要包含三个模块：

3.1 Hadoop Security Module（UGI）

使用 Hadoop 的 UserGroupInformation (UGI) 建立进程级 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。

部署模式差异：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。

在 Kubernetes 环境 下，建议将 keytab 和 krb5.conf 作为 ConfigMap 或 Secret 挂载，避免文件分发问题。同时，Docker 容器 内部的 /etc/krb5.conf 需与外部保持一致，否则认证会失败。

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

使用 credential cache 前需要知道：credential cache 类型很多，常见是 FILE（需要保证缓存文件在认证发生的节点可读）。credential cache 一般由 kinit 生成。与 keytab 最大区别：缓存会过期，保持更新是用户责任。虽然可以不带 keytab 也跑 Kerberos 集群，但要把缓存“铺到”认证发生的地方（多节点/多容器下非常麻烦）。因此，除非安全策略禁止 keytab，或只是短期实验，否则不建议把生产流式作业压在 credential cache 上。

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

原则：每个使用 Kerberos 的组件都要自己负责 TGT 的续期。当提供 keytab 时，组件会自动续 TGT；当使用 credential cache 时，续期由用户负责（最常见的生产故障源）。所以生产上最稳的组合仍然是：keytab + principal + 自动 relogin（后面 SSL 页也给了 security.kerberos.relogin.period 这种配置项）。

[AFFILIATE_SLOT_1]

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，需要非常谨慎地定义边界和刷新策略。

一份“最小可用”的 Kerberos 配置骨架

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

# 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 名称都会不同，但结构就是这样。

[AFFILIATE_SLOT_2]

总结

Flink Kerberos 安全接入是生产环境流式作业的基石。通过理解三大安全模块（Hadoop UGI、动态 JAAS、ZooKeeper Security），掌握 Standalone、K8s、YARN 三种部署模式的差异，并合理选择凭证方式（推荐 keytab + 自动续期），即可构建稳定可靠的认证体系。在 容器化部署 场景下，善用 Flink 的自动分发能力，配合 K8s 的 ConfigMap/Secret 管理，能让 Kerberos 配置变得轻松可控。