ingress secure-backends_Ingress

ingress secure-backends_Ingress的核心作用，就是让Ingress控制器以后端HTTPS协议去访问Pod服务，解决Ingress与后端之间的加密通信与证书校验问题，开启后即告别502、证书报错和回环流量隐患。

这个配置项在Kubernetes中看似不起眼，却直接决定了Ingress到后端Service这条链路是否安全可控，很多人在Ingress层配好了TLS证书，却忽略了后端加密，结果流量在集群内部裸奔，或者因为证书自签导致健康检查失败，下面从原理、配置、场景差异和排错四个维度拆开讲。

加载中

k8s中ingress讲解，安装和使用，nginx-ingress和treafik-ingress

林时工Yeppy

2069152

原视频地址

ingress secure-backends是什么，后端通信的核心开关

Ingress作为集群流量的总入口，承担了两段加密职责：一是客户端到Ingress的HTTPS终结，二是Ingress转发到后端Pod的链路加密，传统认知里，大家默认集群内部网络是可信的，但在多租户环境、混合云架构、以及等保合规要求下，后端链路的加密和身份校验已成为硬性需求。

secure-backends这个参数最早出现在GCE Ingress的配置中，它的含义很直接：当设置为true时，Ingress控制器会使用HTTPS协议与后端Service通信，而不是默认的HTTP，开启后，Ingress会为每个后端节点创建基于HTTPS的健康检查,并用SSL证书完成握手。

这个开关解决了几类典型痛点：

• 后端服务本身强制开启TLS，比如通过Istio注入的Sidecar代理只接受mTLS流量
• 后端Pod使用自签证书，Ingress默认不校验证书来源，可能导致中间人风险
• 集群内部存在敏感数据，如支付回调、用户隐私信息，需要端到端加密
• 安全审计要求Ingress日志中不出现明文请求体

行业共识认为，在服务网格普及之前，secure-backends几乎是集群内后端加密的唯一标准方案，即便现在,它依然是Ingress配置项里入参频率最高的安全参数。

ingress secure-backends怎么配置，从声明到生效的全流程

配置方式取决于你用的Ingress控制器类型，以最常见的GCE Ingress为例,操作路径分为以下几步。

在Ingress资源中声明安全后端

GCE Ingress通过ingress.gcp.kubernetes.io/backend-protocol注解来控制后端协议，将其设置为HTTPS即可，等价于开启secure-backends，在GKE较新版本中,还可以直接在backendConfig中定义安全策略：

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: https-backend-config
spec:
  healthCheck:
    requestPath: /healthz
    type: HTTPS
  securityPolicy:
    ...

在Ingress的Service注解中引用这个BackendConfig：

apiVersion: v1
kind: Service
metadata:
  name: my-service
  annotations:
    cloud.google.com/backend-config: '{"default": "https-backend-config"}'
    cloud.google.com/neg: '{"ingress": true}'
spec:
  ports:
  - port: 443
    targetPort: 8443

Service的端口需要监听443,targetPort指向业务容器的HTTPS端口。

验证配置是否生效

配置完成后，等待Ingress后端同步，在GKE控制台的Ingress详情页，查看后端服务列表，确认协议列显示HTTPS，健康检查状态变为健康,或者通过命令行检查：

kubectl describe ingress my-ingress
gcloud compute backend-services list

如果显示protocol: HTTPS且healthStatus: HEALTHY，说明secure-backends已经生效。

一个常见的误解是：只要给Ingress配了TLS证书，后端就是加密的。Ingress证书只负责客户端到Ingress这一段，后端链路默认仍然走HTTP明文，这也是为什么很多安全扫描报告里会揪出”container-to-container traffic unencrypted”这类告警。

nginx ingress https后端配置的三种常见方式

如果你使用的是nginx ingress控制器，情况稍有不同，nginx ingress没有直接叫secure-backends的参数，但它提供了更灵活的nginx.ingress.kubernetes.io/backend-protocol注解，这个注解就扮演了secure-backends的角色。

显式指定后端协议

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: https-backend-ingress
  annotations:
    nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"
spec:
  tls:
  - hosts:
    - api.example.com
    secretName: ingress-tls-secret
  rules:
  - host: api.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: api-service
            port:
              number: 443

