作者:澄潭
今年 K8s Ingress Nginx 项目接连披露了三个高危安全漏洞(CVE-2021-25745[1], CVE-2021-25746[2],CVE-2021-25748[3]),该项目也在近期宣布将停止接收新功能 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
Ingress API 标准示例
在《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/ru n/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[4],根因都是这个问题。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[5]
更安全的替代品——MSE 云原生网关
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,详见文末文档[6]。
此外,云原生网关的插件市场提供了多种认证鉴权和安全防护插件,可以增强网络安全防护能力:
云原生网关插件市场
用户还可以基于 Wasm 技术,用多种语言(Go、JS、Rust 等)实现网关功能动态扩展(无需重启网关),基于 Wasm 的沙箱机制,即使你的代码逻辑访问了空指针,也不会导致网关 crash。这种安全且简单的扩展机制也是 Ingress Nginx 不具备的。
参考链接:
[1] CVE-2021-25745:
https://github.com/kubernetes/ingress-nginx/issues/8502
[2] CVE-2021-25746:
https://github.com/kubernetes/ingress-nginx/issues/8503
[3] CVE-2021-25748:
https://github.com/kubernetes/ingress-nginx/issues/8686
[4] CVE-2021-25742:
https://github.com/kubernetes/ingress-nginx/issues/7837
[5] 相关 issue:
https://github.com/kubernetes/ingress-nginx/pull/8397
[6] 文档:
https://help.aliyun.com/document_detail/424813.html