今年 K8s Ingress Nginx 项目接连披露了三个高危安全漏洞（CVE-2021-25745, CVE-2021-25746, CVE-2021-25748），该项目也在近期宣布将停止接收新功能 PR，专注修复并提升稳定性。Ingress Nginx 作为 K8s 项目自带的网关组件，被大量用户的 K8s 集群默认安装。作为处于 Internet 网络边界的基础软件，又被大规模使用，势必会成为一些攻击者的理想目标。一旦防线攻破，其代价是惨痛的，可以参考同样是网络边界的基础组件，OpenSSL 的 Heartbleed 心血漏洞殷鉴不远。
2014年 Heartbleed 漏洞释出不久，OpenBSD 开始自行维护 LibreSSL，Google 也推出了 BoringSSL，基于和 OpenSSL 遵循同一套 SSL/TLS 协议标准，提供更安全的替代品。类似的，基于同一套 K8s Ingress API 标准，是否有更安全的 K8s 网关可以替代 Ingress Nginx？
apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: ingress-example spec: rules: - host: foo.bar.com http: paths: - pathType: Prefix path: "/" backend: service: name: service1 port: number: 80 - host: bar.foo.com http: paths: - pathType: Prefix path: "/" backend: service: name: service2 port: number: 80
在《K8s 网关选型初判：Nginx 还是 Envoy》一文中，我们已经给出了这个新的选项：MSE 云原生网关。本文继续展开分析，为何 MSE 云原生网关有更好的安全性保障。
Ingress Nginx 架构设计缺陷
Ingress Nginx 容器架构（图片来自 kubernetes.io）
Ingress Nginx 安全漏洞频发的背后，是由其不安全的架构设计导致的：将控制面 Ingress Controller 组件（Go程序），和数据面 Nginx 组件放在一个容器内。控制面在这里是一个 Admin 的角色，可想而知其会管理一些敏感的信息，例如和 K8s API Server 通信的认证凭证。数据面和控制面共用容器，就给攻击者通过数据面获取这些敏感信息提供了可乘之机。举例来说：
K8s 使用了 RBAC 机制实现 API Server 接口的认证鉴权，而用于 RBAC 认证的凭证信息，会通过 volume 挂载到容器的/var/run/secrets/kubernetes.io/serviceaccount目录。CVE-2021-25745 就是利用了控制面拼接 nginx.conf 配置文件的漏洞，通过 Ingress Path 实现了配置注入，让 Nginx 提供一个静态文件代理的路由，从而获取到这个凭证。可以看下有了这个凭证能干什么事情：
Ingress Nginx 凭证权限（图片来自 blog.lightspin.io）
上图是 ingress-nginx这个ServiceAccount角色的ClusterRole权限描述，因为网关需要加载 TLS 证书，所以这个角色是具有查看集群内所有Secret的权限的。攻击者不但能通过这个凭证拿到所有 TLS 证书的私钥信息，还能拿到集群里所有密钥类配置！
导致漏洞的架构根因 （图片来自 blog.lightspin.io）
实际上，CVE-2021-25746 和 CVE-2021-25748，包括更早的 CVE-2021-25742，根因都是这个问题。CVE-2021-25742 基于 custom snippet 通过 Nginx 配置片段实现凭证获取；CVE-2021-25746 可以基于多种 Ingress Annotation 实现 Nginx 配置片段注入获取凭证；CVE-2021-25748 绕过了针对 CVE-2021-25745 修复的正则检测。真是防不胜防......
Ingress Nginx 社区认识到了这个架构问题的严重性，已经开始计划做控制面和数据面的分离。若继续保持现有架构，未来可能会爆出更严重的安全漏洞。
值得注意的是，这种架构除了会导致上述安全问题，还会导致容器 CPU 负载较高时，控制面和数据面进程互相抢占调度，出现一系列稳定性问题，例如：
1由控制面负责的存活健康检查（livenessProbe）超时失败，导致容器不断重启
2在开启了 prometheus 采集监控指标的情况下，控制面因为高负载抢占不到足够的 CPU，会出现 OOM，导致容器被 kill，详细原因见相关 issue：https://github.com/kubernetes/ingress-nginx/pull/8397
更安全的替代品——MSE 云原生网关
从上图可以看到，MSE 云原生网关使用了数据面（Envoy）和控制面（Istio）隔离的架构，从根本上避免了上述问题。MSE 云原生网关采用了托管部署的模式，不是部署在用户自己的 K8s 集群中，即使出现了安全漏洞，用户也可以通过一键平滑升级轻松修复漏洞。并且有专业安全团队收集漏洞情报，相比开源能提供更迅速、更可靠的修复方案。
基于前面几个 CVE 漏洞原理的说明，不难发现 Ingress Nginx 通过控制面拼接 nginx.conf 配置实现数据面控制的方式也存在很大的安全隐患，例如定义一个特殊的 Ingress Path：
apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: ingress-example spec: rules: - http: paths: - pathType: Prefix # 下文中{...}省略号隐去了可能引发漏洞的配置 path: "/inject{...}location /abc" backend: service: name: service port: number: 80
就会在生成的 nginx.conf 中出现如下配置片段：
location /inject{...}location /abc { set $ingress_name "ingress-example"; ... ... }
熟悉 Nginx 配置的同学会了解，这里有两个 location 路径匹配规则，其中 location /abc 是对应上述 Ingress 路由配置的，而 location /inject则可以实现一个额外的配置注入，在{...}中可以写任意的Nginx Location 级别配置，甚至使用灵活度很高的 Lua 脚本，达到配置注入者的各种目的。
不同于 Ingress Nginx 通过控制面拼接 nginx.conf 配置实现数据面控制，云原生网关使用了更安全可靠的 xDS 协议，通过 xDS API 配置解析替代字符串拼接，从根本上避免了拼接配置导致配置注入的问题，确保配置动作是明确的，行为是可预期的。下面是向 Envoy 下发路由匹配规则用到的 proto 协议，不同于 Ingress Nginx 的 location 指令拼接，这种方式显然约束了路由匹配配置的作用范围。
message RouteMatch { option (udpa.annotations.versioning).previous_message_type = "envoy.api.v2.route.RouteMatch"; message GrpcRouteMatchOptions { option (udpa.annotations.versioning).previous_message_type = "envoy.api.v2.route.RouteMatch.GrpcRouteMatchOptions"; } message TlsContextMatchOptions { option (udpa.annotations.versioning).previous_message_type = "envoy.api.v2.route.RouteMatch.TlsContextMatchOptions"; google.protobuf.BoolValue presented = 1; google.protobuf.BoolValue validated = 2; } // An extensible message for matching CONNECT requests. message ConnectMatcher { } reserved 5, 3; reserved "regex"; oneof path_specifier { option (validate.required) = true; string prefix = 1; string path = 2; type.matcher.v3.RegexMatcher safe_regex = 10 [(validate.rules).message = {required: true}]; ConnectMatcher connect_matcher = 12; string path_separated_prefix = 14 [(validate.rules).string = {pattern: "^[^?#]+[^?#/]$"}]; string path_template = 15 [(validate.rules).string = {min_len: 1 max_len: 256 ignore_empty: true}]; } google.protobuf.BoolValue case_sensitive = 4; core.v3.RuntimeFractionalPercent runtime_fraction = 9; repeated HeaderMatcher headers = 6; repeated QueryParameterMatcher query_parameters = 7; GrpcRouteMatchOptions grpc = 8; TlsContextMatchOptions tls_context = 11; repeated type.matcher.v3.MetadataMatcher dynamic_metadata = 13; }
值得一提的是，目前 Ingress Nginx 的大量路由策略功能都需要通过更新 nginx.conf，然后重启 Nginx 生效，重启过程中客户端连接会断开，在 websocket 等长连接场景下，会造成业务影响；而通过 Envoy 的 xDS 配置下发，路由策略生效基于 RDS/ECDS，对长连接完全无影响。
为了方便用户从 Ingress Nginx 平滑迁移到 MSE 云原生网关，我们除了完全兼容了 K8s Ingress API 的标准，也兼容了常用的 Ingress Nginx Annotation：https://help.aliyun.com/document_detail/424813.html。
此外，云原生网关的插件市场提供了多种认证鉴权和安全防护插件，可以增强网络安全防护能力：
云原生网关插件市场
用户还可以基于 Wasm 技术，用多种语言（Go、JS、Rust等）实现网关功能动态扩展（无需重启网关），基于 Wasm 的沙箱机制，即使你的代码逻辑访问了空指针，也不会导致网关 crash。这种安全且简单的扩展机制也是 Ingress Nginx 不具备的。
MSE 注册配置中心专业版首购享 9 折优惠，MSE 云原生网关预付费全规格享 9 折优惠。点击阅读原文，即享优惠！
