关于kubernetes:K8S-生态周报-Kubernetes-新增-auth-whoami-子命令可获取用户属性

0次阅读

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

「K8S 生态周报」内容次要蕴含我所接触到的 K8S 生态相干的每周值得举荐的一些信息。欢送订阅知乎专栏「k8s 生态」。

大家好,我是张晋涛。

Apache APISIX Ingress v1.5.0 公布

目前 Apache APISIX Ingress controller 我的项目曾经进入了 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/api…

公布流程未完结前,也可间接从最新的代码中构建镜像尝试应用。

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 到其余的分支中,并将在下个版本进行公布。

  • Removal of GlusterFS code from the repo by humblec · Pull Request #112015 · kubernetes/kubernetes

在之前的「K8S 生态周报」中我曾介绍过,在 v1.25 中将树内的 GlusterFS plugin 标记为废除,并倡议迁徙至应用 CSI,
现在这些插件曾经被彻底删除了。


欢送订阅我的文章公众号【MoeLove】

正文完
 0