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 代理拓扑与推荐配置组合。

相关推荐
用户962377954481 天前
VulnHub DC-3 靶机渗透测试笔记
安全
叶落阁主2 天前
Tailscale 完全指南:从入门到私有 DERP 部署
运维·安全·远程工作
用户962377954484 天前
DVWA 靶场实验报告 (High Level)
安全
数据智能老司机5 天前
用于进攻性网络安全的智能体 AI——在 n8n 中构建你的第一个 AI 工作流
人工智能·安全·agent
数据智能老司机5 天前
用于进攻性网络安全的智能体 AI——智能体 AI 入门
人工智能·安全·agent
用户962377954485 天前
DVWA 靶场实验报告 (Medium Level)
安全
red1giant_star5 天前
S2-067 漏洞复现:Struts2 S2-067 文件上传路径穿越漏洞
安全
用户962377954485 天前
DVWA Weak Session IDs High 的 Cookie dvwaSession 为什么刷新不出来?
安全
大大大大晴天5 天前
Flink生产问题排障-HBase NotServingRegionException
flink·hbase
大大大大晴天6 天前
Flink生产问题排障-Kryo serializer scala extensions are not available
大数据·flink