Flink SSL/TLS 安全加固内网 mTLS、REST HTTPS、证书 Pinning 与部署要点

1.1 Internal Connectivity(内部连接)

内部连接指 Flink 进程之间的通信,用户不会直接连这些端口,主要包括:

  • 控制面:JobManager/TaskManager/Dispatcher/ResourceManager 之间的 RPC(Pekko-based)
  • 数据面:TaskManager ↔ TaskManager 的网络数据交换(shuffle/broadcast/redistribution)
  • Blob Service:作业 jar、依赖、工件等的分发

内部连接的推荐安全模型是 mTLS(双向认证 + 加密):连接两端都要出示证书,互相校验。常见做法是给该 Flink 部署准备一套"专用证书"(自签或内部 CA 签发),把它当作"共享秘密"用于内部互信。

关键点:

  • 内部 mTLS 用专用 CA/证书时,安全边界清晰,证书不需要给其他外部系统使用
  • 由于内部连接是共享证书的双向认证,Flink 可以跳过 hostname 校验,从而更适配容器/动态主机名场景(文档也强调这点让容器化更容易)

1.2 External / REST Connectivity(外部 REST/WebUI)

外部连接是对外暴露的 HTTP/REST 端点,用于:

  • Web UI
  • Flink CLI 与 JobManager/Dispatcher 的 REST 命令交互
  • Session 集群提交作业、运行中作业的查询与修改

REST 端点可以启用 TLS(HTTPS),但默认只加密不认证客户端:也就是服务端会接受任意客户端的 HTTPS 连接(只要能握手成功)。

如果你需要对 REST 访问做认证,有两种路线:

  • 简单 mutual auth(双向 TLS)可以通过配置开启
  • 更推荐:把 Flink REST 绑定到 loopback/pod 内网,再用 sidecar 代理做认证与转发(如 Envoy、NGINX + MOD_AUTH)。原因是代理支持更丰富的认证方式,更好融入现有基础设施

2. 开关总览:分别控制内部与 REST

你可以分别开启内部与外部 TLS:

  • security.ssl.internal.enabled: true 启用内部所有连接的 SSL
  • security.ssl.rest.enabled: true 启用 REST/外部端点的 SSL

兼容选项:

  • security.ssl.enabled 仍存在,等同于同时开启 internal + rest(为了向后兼容)

内部链路还可以按类型单独关闭(在 security.ssl.internal.enabled=true 的前提下):

  • taskmanager.data.ssl.enabled: false 关闭 TM 数据面加密
  • blob.service.ssl.enabled: false 关闭 BLOB 传输加密
  • pekko.ssl.enabled: false 关闭 RPC SSL

生产建议:除非有明确的性能/排障需求,否则内部链路尽量不要拆开关,减少"局部明文"带来的误判与合规风险。

3. Keystore/Truststore:内部 mTLS 与 REST HTTPS 的典型差异

3.1 基本概念

  • Keystore:包含证书(公钥)+ 私钥
  • Truststore:包含"信任的证书或 CA"

原则:truststore 必须能信任对端出示的证书(或信任签发该证书的 CA)。

3.2 内部 mTLS(最常见:同一套文件同时做 keystore/truststore)

内部通信因为是双向认证,通常采用"专用证书当共享秘密"的模式:

yaml 复制代码
security.ssl.internal.enabled: true
security.ssl.internal.keystore: /path/to/internal.keystore
security.ssl.internal.truststore: /path/to/internal.keystore
security.ssl.internal.keystore-password: internal_store_password
security.ssl.internal.truststore-password: internal_store_password
security.ssl.internal.key-password: internal_store_password

当使用自签证书时,keystore 与 truststore 甚至可以是同一个文件(文档给的就是这种最简单形态)。

如果内部证书不是自签,而是由企业统一 CA 签发:

truststore 往往需要导入企业 CA 公钥才能通过握手。这里有一个很重要的风险:truststore 会因此信任"该企业 CA 签发的所有证书"。

