EKS Fargate下HTTPS透传至Pod实现内部mTLS的配置问询

可行性结论 #

完全可行。集群内访问出现连接挂起的根因是默认K8s Ingress/云厂商负载均衡默认采用七层HTTP/HTTPS监听模式，会在负载均衡层终止TLS连接，不会把完整的TLS握手报文透传给后端应用，应用侧一直等待客户端的TLS握手请求，最终导致连接超时挂起。

不需要在负载均衡层配置任何证书ARN，只需要把监听模式改成四层TCP透传：

• 负载均衡侧创建TCP协议的监听，端口映射到应用的HTTPS服务端口（通常是443或自定义服务端口）
• 绑定的目标组也采用TCP协议，不要选择HTTP/HTTPS类型的目标组

这种模式下负载均衡只做报文转发，不解析、不终止TLS连接，所有SSL握手、mTLS证书校验逻辑全量由后端应用处理，完全匹配证书内置在应用中的诉求。

方案优缺点 #

• 优点
  • 完全复用应用侧已实现的SSL、mTLS逻辑，不需要在基础设施层重复维护证书、信任链，证书轮换仅需更新应用侧配置即可，无需调整负载均衡规则
  • 实现真正的端到端加密，流量从客户端到应用全程无TLS终止点，符合零信任安全要求
  • 私有CA信任规则完全由应用侧管控，不需要给负载均衡开放ACM Private CA的操作权限
• 缺点
  • 四层透传模式下无法使用负载均衡的七层能力，包括基于Host/路径的路由、七层WAF规则、HTTP头自动注入等，获取客户端真实IP需要额外开启TCP源地址透传配置
  • 所有TLS握手异常、非法证书请求都会直接透传到应用，会额外占用应用的连接资源
  • 流量发布粒度变粗，无法基于HTTP请求属性做细粒度的流量切分、蓝绿发布路由

可行性结论 #

技术上完全可实现，首先要纠正一个常见认知偏差：客户端校验服务端证书是客户端TLS栈的独立行为，和服务端Spring Security的X509认证逻辑没有强制绑定关系。

mTLS的双向校验是完全独立的两个流程：

1. 服务端校验客户端证书：由服务端SSL配置控制，通过在密钥库配置中开启needClientAuth: true，加载包含私有根CA的信任库实现
2. 客户端校验服务端证书：完全由客户端自身的TLS配置决定，服务端无法强制客户端必须校验自身证书，仅能决定是否向客户端返回自身的服务端证书

要实现开发环境无需配置SSL证书的诉求，不需要修改Spring Security的X509认证核心逻辑，只需要做环境配置隔离：

• 本地开发环境直接关闭应用SSL配置，以HTTP协议启动服务，Spring Security的X509认证过滤器会自动识别非HTTPS请求，跳过证书提取逻辑，不影响普通接口调试
• 生产环境通过配置开关打开SSL、加载PKCS12密钥库和信任库，强制开启mTLS校验

如果本地开发需要临时用HTTPS调试但不想配置正式服务端证书，只需要在调试用的客户端（Postman、测试代码等）中关闭服务端证书校验逻辑即可，服务端无需做任何适配。

方案优缺点 #

• 优点
  • 本地开发流程大幅简化，开发人员无需配置本地密钥库、JVM SSL参数，直接启动应用即可调试业务逻辑
  • 环境配置隔离性强，通过环境变量、配置文件区分多环境配置，不会出现本地证书路径错误、密码不匹配导致的启动失败问题
• 缺点
  • 本地环境完全关闭SSL的情况下，无法复现TLS握手、证书校验相关的异常，这类问题只能到测试/生产环境排查
  • 如果客户端跳过服务端证书校验的配置被误带到生产环境，会存在中间人攻击风险，必须通过配置管控严格隔离开发和生产的客户端配置
  • 本地调试mTLS握手相关逻辑时，仍然需要加载全套密钥库、信任库配置，无法完全跳过SSL相关设置

额外提示：配置四层TCP透传后，记得把负载均衡目标组的空闲超时时间和应用侧的连接超时配置（比如Spring Boot的server.tomcat.connection-timeout）对齐，避免长连接场景下负载均衡提前断连导致请求异常。

内容的提问来源于stack exchange，提问作者user3677636