关于后端:Ingress-Nginx-接连披露高危安全漏洞是否有更好的选择

1次阅读

共计 5022 个字符，预计需要花费 13 分钟才能阅读完成。

简介：在《K8s 网关选型初判：Nginx 还是 Envoy》一文中，咱们曾经给出了这个新的选项：MSE 云原生网关。本文持续开展剖析，为何 MSE 云原生网关有更好的安全性保障。作者：澄潭往年 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… [2] CVE-2021-25746：https://github.com/kubernetes… [3] CVE-2021-25748：https://github.com/kubernetes… [4] CVE-2021-25742：https://github.com/kubernetes… [5] 相干 issue：https://github.com/kubernetes… [6] 文档：https://help.aliyun.com/docum… 原文链接：https://click.aliyun.com/m/10… 本文为阿里云原创内容，未经容许不得转载。

正文完