Apache APISIX Ingress v1.5.0 发布

目前 Apache APISIX Ingress controller^[2]^ 项目已经进入了 v1.5 的发布窗口，之前已经发布了 1.5.0-rc1 版本，如今发现的一些 bug 已经得到修正，我们已经计划发布 v1.5.0 的正式版本了。待投票流程结束后，将会有正式的公告和对应的 Release 发布。

距离上一个特性版本 v1.4.0 发布已经过去了将近 7 个月的时间，这期间我们进行了大量的开发工作，有 155 次提交和 32 位贡献者参与，感谢大家的参与让这个版本有了很大的不同。这里我列一些主要的变化，后续还会有专门的发版公告和特性解读文章等。

在这个版本中，正式将所有 CRD 资源的 API version 升级到了 v2 stable ，这也标志着用户使用起来会更加的方便和统一，同时这些资源也已经过多个版本迭代和用户在生产环境的使用，达到了足够稳定的级别。

此外，在这个版本中提供了对 Gateway API 的支持，不过此特性目前尚处于实验性质，默认不开启，用户可以通过为它传递 enable_gateway_api=true 的配置项来开启此能力。在下个版本中我们将引入 Gateway API 项目的一致性测试，来保证我们的实现与 Gateway API 项目的一致性。这样做的好处在于凡是通过了 Gateway API 一致性校验的实现，均可进行互相替换，不会存在锁定的情况。而且在迁移的过程中，也可以保证配置的兼容性。

Apache APISIX Ingress controller 项目是支持多种配置方式的，无论使用 CRD 的方式，或者使用 Kubernetes 中原生的 Ingress 资源都是可以的。但在之前版本中，对于 Ingress 资源来说，想要使用 APISIX 提供的 plugin 能力，就必须先实现一个对应的 annotation，这种方式可扩展能力很差。在这个版本中，我们为 Ingress 资源提供了一个新的 annotation 允许所有的 Ingress 资源可以直接使用 APISIX 所提供的 70+ 种 plugin 的能力，这对于一些使用开源的仅支持配置 Ingress 资源的用户而言，是非常有用的。

除去这些新功能外，目前无论是开源项目的维护者，还是使用者，都在积极的关注供应链安全。在 Apache APISIX Ingress controller 中，我们也升级了它使用的 Golang 版本，以及所有依赖的模块均升级到了最新版本，并且借助 GitHub 的 Dependabot 进行依赖的周期性扫描和更新，尽可能的提供安全可信的软件。

这里我先介绍这么多，大家如果对此项目感兴趣，欢迎在 GitHub 加个 star https://github.com/apache/apisix-ingress-controller

发布流程未结束前，也可直接从最新的代码中构建镜像尝试使用。

Wasmtime v1.0 正式发布

Wasmtime 是一个快速且安全的 WebAssembly 运行时，是 Bytecode Alliance （非营利组织）下的项目。

"

字节码联盟是一个非营利组织，致力于创建安全的新软件基础，建立在WebAssembly和WebAssembly 系统接口 (WASI)等标准之上。字节码联盟致力于建立一个功能强大、安全的平台，让应用程序开发人员和服务提供商能够自信地在任何基础设施、任何操作系统或设备上运行不受信任的代码，并利用数十年来在 Web 浏览器中的经验。我们的愿景是为所有平台建立一个默认安全的 WebAssembly 生态系统。 "

关于 WebAssembly 的详细介绍，并不是此处的重点，推荐可以看看 MDN 的 WebAssembly 文档进行了解。

Wasmtime 的语言支持目前是有限的，其中最受支持的语言是 Rust。此外，多种语言都支持嵌入 Wasmtime，比如 Rust、C、Python、C#、Go 和 Bash 等。

以下我使用 Rust 来快速的介绍下 Wasmtime 的使用。

首先在安装完 Rust 和 Wasmtime 的环境后，写一个最简单的 hello.rs

fn main() {
    println!("Hello, Wasmtime!");
}

然后进行编译和运行即可：

➜  ws rustup target add wasm32-wasi
info: component 'rust-std' for target 'wasm32-wasi' is up to date
➜  ws rustc hello.rs --target wasm32-wasi
➜  ws wasmtime hello.wasm
Hello, Wasmtime!

可以看到非常简单，当然你也可以选择使用 cargo new的方式创建个新项目来进行使用，此处仅做为示例。