为了避免"过度信任",Flink 提供了证书 Pinning:

  • security.ssl.internal.cert.fingerprint: <sha1 fingerprint>
    用指纹把内部通信锁定为"只信任这一张部署证书",防止被同 CA 的其他证书冒用。

3.3 REST HTTPS(默认:服务端用 keystore,客户端用 truststore)

REST 模式下:

  • 服务端(JM/Dispatcher REST)用 keystore 提供证书
  • REST 客户端(包括 Flink CLI)用 truststore 去信任服务端证书

相关配置:

yaml 复制代码
security.ssl.rest.enabled: true
security.ssl.rest.keystore: /path/to/rest.keystore
security.ssl.rest.truststore: /path/to/rest.truststore
security.ssl.rest.keystore-password: rest_keystore_password
security.ssl.rest.truststore-password: rest_truststore_password
security.ssl.rest.key-password: rest_keystore_password

# 是否启用 REST mutual TLS
security.ssl.rest.authentication-enabled: false

如果 REST 证书来自"正规 CA 链",truststore 应包含该 CA 链根证书。

如果 REST 证书不是自签而是企业/公网 CA 签发,同样建议使用 Pinning(文档提供):

  • security.ssl.rest.cert.fingerprint: <sha1 fingerprint>

此外,REST 对外暴露时,证书 CN/SAN 应匹配主机名与 IP(尤其是 SAN)。

4. 一套可直接复用的 keytool 生成示例

4.1 内部通信:生成一张专用自签证书(PKCS12)

bash 复制代码
keytool -genkeypair \
  -alias flink.internal \
  -keystore internal.keystore \
  -dname "CN=flink.internal" \
  -storepass internal_store_password \
  -keyalg RSA \
  -keysize 4096 \
  -storetype PKCS12

然后按上面的 internal 配置引用它,同时作为 truststore。

4.2 REST:简单自签证书(带 SAN)+ truststore

假设 REST 的主机为 myhost.company.org,IP 为 10.0.2.15:

bash 复制代码
keytool -genkeypair \
  -alias flink.rest \
  -keystore rest.keystore \
  -dname "CN=myhost.company.org" \
  -ext "SAN=dns:myhost.company.org,ip:10.0.2.15" \
  -storepass rest_keystore_password \
  -keyalg RSA \
  -keysize 4096 \
  -storetype PKCS12

keytool -exportcert \
  -keystore rest.keystore \
  -alias flink.rest \
  -storepass rest_keystore_password \
  -file flink.cer

keytool -importcert \
  -keystore rest.truststore \
  -alias flink.rest \
  -storepass rest_truststore_password \
  -file flink.cer \
  -noprompt

4.3 curl 访问 REST:keystore 转 PEM

bash 复制代码
openssl pkcs12 -passin pass:rest_keystore_password -in rest.keystore -out rest.pem -nodes

# 单向 TLS
curl --cacert rest.pem flink_url

# 如果启用了 REST mutual TLS
curl --cacert rest.pem --cert rest.pem flink_url

5. Cipher Suites 与协议/引擎:安全与兼容的取舍点

5.1 推荐更强的 cipher suites

RFC 7525 推荐更强的套件,Flink 默认为了兼容性可能更弱。你可以显式配置:

yaml 复制代码
security.ssl.algorithms: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_DHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

如果你的运行环境不支持这些套件,现象通常是 Flink 进程之间"握手失败、互相连不上"。

5.2 SSL Provider:JDK vs OPENSSL

yaml 复制代码
security.ssl.provider: JDK
security.ssl.protocol: TLSv1.2

也可以切换到 OPENSSL(基于 netty-tcnative),分动态链接与静态链接两种形态。动态链接需要把 opt/flink-shaded-netty-tcnative-dynamic-*.jar 拷到 lib/;静态链接需要自行构建(文档里给了 flink-shaded 的构建方式)。

6. 部署与运维要点:Standalone / Container / YARN

