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

简介： 在《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: &＃8220;/&＃8221;
    backend:
    service:

    name: service1
    port:
      number: 80

• host: bar.foo.com
  http:
  paths:

  • pathType: Prefix
    path: &＃8220;/&＃8221;
    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 修复的正则检测。真是防不胜防&＃8230;&＃8230; 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

    下文中{&＃8230;}省略号隐去了可能引发破绽的配置

    path: &＃8220;/inject{&＃8230;}location /abc&＃8221;
    backend:
    service:

    name: service
    port:
      number: 80 就会在生成的 nginx.conf 中呈现如下配置片段： location /inject{...}location /abc {

    set $ingress_name &＃8220;ingress-example&＃8221;;
    &＃8230;
    &＃8230;

} 相熟 Nginx 配置的同学会理解，这里有两个 location 门路匹配规定，其中 location /abc 是对应上述 Ingress 路由配置的，而 location /inject 则能够实现一个额定的配置注入，在{&＃8230;}中能够写任意的 Nginx  Location 级别配置，甚至应用灵便度很高的 Lua 脚本，达到配置注入者的各种目标。 不同于 Ingress Nginx 通过管制面拼接 nginx.conf 配置实现数据面管制，云原生网关应用了更安全可靠的 xDS 协定，通过 xDS API 配置解析代替字符串拼接，从根本上防止了拼接配置导致配置注入的问题，确保配置动作是明确的，行为是可预期的。上面是向 Envoy 下发路由匹配规定用到的 proto 协定，不同于 Ingress Nginx 的 location 指令拼接，这种形式显然束缚了路由匹配配置的作用范畴。 message RouteMatch {
option (udpa.annotations.versioning).previous_message_type = &＃8220;envoy.api.v2.route.RouteMatch&＃8221;;
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 &＃8220;regex&＃8221;;
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&＃8230;  [2] CVE-2021-25746：https://github.com/kubernetes&＃8230; [3] CVE-2021-25748：https://github.com/kubernetes&＃8230; [4] CVE-2021-25742：https://github.com/kubernetes&＃8230; [5] 相干 issue：https://github.com/kubernetes&＃8230; [6] 文档：https://help.aliyun.com/docum&＃8230;原文链接：https://click.aliyun.com/m/10&＃8230;本文为阿里云原创内容，未经容许不得转载。