AWS EKS中端到端TLS的最佳实现方案及步骤咨询

你好！结合你现有的EKS集群配置（已经部署了AWS Load Balancer Controller和Cert-Manager），你提到的两种思路都是可行的，但各有适用场景，我来帮你拆解分析，并给出具体的实施建议：

方案一：保留现有NLB，实现域名解析+端到端TLS到Pod #

这个方案的核心是复用你当前运行正常的NLB，通过Route53绑定自定义域名，同时确保NLB到Pod的流量依然保持TLS加密，实现真正的端到端加密链路。

可行性分析 #

完全可行！NLB支持两种模式适配端到端TLS：

• TCP透传模式：NLB仅做四层转发，不处理TLS终止，直接把客户端的TLS流量转发到Pod的8443端口（由Pod自身完成TLS终止）
• NLB TLS终止+Pod侧TLS：NLB先用ACM证书终止客户端的TLS连接，再发起新的TLS连接转发到Pod的8443端口（双重加密，适合对中间链路安全要求极高的场景）

具体实施步骤 #

1. 绑定自定义域名到NLB

   • 在Route53中创建你的自定义域名（比如my-app.example.com）的A记录，类型选择Alias，指向现有NLB的DNS名称（可通过kubectl get service my-service -o jsonpath='{.status.loadBalancer.ingress[0].hostname}'命令获取）

2. 配置端到端TLS链路
   如果你选择TCP透传模式（最直接，复用现有Service配置）：

   • 确保Pod已配置TLS证书：可以用Cert-Manager给Pod签发证书，挂载到容器中，让应用在8443端口启用TLS服务
   • 现有Service配置已经是TCP 443转发到Pod 8443，无需修改Service，只需验证Pod侧TLS服务正常运行即可

   如果你选择NLB TLS终止+Pod侧TLS（增强中间链路安全）：

   • 用Cert-Manager在AWS ACM中签发自定义域名的证书（或直接在ACM手动申请）
   • 修改Service的annotations，添加NLB的TLS配置：

     service.beta.kubernetes.io/aws-load-balancer-ssl-cert: "arn:aws:acm:region:account-id:certificate/cert-id"
     service.beta.kubernetes.io/aws-load-balancer-ssl-ports: "443"
     

   • 确保Pod侧依然运行TLS服务，NLB会在终止客户端TLS后，以TLS方式转发流量到Pod的8443端口（需保证Pod的证书被NLB信任，或配置NLB信任Pod证书的CA）

方案二：改用Ingress+ALB实现端到端TLS #

这个方案通过Ingress资源配合AWS Load Balancer Controller创建ALB，用ACM证书处理客户端TLS，再由Ingress转发加密流量到Pod的TLS端口，适合需要七层路由能力的场景。

可行性分析 #

同样可行！ALB作为七层负载均衡，能提供路径转发、主机头匹配等丰富的路由规则，还可集成WAF等高级特性。但需要你调整现有Service的类型。

具体实施步骤 #

1. 修改现有Service类型
   将my-service的类型从LoadBalancer改为ClusterIP（比NodePort更安全，避免节点端口暴露），修改后的Service spec片段：

   spec:
     type: ClusterIP
     # 移除allocateLoadBalancerNodePorts、loadBalancerSourceRanges等LB相关配置
     ports:
     - port: 443
       protocol: TCP
       targetPort: 8443
   

2. 创建Ingress资源
   配置Ingress绑定自定义域名，指定ACM证书，转发流量到Pod的TLS端口：

   apiVersion: networking.k8s.io/v1
   kind: Ingress
   metadata:
     name: my-app-ingress
     namespace: default-namespace
     annotations:
       alb.ingress.kubernetes.io/scheme: internet-facing
       alb.ingress.kubernetes.io/target-type: ip # 直接指向Pod IP，转发更高效
       alb.ingress.kubernetes.io/certificate-arn: "arn:aws:acm:region:account-id:certificate/cert-id"
       alb.ingress.kubernetes.io/listen-ports: '[{"HTTPS":443}]'
       alb.ingress.kubernetes.io/ssl-policy: ELBSecurityPolicy-TLS13-1-2-2021-06 # 可选，指定TLS版本
   spec:
     ingressClassName: alb # 对应AWS Load Balancer Controller的ingressClass
     rules:
     - host: my-app.example.com
       http:
         paths:
         - path: /
           pathType: Prefix
           backend:
             service:
               name: my-service
               port:
                 number: 443
     tls:
     - hosts:
       - my-app.example.com
       # 若使用ACM证书可留空；若使用集群内证书则填写Secret名称
       secretName: 
   

3. 绑定域名到ALB
   在Route53中创建my-app.example.com的Alias记录，指向Ingress创建的ALB的DNS名称（可通过kubectl get ingress my-app-ingress命令获取）

4. 验证Pod侧TLS服务
   确保Pod已配置好TLS证书，Ingress会将加密后的流量转发到Pod的8443端口，实现端到端加密。

方案选择建议 #

• 如果你不需要复杂的七层路由规则，只是想快速实现域名绑定和端到端TLS，推荐选择方案一，复用现有NLB，改动最小，运维成本低。
• 如果你未来需要路径转发、多域名路由等七层功能，或想利用ALB的WAF集成等高级特性，推荐选择方案二，虽然需要调整Service和新增Ingress，但扩展性更好。

另外，不管哪种方案，都可以用Cert-Manager自动化管理证书：

• 方案一中的NLB TLS终止证书，Cert-Manager可自动在ACM签发并更新Service的annotations
• Pod侧的证书，Cert-Manager可签发集群内Secret并挂载到Pod，实现证书自动轮转

备注：内容来源于stack exchange，提问作者unbox-us