EKS Fargate下如何实现生产级Pod间及ALB到Pod流量加密

结论先行：符合生产部署标准的全链路加密方案是完全可落地的，不需要依赖对Fargate兼容性差的传统服务网格版本，也不需要手动维护证书的临时测试方案。

ALB到Pod链路的单向TLS加密 #

这部分链路不需要引入任何第三方组件，用AWS原生的Load Balancer Controller即可实现，已经是大量生产环境的通用实践：

• 配置逻辑：后端Pod只暴露HTTPS服务端口，在Ingress配置中将目标组协议设置为HTTPS，对应健康检查协议也同步设置为HTTPS，后端服务的证书统一托管在ACM，ALB会自动完成证书校验后转发加密流量
• 生产级特性：证书支持自动续期轮换，不需要手动登录Pod修改配置；安全组层面只放通ALB所属安全组到Pod HTTPS端口的访问权限，直接阻断所有到Pod明文端口的外部访问
• 注意事项：不要使用自签名证书配置后端HTTPS，避免ALB证书校验失败导致健康检查异常，证书统一通过ACM签发和管理即可。

Pod间互访的mTLS加密 #

目前有两类成熟的生产级方案，可根据团队技术栈选择：

方案1：适配Fargate权限模型的服务网格方案 #

之前Istio、Linkerd不支持Fargate的核心原因是传统sidecar需要NET_ADMIN/NET_RAW特权做iptables流量拦截，而Fargate默认禁止这类高权限。目前AWS App Mesh的Envoy sidecar已经支持用户态流量重定向模式，不需要任何特权权能即可运行，完全兼容Fargate的安全约束：

• 证书管理全托管：对接ACM Private CA自动为每个工作负载签发短周期mTLS证书，自动完成轮换，不需要手动分发证书、也不需要手动把CA根证书导入应用信任存储
• 能力完整：支持服务间细粒度授权规则、流量可观测性、流量治理等全量服务网格能力，完全满足Pod间mTLS加密的核心需求
• 兼容性：不需要修改业务代码，只需要在Pod注入时添加Envoy sidecar配置即可上线。

方案2：无Sidecar的应用层mTLS方案 #

如果团队不想引入服务网格的运维复杂度，且业务服务本身基于原生支持mTLS的框架（Spring Boot、gRPC、Go Micro等）开发，可以选择轻量的证书自动分发方案：

• 核心逻辑：通过cert-manager对接Kubernetes CSR API和ACM Private CA，为每个服务自动签发唯一的工作负载证书，证书通过Kubernetes Secret自动挂载到Pod，通过环境变量把证书、CA根证书路径注入业务应用，由应用本身完成mTLS握手和校验
• 生产级特性：证书自动轮换，不需要人工干预；配合Kubernetes Network Policy阻断Pod间明文端口的访问，从网络层强制所有互访走加密通道
• 适用场景：服务规模在50个以内、没有复杂流量治理需求的团队，运维成本远低于服务网格方案。

不推荐的非生产方案 #

手动为每个Pod部署Nginx sidecar、手动分发自签名证书、手动更新应用信任存储的临时方案，存在证书轮换成本极高、无集中权限管控、故障排查链路长的问题，完全达不到生产环境SLA要求，不建议在正式环境使用。

落地校验要点 #

• 上线前通过流量抓包验证ALB到Pod、Pod到Pod的流量是否为密文，确认没有明文流量泄露
• 所有证书有效期建议设置为7天以内，通过托管CA自动续期，避免证书过期导致的业务中断
• 配置默认拒绝的Network Policy，仅放通业务需要的加密端口访问，从底层阻断非加密流量的通信可能

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