后端服务必须监听443端口，且Pod内的应用需要具备HTTPS服务能力，如果你的应用只能监听HTTP，需要在部署层面加一个Sidecar容器来终结TLS,或者让应用本身支持HTTPS。

配合Certificate注解使用自定义CA

当后端使用自签证书或私有CA签发的证书时，nginx ingress默认会跳过校验，这在安全上是有隐患的，可以通过关联Secret来指定CA证书,让nginx代理验证后端身份：

nginx.ingress.kubernetes.io/proxy-ssl-secret: "default/backend-ca-secret"
nginx.ingress.kubernetes.io/proxy-ssl-verify: "on"

这个组合让nginx在后端握手时校验证书链，从单向加密升级为双向可信。

全局默认开启HTTPS后端

如果你希望整个集群的所有Ingress默认用HTTPS访问后端，可以修改nginx ingress控制器的ConfigMap：

data:
  backend-protocol: "HTTPS"

这种方式适合后端服务已全面TLS化的场景，不过要小心，全局开启后如果某个后端不支持HTTPS，会导致503或502,建议先收敛后端能力再全局切换。

下表对比了gce ingress和nginx ingress在secure-backends概念上的差异：

配置secure-backends时容易踩的坑与排查思路

很多人在开启secure-backends后遇到服务突然不可用,原因通常集中在下面几个点。

坑一：健康检查失败导致后端服务被摘除

GCE Ingress开启HTTPS后，健康检查请求也会走HTTPS，如果你的健康检查路径返回的是HTTP重定向，或者后端应用的健康检查端点没有监听TLS端口,后端会被标记为不健康。

解决思路：确保健康检查端点和业务端口共用同一个HTTPS监听器,或者将健康检查的requestPath单独指向一个支持HTTPS的路径。

坑二：自签证书导致代理后端报错

nginx ingress在backend-protocol: HTTPS模式下，如果后端证书是自签的，且没有配置proxy-ssl-verify off或指定CA，日志里会报ssl_certificate相关错误，这里有个原则：生产环境建议配置proxy-ssl-secret明确信任链，而不是关闭校验。

坑三：nginx ingress与GCE ingress混用时端口不一致

有的集群同时部署了nginx ingress和GCE ingress，业务方容易搞混哪个控制器在处理流量，在排查时要先确认IngressClass的指向，再检查对应控制器的日志，通常GCE ingress的日志在Cloud Logging中，nginx ingress的日志在控制器Pod里。

常用的排查命令：

kubectl logs -n ingress-nginx deployment/ingress-nginx-controller --tail=200
kubectl get svc -A -o wide | grep <namespace>

坑四：后端只监听HTTP，强行切HTTPS导致502

这种场景在业务侧改造中最常见，如果业务应用没有能力提供TLS，盲目开启secure-backends会直接导致502，稳妥的做法是：先让业务容器同时监听80和443，或者用InitContainer做端口转发,再逐步下掉HTTP。

常见问题：ingress secure-backends相关咨询汇总

Q1：ingress secure-backends和tls证书配置有关系吗？
有关系但作用层次不同，TLS证书配置管的是客户端到Ingress这一段，secure-backends管的是Ingress到后端Service这一段，两者形成一条完整的加密链路，如果后端协议不匹配，即使客户端到Ingress这段加密正常,后端链路依然可能是明文。

Q2：gce ingress和nginx ingress的secure-backends配置可以互相迁移吗？
不能直接迁移，gce ingress通过BackendConfig声明，nginx ingress通过注解或ConfigMap声明，两者对健康检查的处理逻辑也不同，迁移时需要重新设计后端的TLS终止位置,并调整健康检查策略。

Q3：开启secure-backends后集群内部流量性能会下降多少？
据业内公开的性能测试数据，HTTPS后端相比HTTP后端，在纯转发场景下延迟增加通常小于5%，主要开销来自TLS握手和加解密，对于长连接应用影响不会太大，但对于高并发短请求场景，建议开启TLS会话复用并调大keepalive连接数，Ingress与后端之间的HTTP/2支持也能减少握手开销。