|
本文档采用自动化机器翻译技术翻译。 尽管我们力求提供准确的译文,但不对翻译内容的完整性、准确性或可靠性作出任何保证。 若出现任何内容不一致情况,请以原始 英文 版本为准,且原始英文版本为权威文本。 |
|
这是尚未发布的文档。 Admission Controller 1.34-dev. |
变更策略
变更策略的结构与验证策略相同:
-
它们必须注册
validate和validate_settingswaPC 函数。 -
主机与策略之间使用的通信 API 与验证策略使用的相同。
变更策略接受请求,并可以通过返回一个看起来像这样的 ValidationResponse 对象来提出对传入对象的变更:
{
"accepted": true,
"mutated_object": <object to be created>
}
mutated_object 字段包含策略希望在 Kubernetes 集群中创建的对象,序列化为 JSON。
一个具体的例子
假设策略收到了这个 ValidationRequest:
{
"settings": {},
"request": {
"operation": "CREATE",
"object": {
"apiVersion": "v1",
"kind": "Pod",
"metadata": {
"name": "security-context-demo-4"
},
"spec": {
"containers": [
{
"name": "sec-ctx-4",
"image": "gcr.io/google-samples/node-hello:1.0",
"securityContext": {
"capabilities": {
"add": ["NET_ADMIN", "SYS_TIME"]
}
}
}
]
}
}
}
}
|
在这个例子中, |
这个请求生成是因为有人试图创建一个看起来像这样的 Pod:
apiVersion: v1
kind: Pod
metadata:
name: security-context-demo-4
spec:
containers:
- name: sec-ctx-4
image: gcr.io/google-samples/node-hello:1.0
securityContext:
capabilities:
add:
- NET_ADMIN
- SYS_TIME
假设策略回复以下 ValidationResponse:
{
"accepted": true,
"mutated_object": {
"apiVersion": "v1",
"kind": "Pod",
"metadata": {
"name": "security-context-demo-4"
},
"spec": {
"containers": [
{
"name": "sec-ctx-4",
"image": "gcr.io/google-samples/node-hello:1.0",
"securityContext": {
"capabilities": {
"add": [
"NET_ADMIN",
"SYS_TIME"
],
"drop": [
"BPF"
]
}
}
}
]
}
}
}
这将导致请求被接受,但最终的 Pod 看起来像这样:
apiVersion: v1
kind: Pod
metadata:
name: security-context-demo-4
spec:
containers:
- name: sec-ctx-4
image: gcr.io/google-samples/node-hello:1.0
securityContext:
capabilities:
add:
- NET_ADMIN
- SYS_TIME
drop:
- BPF
正如你所看到的,策略改变了 Pod 中唯一声明的容器的 securityContext.capabilities.drop 部分。
由于策略,容器现在放弃了 BPF 能力。
回顾
这些是变更策略必须实现的函数:
| waPC 函数名称 | 输入负载 | 输出负载 |
|---|---|---|
|
|
|
|
|
|