Kubernetes集群Namespace内POD进出SSL流量统一代理鉴权方案咨询

一、Istio/Envoy 原生适配方案（优先推荐） #

你之前调研未找到对应方案大概率是配置路径不匹配，该需求完全可以通过Istio原生能力实现：

• 首先在目标Namespace内部署一个独立的Envoy实例作为统一流量出入口，不要使用集群全局的Istio Ingress/Egress Gateway
• 配置Sidecar自定义资源，将Namespace下所有业务Pod的入向、出向流量全部转发到该专属Envoy实例
• 在该Envoy实例上配置SSL终止规则，挂载对应域名的SSL证书
• 配置Istio AuthorizationPolicy 资源，指定匹配请求头的校验规则，不满足规则的请求直接返回403状态码；如果有复杂校验逻辑，可给Envoy挂载Lua过滤器实现自定义判断
• 最后配置NetworkPolicy禁止业务Pod直接接收/发送外部流量，强制所有流量经过该Envoy实例

二、独立Nginx部署方案 #

你当前规划的方案可落地性很强，具体实现可参考以下步骤：

• 部署Nginx Pod时挂载SSL证书，同时配置反向代理规则处理入向流量、正向代理规则处理出向流量
• 基础头校验逻辑可直接通过Nginx原生ngx_http_headers_module实现，示例配置如下：

  if ($http_{你要检查的头名称} !~* ^{允许的头值}$) {
      return 403;
  }
  

• 复杂自定义校验逻辑可搭配auth_request模块，调用你开发的Python服务完成判断，无需直接给Nginx编译Python模块
• 流量拦截通过NetworkPolicy实现：禁止业务Pod和外部的直接通信，只允许和Nginx Pod的端口互通；入向流量将Nginx Ingress的后端直接指向Nginx Pod对应的Service即可

三、Squid组件适配性说明 #

Squid完全可以实现该需求：

• Squid天然支持正向+反向代理混合部署，通过ssl_bump配置可实现SSL流量的终止
• 原生支持ACL规则匹配请求头，不符合规则的流量可直接配置返回403
• 注意事项：Squid仅对HTTP/HTTPS协议的头校验支持成熟，若存在其他TCP类型的SSL流量则无法实现头检查；全Namespace流量拦截需要给所有业务Pod配置HTTP_PROXY/HTTPS_PROXY环境变量指向Squid实例，或者配置透明代理规则，适配成本略高于前两种方案

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