kubernetes 确保对命名空间锁的验证Webhook配置的有效执行

fv2wmkja  于 5个月前  发布在  Kubernetes
关注(0)|答案(7)|浏览(127)

发生了什么?
正如在 https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/#configure-admission-webhooks-on-the-fly 中提到的:
"在创建了 webhook 配置后,系统需要几秒钟的时间来执行新的配置。"
尽管等待验证 webhook 配置被考虑用于新 pod 创建请求,但在系统负载过高时,某些请求仍然能够绕过验证过程。

预期会发生什么?

在这个特定的场景中,预期是在 dryRun 检查(验证 webhook 拒绝我的请求)之后发生的任何创建请求都会受到 webhook 验证过程的约束。

如何尽可能精确地重现它?

  1. 创建一个允许内存请求为 1 Mi 的 ResourceQuota。
  2. 运行一个带有提供的函数的线程,该线程不断创建需要 10Mi 资源的 pod。
  3. 创建一个 ValidatingWebhookConfiguration,拒绝除名称为 "allowed-pod" 的所有 pod 创建。
  4. 确保 webhook 在集群节点上以 dry run 模式运行。
  5. 将 ResourceQuota 的 memory.request 提高到 10Mi。
  6. 您将观察到线程即使其名称不是 "allowed-pod",也能创建 pod。
func abuseSystem(virtClient kubecli.KubevirtClient, ctx context.Context, testNs string) {
	pod := &v1.Pod{
		ObjectMeta: metav1.ObjectMeta{
			Name:      "pod" + rand.String(3),
			Namespace: testNs, // Adjust the namespace as needed
		},
		Spec: v1.PodSpec{
			Containers: []v1.Container{
				{
					Name:  "nginx",
					Image: "your-image", // Specify the container image to use
					Resources: v1.ResourceRequirements{
						Requests: v1.ResourceList{
							v1.ResourceMemory: resource.MustParse("10Mi"),
						},
					},
				},
			},
		},
	}

	for {
		select {
		case <-ctx.Done():
			fmt.Println("Abusing process canceled")
			return
		default:
			// Create a pod requiring 10Mi resources
			_, _ = virtClient.CoreV1().Pods(pod.Namespace).Create(context.TODO(), pod, metav1.CreateOptions{})
		}
	}
}

我们还需要了解其他信息吗?

我希望在 dryRun 检查之后的每个请求都能经过验证过程。或者,应该有一个可靠的方法来确定何时完全遵守 validatingwebhookconfiguration,表明所有 pod 创建请求都将经过预期的验证。

Kubernetes 版本

Client Version: version.Info{Major:"1", Minor:"26", GitVersion:"v1.26.3", GitCommit:"9e644106593f3f4aa98f8a84b23db5fa378900bd", GitTreeState:"clean", BuildDate:"2023-03-15T13:40:17Z", GoVersion:"go1.19.7", Compiler:"gc", Platform:"linux/amd64"}
Kustomize Version: v4.5.7
Server Version: version.Info{Major:"1", Minor:"26", GitVersion:"v1.26.3", GitCommit:"9e644106593f3f4aa98f8a84b23db5fa378900bd", GitTreeState:"clean", BuildDate:"2023-03-15T13:33:12Z", GoVersion:"go1.19.7", Compiler:"gc", Platform:"linux/amd64"}

云提供商

本地部署

OS 版本

# On Linux:
$ cat /etc/os-release
# paste output here
$ uname -a
# paste output here

# On Windows:
C:\> wmic os get Caption, Version, BuildNumber, OSArchitecture
# paste output here

安装工具

容器运行时 (CRI) 和版本 (如果适用)

相关插件 (CNI, CSI, ...) 和版本 (如果适用)

bfhwhh0e

bfhwhh0e1#

验证Webhook配置
/sig api-machinery

h9a6wy2h

h9a6wy2h2#

我预计在进行dryRun检查之后,每个请求都会经历验证过程。或者,应该有一种可靠的方法来确定验证webhook配置何时得到充分的尊重,表明所有pod创建请求都将经历预期的验证。
Kubernetes不保证观察到先前请求的副作用的客户端可以对同一集群进行后续请求,并确保之前观察到的副作用适用于与此无关的后续请求。关于集群收敛所需的时间也没有保证,甚至不确定集群是否能达到稳定状态。
有关支持事务或类似机制以观察对象效果是否处于活动状态的上下文,请参阅#6055(评论)。
如果实施了这个更改,您正在要求的@Barakmor1将需要更广泛的启用更改和相应的enhancement proposal。您可以合理地认为它不会发生。

fivyi3re

fivyi3re3#

/remove-kind bug
/kind feature
xienkqul

xienkqul4#

您好,Markdown是一种轻量级标记语言,它允许人们使用易读易写的纯文本格式编写文档。Markdown 的语法非常简单,只需要使用一些简单的符号就可以实现各种排版效果。

关于您提到的问题,我不太确定您的问题是什么。如果您能提供更多上下文或者解释一下您的问题,我会尽力帮助您。

g6ll5ycj

g6ll5ycj5#

/cc @jpbetz
/triage accepted
luaexgnf

luaexgnf6#

这个问题已经超过一年没有更新了,应该重新进行优先级评估。
你可以:

  • 确认这个问题仍然与 /triage accepted (仅组织成员)相关
  • /close 关闭这个问题

有关优先级评估过程的更多详细信息,请参见 https://www.kubernetes.dev/docs/guide/issue-triage/
已接受移除优先级评估

qzwqbdag

qzwqbdag7#

/cc @jpbetz
/triage accepted

相关问题