|
本文档采用自动化机器翻译技术翻译。 尽管我们力求提供准确的译文,但不对翻译内容的完整性、准确性或可靠性作出任何保证。 若出现任何内容不一致情况,请以原始 英文 版本为准,且原始英文版本为权威文本。 |
|
这是尚未发布的文档。 Admission Controller 1.34-dev. |
策略组
策略组功能允许用户通过组合简单策略来创建复杂策略。它引入了两个新的自定义资源定义(CRD):
-
AdmissionPolicyGroup:适用于特定名称空间的准入策略。 -
ClusterAdmissionPolicyGroup:适用于整个集群的准入策略。
这些策略组使用户能够使用现有策略,减少自定义策略创建的需求并增强重用性。通过避免策略逻辑的重复,用户可以简化管理并使用类似 DSL 的配置创建自定义策略。
策略组允许使用逻辑运算符对多个策略进行组合评估。这允许定义复杂的逻辑。然而,虽然普通策略可以包含变更逻辑以在准入期间修改资源,但策略组仅进行验证。
策略组的配置与普通策略类似。不同之处在于添加了 expression、message 和 policies 字段,并在不同位置声明上下文感知规则。
这是一个 ClusterAdmissionPolicyGroup 的示例,您可以在接下来的部分中使用它来解释不同的字段:
一个`ClusterAdmissionPolicyGroup`,拒绝使用带有`latest`标签镜像的Pod,除非这些镜像由两个受信任方签名:爱丽丝和鲍勃。
apiVersion: policies.kubewarden.io/v1
kind: ClusterAdmissionPolicyGroup # or AdmissionPolicyGroup
metadata:
name: demo
spec:
rules:
- apiGroups: [""]
apiVersions: ["v1"]
resources: ["pods"]
operations:
- CREATE
- UPDATE
policies:
signed_by_alice:
module: ghcr.io/kubewarden/policies/verify-image-signatures:v0.3.0
settings:
modifyImagesWithDigest: false
signatures:
- image: "*"
pubKeys:
- |
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEyg65hiNHt8FXTamzCn34IE3qMGcV
yQz3gPlhoKq3yqa1GIofcgLjUZtcKlUSVAU2/S5gXqyDnsW6466Jx/ZVlg==
-----END PUBLIC KEY-----
signed_by_bob:
module: ghcr.io/kubewarden/policies/verify-image-signatures:v0.3.0
settings:
modifyImagesWithDigest: false
signatures:
- image: "*"
pubKeys:
- |
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEswA3Ec4w1ErOpeLPfCdkrh8jvk3X
urm8ZrXi4S3an70k8bf1OlGnI/aHCcGleewHbBk1iByySMwr8BabchXGSg==
-----END PUBLIC KEY-----
reject_latest:
module: registry://ghcr.io/kubewarden/policies/trusted-repos:v0.2.0
settings:
tags:
reject:
- latest
expression: "reject_latest() || (signed_by_alice() && signed_by_bob())"
message: "the image is using the latest tag or is not signed by Alice and Bob"
主要配置字段
本节涵盖策略组的主要配置字段。
policies 属性
策略字段是普通策略的映射。SUSE Security Admission Controller 通过策略组调用策略,以确定是否接受或拒绝正在评估的资源。这些策略的定义是普通 Admission Controller 策略的简化版本,仅包含 module、settings 和 contextAwareResources 属性。这些元素对于策略在策略组中正常工作是必要的。
一个唯一的名称标识组策略中的每个策略。例如,以下代码片段定义了三个策略:signed_by_alice、signed_by_bob 和 reject_latest_tag.
policies:
signed_by_alice:
module: ghcr.io/kubewarden/policies/verify-image-signatures:v0.2.8
settings: {} # settings for the policy
signed_by_bob:
module: ghcr.io/kubewarden/policies/verify-image-signatures:v0.2.8
settings: {} # settings for the policy
reject_latest_tag:
module: ghcr.io/kubewarden/policies/trusted-repos-policy:v0.2.0
settings: {} # settings for the policy
|
一个策略组可以多次包含相同的策略,但配置不同。 |
expression 属性
expression 属性包含由逻辑运算符连接在一起的策略标识符组成的语句。
expression 语句的评估必须得出布尔数据类型的值。
策略的表示形式是一个以 .spec.policies 映射中指定的策略标识符命名的函数。策略评估产生的结果随后使用用户提供的逻辑运算符进行评估。
这些是支持的运算符:
-
&&:用于执行AND操作 -
||:用于执行OR操作 -
!:用于执行NOT操作
您可以使用圆括号 ( ) 来定义评估优先级。
例如,给定以下表达式:
reject_latest() || (signed_by_alice() && signed_by_bob())
该策略拒绝使用 latest 标签的镜像的工作负载,除非 Alice 和 Bob 都已签署这些镜像。
message 属性和响应格式
message 字段指定当 expression 的评估结果为拒绝时返回的消息。响应包括消息,以及各个策略评估的结果。
|
只有在必要时,属于该组的策略才会进行评估。 例如,给定以下表达式:
当 同样,如果 这避免了对组中策略的不必要评估,并为入场请求提供快速响应。 |
当组策略执行拒绝时,系统将所有组策略的评估细节作为 AdmissionResponse .status.details.causes 的一部分发送。
您可以通过提高 kubectl 的详细程度来获取被拒绝的入场请求的完整细节:
kubectl -v4 apply -f signed-pod.yml
I0919 18:29:40.251332 4330 helpers.go:246] server response object: [{
"kind": "Status",
"apiVersion": "v1",
"metadata": {},
"status": "Failure",
"message": "error when creating \"signed-pod.yml\": admission webhook \"clusterwide-demo.kubewarden.admission\" denied the request: the image is using the latest tag or is not signed by Alice and Bob",
"details": {
"causes": [
{
"message": "Resource signed is not accepted: verification of image testing.registry.svc.lan/busybox:latest failed: Host error: Callback evaluation failure: Image verification failed: missing signatures\nThe following constraints were not satisfied:\nkind: pubKey\nowner: null\nkey: |\n -----BEGIN PUBLIC KEY-----\n MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEswA3Ec4w1ErOpeLPfCdkrh8jvk3X\n urm8ZrXi4S3an70k8bf1OlGnI/aHCcGleewHbBk1iByySMwr8BabchXGSg==\n -----END PUBLIC KEY-----\nannotations: null\n",
"field": "spec.policies.signed_by_bob"
},
{
"message": "not allowed, reported errors: tags not allowed: latest",
"field": "spec.policies.reject_latest"
}
]
},
"code": 400
}]
Error from server: error when creating "signed-pod.yml": admission webhook "clusterwide-demo.kubewarden.admission" denied the request: the image is using the latest tag or is not signed by Alice and Bob
完整的入场响应在调试模式下运行的策略服务器的日志中可用。此外,评估细节始终是由策略服务器发出的OpenTelemetry跟踪的一部分。
上下文感知策略
策略组与普通策略之间的另一个区别是上下文感知资源规则的定义位置。组中的每个策略接受一个可选的`contextAwareResources`字段,以指定在评估期间策略可以访问的资源。与普通策略类似,您只能通过定义`ClusterAdmissionPolicyGroup`来使用上下文感知功能。这是出于安全原因,因为只有非特权用户可以部署`AdmissionPolicyGroup`资源。有关更多详细信息,请参阅上下文感知策略文档。
一个使用上下文感知策略的策略组示例。
apiVersion: policies.kubewarden.io/v1
kind: ClusterAdmissionPolicyGroup # or AdmissionPolicyGroup
metadata:
name: demo-ctx-aware
spec:
rules:
- apiGroups:
- ""
apiVersions:
- v1
resources:
- services
operations:
- CREATE
- UPDATE
policies:
unique_service_selector:
module: registry://ghcr.io/kubewarden/policies/unique-service-selector-policy:v0.1.0
contextAwareResources:
- apiVersion: v1
kind: Service
settings:
app.kubernetes.io/name: MyApp
owned_by_foo_team:
module: registry://ghcr.io/kubewarden/policies/safe-annotations:v0.2.9
settings:
mandatory_annotations:
- owner
constrained_annotations:
owner: "foo-team"
expression: "unique_service_selector() || (!unique_service_selector() && owned_by_foo_team())"
message: "the service selector is not unique or the service is not owned by the foo team"
在前面的示例中,`unique_service_selector`策略可以访问`Service`资源。然而,`owned_by_foo_team`无法访问Kubernetes资源。
审计扫描器
与AdmissionPolicy和ClusterAdmissionPolicy CRD类似,`backgroundAudit`字段指示在审计检查期间是否包含策略组。