6.1 证书文件如何分发

  • Standalone:拷到每个节点或挂载共享目录
  • 容器:把 keystore/truststore 放进镜像或挂载到 Pod
  • YARN:部署阶段可自动分发;也可以用 -yt ship 文件目录

6.2 YARN 场景的特殊点:YARN Proxy 与 HTTPS

YARN 上通过 Tracking URL 访问 Flink Web Dashboard 时,会走 YARN Proxy。要让 YARN Proxy 能访问 Flink 的 HTTPS,需要让 Proxy 节点信任 Flink 的证书(把自定义 CA 导入 Proxy 节点 Java 默认 truststore)。

6.3 REST 认证的推荐姿势:代理前置

即使 REST 开了 HTTPS,如果你要做更丰富的认证/授权(OIDC、LDAP、JWT、IP 白名单、多租户隔离),建议:

  • Flink REST 只绑定 loopback/pod 内网
  • 由 sidecar 或 Ingress/网关负责对外 TLS 终止 + 认证 + 转发

7. 一份"最小可用"配置模板

内部 mTLS + REST HTTPS(不启用 REST 双向认证):

yaml 复制代码
security.ssl.internal.enabled: true
security.ssl.internal.keystore: /path/to/internal.keystore
security.ssl.internal.truststore: /path/to/internal.keystore
security.ssl.internal.keystore-password: internal_store_password
security.ssl.internal.truststore-password: internal_store_password
security.ssl.internal.key-password: internal_store_password

security.ssl.rest.enabled: true
security.ssl.rest.keystore: /path/to/rest.keystore
security.ssl.rest.truststore: /path/to/rest.truststore
security.ssl.rest.keystore-password: rest_keystore_password
security.ssl.rest.truststore-password: rest_truststore_password
security.ssl.rest.key-password: rest_keystore_password
security.ssl.rest.authentication-enabled: false

如果内部证书是企业 CA 签发而不是自签,建议再加:

yaml 复制代码
security.ssl.internal.cert.fingerprint: 00:00:...

如果 REST 证书也是企业/公网 CA,且你要做 Pinning:

yaml 复制代码
security.ssl.rest.cert.fingerprint: 00:00:...

如果你希望我把这部分继续扩展成"可直接落地的生产方案",你告诉我两点就行:你们是 Standalone/YARN/K8s 哪种部署,以及 high-availability.storageDir/checkpoint 在用什么存储(HDFS/S3/OSS/ABFS)。我可以给你一份更贴合场景的证书分发、REST 代理拓扑与推荐配置组合。

相关推荐
飞飞传输8 分钟前
业务系统文件安全检测怎么做?生物医药企业选型与建设指南
大数据·运维·安全
starzy199029 分钟前
Flink JobManager启动流程源码深度剖析:从ClusterEntrypoint到JobMaster启动的完整链路
大数据·flink
迪康软件zz1 小时前
终端审批体系怎么搭?从模板配置到业务连续性
运维·安全·自动化运维
Hum8le1 小时前
CTF题目《easy_web》(安洵杯 2019 变种 Web)
前端·安全·web安全
用户3610588626121 小时前
Flink Time 之 WaterMark 水位线原理剖析:从生成机制到传播触发与调优实战
大数据·flink
HackTwoHub2 小时前
DeepSeek Harness 红队破甲插件|适配 SRC 挖掘场景,区分平台拦截与模型原生输出,用于大模型安全边界合规测评研究
安全·web安全·网络安全·系统安全·密码学·网络攻击模型·安全架构
梦帮科技2 小时前
【3.0】上线与运维:节点监控、水龙头、区块浏览器与安全清单
运维·安全·web安全·金融·区块链·密码学·安全架构
花 满 楼2 小时前
HSM自学之路——阶段5安全启动专题与实践
安全·嵌入式·汽车电子·hsm·安全启动
三8443 小时前
Fastjson 漏洞· 06 · 防御、审计与检测
安全·web安全·fastjson
qetfw3 小时前
Debian SSH 安全配置:端口、来源限制与免密登录
linux·安全·debian·ssh