写点什么

Ingress Nginx 接连披露高危安全漏洞,是否有更好的选择?

  • 2022 年 8 月 07 日
  • 本文字数:3755 字

    阅读完需:约 12 分钟

作者: 澄潭


今年 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/v1kind: Ingressmetadata:  name: ingress-examplespec:  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 架构设计缺陷

1.png


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 提供一个静态文件代理的路由,从而获取到这个凭证。可以看下有了这个凭证能干什么事情:


2.png


Ingress Nginx 凭证权限(图片来自 blog.lightspin.io)


上图是 ingress-nginx 这个 ServiceAccount 角色的 ClusterRole 权限描述,因为网关需要加载 TLS 证书,所以这个角色是具有查看集群内所有 Secret 的权限的。攻击者不但能通过这个凭证拿到所有 TLS 证书的私钥信息,还能拿到集群里所有密钥类配置!


3.png


导致漏洞的架构根因 (图片来自 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 云原生网关

4.png


MSE 云原生网关的控制面和数据面架构


从上图可以看到,MSE 云原生网关使用了数据面(Envoy)和控制面(Istio)隔离的架构,从根本上避免了上述问题。MSE 云原生网关采用了托管部署的模式,不是部署在用户自己的 K8s 集群中,即使出现了安全漏洞,用户也可以通过一键平滑升级轻松修复漏洞。并且有专业安全团队收集漏洞情报,相比开源能提供更迅速、更可靠的修复方案。


基于前面几个 CVE 漏洞原理的说明,不难发现 Ingress Nginx 通过控制面拼接 nginx.conf 配置实现数据面控制的方式也存在很大的安全隐患,例如定义一个特殊的 Ingress Path:


apiVersion: networking.k8s.io/v1kind: Ingressmetadata:  name: ingress-examplespec:  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]


此外,云原生网关的插件市场提供了多种认证鉴权和安全防护插件,可以增强网络安全防护能力:


5.png


云原生网关插件市场


用户还可以基于 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

发布于: 刚刚阅读数: 4
用户头像

阿里巴巴云原生 2019.05.21 加入

还未添加个人简介

评论

发布
暂无评论
Ingress Nginx 接连披露高危安全漏洞,是否有更好的选择?_阿里云_阿里巴巴云原生_InfoQ写作社区