来自 Fastly 的工程师提到，在一年多以前就可以将 Wasmtime 称为生产就绪了，之所以没有这样做，是希望能在正式宣布它生产就绪前，能在生产中稳定运行 Wasmtime 很长一段时间。

此事与 K8s 生态比较相关的一个重要内容是，Microsoft 在 Azure Kubernetes （AKS）服务中提供了一个预览版功能：允许创建具有 WASM/WASI 运行时的节点池，并运行 WASM 应用程序。当然，此处可以使用的 WASM 运行时就是 Wasmtime 。

期待后续 WebAssembly 生态在云原生领域中的发展！

上游进展

Add auth API to get self subject attributes by nabokihms · Pull Request #111333 · kubernetes/kubernetes

这是 KEP-3325: Self subject attributes review API 实现的一部分。

大家想必都知道，Kubernetes 中并没有 User（用户）的资源，但是 Kubernetes 中有权限校验的方式，比如我们常用到的利用 x509 证书进行用户权限相关的校验，或者通过外部的 OIDC 和 webhook 等进行校验。

此功能实际上是为了添加一个新的接口，以便于用户身份通过校验后，获取其所具有的属性。这样就可以简单的通过增加一个 kubectl auth whoami 的命令，来了解当前用户的相关信息了。这功能比较类似于我们做 OAuth 的时候，可能会做个 UserInfo 之类的接口，用来查看用户相关的属性。

该功能是通过在 authentication.k8s.io Group 下添加了 SelfSubjectReview 资源来实现的，具体如下：

// SelfSubjectReview contains the user information that the kube-apiserver has about the user making this request.
// When using impersonation, users will receive the user info of the user being impersonated.
type SelfSubjectReview struct {
 metav1.TypeMeta `json:",inline"`
 // Standard object's metadata.
 // More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
 // +optional
 metav1.ObjectMeta `json:"metadata,omitempty" protobuf:"bytes,1,opt,name=metadata"`
 // Status is filled in by the server with the user attributes.
 Status SelfSubjectReviewStatus `json:"status,omitempty" protobuf:"bytes,2,opt,name=status"`
}

// SelfSubjectReviewStatus is filled by the kube-apiserver and sent back to a user.
type SelfSubjectReviewStatus struct {
 // User attributes of the user making this request.
 // +optional
 UserInfo v1.UserInfo `json:"userInfo,omitempty" protobuf:"bytes,1,opt,name=userInfo"`
}

此功能在 v1.26 版本开始引入，并作为 Alpha 特性提供，可通过 APISelfSubjectReview feature gate 控制是否启用。

同时，本次也在 kubectl 中添加了 kubectl alpha auth whoami 子命令，可直接查看当前用户的相关属性信息。

Limit redirect proxy handling to redirected responses by liggitt · Pull Request #112526 · kubernetes/kubernetes

在上一篇《K8S 生态周报| Kubernetes 爆出全版本漏洞》中，我曾介绍过 CVE-2022-3172 漏洞相关的信息。

上游中的修复方式是提供了一个选项 --aggregator-reject-forwarding-redirect=true 来设置拒绝跟随重定向，避免 SSRF 。但同时该修复也引入了新的问题，由于该修复仅判断了 HTTP Code 是否在 300～399 ，但这是个不完整的假设，并非所有的 3xx 状态码都是重定向，比如 304 Not Modified 表示无需再次传输请求的内容。

所以本次的修复额外增加了对 Location Header 的判断。如下：

diff --git a/staging/src/k8s.io/apimachinery/pkg/util/proxy/upgradeaware.go b/staging/src/k8s.io/apimachinery/pkg/util/proxy/upgradeaware.go
index a3a14241cc6..278ed089d95 100644
--- a/staging/src/k8s.io/apimachinery/pkg/util/proxy/upgradeaware.go
+++ b/staging/src/k8s.io/apimachinery/pkg/util/proxy/upgradeaware.go
@@ -263,7 +263,7 @@ func (h *UpgradeAwareHandler) ServeHTTP(w http.ResponseWriter, req *http.Request
   oldModifyResponse := proxy.ModifyResponse
   proxy.ModifyResponse = func(response *http.Response) error {
    code := response.StatusCode
-   if code >= 300 && code <= 399 {
+   if code >= 300 && code <= 399 && len(response.Header.Get("Location")) > 0 {
     // close the original response
     response.Body.Close()
     msg := "the backend attempted to redirect this request, which is not permitted"

此修复也会被 cherry-pick 到其他的分支中，并将在下个版本进行发布。