本文档采用自动化机器翻译技术翻译。尽管我们力求提供准确的译文，但不对翻译内容的完整性、准确性或可靠性作出任何保证。若出现任何内容不一致情况，请以原始英文版本为准，且原始英文版本为权威文本。

这是尚未发布的文档。 Admission Controller 1.34-dev.

快速入门

SUSE Security Admission Controller堆栈包括：

一个或多个ClusterAdmissionPolicy资源：这定义了Kubernetes集群的策略。
一个或多个PolicyServer资源：表示Admission Controller的部署`PolicyServer`。Admission Controller `PolicyServer`加载并评估您的管理员策略。
一个或多个AdmissionPolicy资源：为定义的名称空间提供策略。
一个`kubewarden-controller`的部署：该控制器监视ClusterAdmissionPolicy资源并与Admission Controller PolicyServer组件交互。

Admission Controller描述其Kubernetes自定义资源定义（CRDs）在这里。

本教程及其余文档中提到的Admission Controller CRDs具有简短名称，更易于使用。这些是CRDs的简短名称：

资源

shortName

AdmissionPolicies

ClusterAdmissionPolicies

cap

AdmissionPolicyGroups

apg

ClusterAdmissionPolicyGroups

capg

PolicyServers

安装

身份验证

您可以从GitHub容器注册表中检索Admission Controller策略，地址为https://ghcr.io.。使用Admission Controller CLI访问该储存库需要身份验证，您需要一个https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens[GitHub个人访问令牌]（PAT）。如果您尚未创建，文档将指导您完成创建过程。然后，您可以使用类似以下的命令进行身份验证：

echo $PAT | docker login ghcr.io --username <my-gh-username> --password-stdin

使用`helm`图表按如下方式部署Admission Controller堆栈：

helm repo add kubewarden https://charts.kubewarden.io

helm repo update kubewarden

在您的Kubernetes集群中，在`kubewarden`名称空间中安装以下Helm图表：

kubewarden-crds，它注册了ClusterAdmissionPolicy、AdmissionPolicy和PolicyServer自定义资源定义。此外，审计扫描仪使用的{report}自定义资源定义。
kubewarden-controller，它安装了Admission Controller控制器和审计扫描仪。

如果您需要禁用审计扫描仪组件，请查看审计扫描仪安装文档页面。
kubewarden-defaults，它创建了一个名为`PolicyServer`的`default`资源。它还可以安装一组推荐的策略，以通过强制执行公认的最佳实践来保护您的集群。

helm install --wait -n kubewarden --create-namespace kubewarden-crds kubewarden/kubewarden-crds

helm install --wait -n kubewarden kubewarden-controller kubewarden/kubewarden-controller

helm install --wait -n kubewarden kubewarden-defaults kubewarden/kubewarden-defaults

由于https://github.com/kubewarden/kubewarden-controller/releases/tag/v0.4.0[v0.4.0]，未使用`kubewarden-controller`图表创建名为`PolicyServer`的`default`资源。现在，一个名为`kubewarden-defaults`的Helm图表安装默认策略服务器。

这意味着如果在升级或删除时未使用最新版本的`kubewarden-controller`，则您的默认策略服务器不会被升级或删除。因此，如果您尝试安装具有冲突信息的`kubewarden-defaults`，例如相同的策略服务器名称，可能会遇到问题。要安装`kubewarden-defaults` Helm图表的未来升级，请在安装新图表之前去除由`PolicyServer`创建的现有`kubewarden-controller`资源。现在，您可以使用Helm升级更新您的策略服务器，而不会发生资源冲突。当您去除`PolicyServer`时，您也会去除与之绑定的所有策略。

默认配置值对于大多数部署来说是足够的。https://charts.kubewarden.io/#configuration[文档]描述了所有选项。

主要组件

Admission Controller有三个主要组件供您交互：

`PolicyServer`

kubewarden-controller`管理一个Admission Controller `PolicyServer。您可以在同一个Kubernetes集群中部署多个PolicyServer。

一个 PolicyServer 通过对传入请求执行 Admission Controller 策略来验证它们。

这是默认的 PolicyServer 配置：

apiVersion: policies.kubewarden.io/v1
kind: PolicyServer
metadata:
  name: reserved-instance-for-tenant-a
spec:
  image: ghcr.io/kubewarden/policy-server:v1.3.0
  replicas: 2
  serviceAccountName: ~
  env:
    - name: KUBEWARDEN_LOG_LEVEL
      value: debug

检查最新发布的 PolicyServer 版本并更改标签以匹配。

PolicyServer 资源属性概述：

必需占位符说明

必需	占位符	说明
Y	`image`	容器镜像的名称
Y	`replicas`	所需实例的数量
N	`serviceAccountName`	用于 `ServiceAccount` 部署的 `PolicyServer` 名称。如果没有提供值，则使用安装名称空间中的默认 `ServiceAccount`，即 `kubewarden-controller`.
N	`env`	环境变量列表
N	`annotations`	注释列表

image

容器镜像的名称

replicas

所需实例的数量

serviceAccountName

用于 ServiceAccount 部署的 PolicyServer 名称。如果没有提供值，则使用安装名称空间中的默认 ServiceAccount，即 kubewarden-controller.

env

环境变量列表

annotations

注释列表

更改这些属性中的任何一个会导致使用新配置的 PolicyServer 部署。

ClusterAdmissionPolicy

ClusterAdmissionPolicy 资源是 Admission Controller 堆栈的核心。它定义了策略如何评估请求。

强制执行策略是 Kubernetes 管理员执行的最常见操作。您可以声明任意数量的策略，每个策略针对一个或多个 Kubernetes 资源（即 pods、Custom Resource 和其他）。您还可以指定应用于目标资源的操作类型。可用的操作有 CREATE、UPDATE、DELETE 和 CONNECT。

默认 ClusterAdmissionPolicy 配置：

apiVersion: policies.kubewarden.io/v1
kind: ClusterAdmissionPolicy
metadata:
  name: psp-capabilities
spec:
  policyServer: reserved-instance-for-tenant-a
  module: registry://ghcr.io/kubewarden/policies/psp-capabilities:v0.1.9
  rules:
    - apiGroups: [""]
      apiVersions: ["v1"]
      resources: ["pods"]
      operations:
        - CREATE
        - UPDATE
  mutating: true
  settings:
    allowed_capabilities:
      - CHOWN
    required_drop_capabilities:
      - NET_ADMIN

ClusterAdmissionPolicy 资源属性概述：

必需占位符说明

必需	占位符	说明
N	`policy-server`	标识现有的 `PolicyServer` 对象。只有这个 `PolicyServer` 实例服务于该策略。名为 `default` 的策略服务器在没有明确 `PolicyServer` 的情况下服务于一个 ClusterAdmissionPolicy。
Y	`module`	Admission Controller 策略的位置。以下方案是允许的：
N		- `registry`：从符合 OCI artifacts 的容器注册表下载策略。示例： `registry://<OCI registry/policy URL>`
N		- `http`， `https`：从常规 HTTP(s) 服务器下载策略。示例： `https://<website/policy URL>`
N		- `file`：从计算机文件系统中的文件加载策略。示例： `file:///<policy WASM binary full path>`
Y	`resources`	由策略评估的 Kubernetes 资源
Y	`operations`	API 服务器应将先前给定类型的哪些操作转发到此准入策略进行评估。
Y	`mutating`	为可以改变传入请求的策略设置此布尔值 `true`。
N	`settings`	一个自由格式的对象，包含策略配置值
N	`failurePolicy`	如果由策略评估的请求导致错误，则采取的行动。以下选项是允许的：
N		- `Ignore`：忽略调用 webhook 时的错误，API 请求继续。
N		- `Fail`：调用 webhook 时的错误导致入场失败，API 请求被拒绝。

policy-server

标识现有的 PolicyServer 对象。只有这个 PolicyServer 实例服务于该策略。名为 default 的策略服务器在没有明确 PolicyServer 的情况下服务于一个 ClusterAdmissionPolicy。

module

Admission Controller 策略的位置。以下方案是允许的：

- registry：从符合 OCI artifacts 的容器注册表下载策略。示例： registry://<OCI registry/policy URL>

- http， https：从常规 HTTP(s) 服务器下载策略。示例： https://<website/policy URL>

- file：从计算机文件系统中的文件加载策略。示例： file:///<policy WASM binary full path>

resources

由策略评估的 Kubernetes 资源

operations

API 服务器应将先前给定类型的哪些操作转发到此准入策略进行评估。

mutating

为可以改变传入请求的策略设置此布尔值 true。

settings

一个自由格式的对象，包含策略配置值

failurePolicy

如果由策略评估的请求导致错误，则采取的行动。以下选项是允许的：

- Ignore：忽略调用 webhook 时的错误，API 请求继续。

- Fail：调用 webhook 时的错误导致入场失败，API 请求被拒绝。

控制器注册了 ClusterAdmissionPolicy 资源 * 的 webhook scope。这意味着注册的 webhook 会转发所有与给定的 resources 和 operations 匹配的请求，无论是名称空间级别还是集群级别的资源。

AdmissionPolicy

AdmissionPolicy 是一个名称空间级别的资源。该策略仅处理针对定义了 AdmissionPolicy 的名称空间的请求。除此之外，AdmissionPolicy 和 ClusterAdmissionPolicy 资源之间没有功能上的差异。

AdmissionPolicy 需要 Kubernetes 1.21.0 或更高版本。这是因为 Admission Controller 使用了在 Kubernetes 1.21.0 中引入的 kubernetes.io/metadata.name 标签。

这些自定义资源的完整文档在这里或 docs.crds.dev 上。

示例：强制执行您的第一个策略

我们将使用 pod-privileged 策略。我们希望通过强制执行此策略来防止在我们的 Kubernetes 集群中创建特权容器。

让我们定义一个 ClusterAdmissionPolicy 来实现这一点：

kubectl apply -f - <<EOF
apiVersion: policies.kubewarden.io/v1
kind: ClusterAdmissionPolicy
metadata:
  name: privileged-pods
spec:
  module: registry://ghcr.io/kubewarden/policies/pod-privileged:v0.2.2
  rules:
  - apiGroups: [""]
    apiVersions: ["v1"]
    resources: ["pods"]
    operations:
    - CREATE
    - UPDATE
  mutating: false
EOF

这将产生以下输出：

clusteradmissionpolicy.policies.kubewarden.io/privileged-pods created

在实例化 ClusterAdmissionPolicy 后，状态变为 pending，并强制进行目标 PolicyServer 的滚动更新。在这个例子中，它是名为`PolicyServer`的`default`。您可以通过运行以下命令来监控滚动更新：

kubectl get clusteradmissionpolicy.policies.kubewarden.io/privileged-pods

您应该会看到以下输出：

NAME              POLICY SERVER   MUTATING   STATUS
privileged-pods   default         false      pending

一旦新策略准备就绪，kubewarden-controller 会注册一个 ValidatingWebhookConfiguration 对象来提供服务。

一旦每个实例的部署完成，ClusterAdmissionPolicy 状态变为 active PolicyServer。使用以下命令显示 ValidatingWebhookConfiguration：

kubectl get validatingwebhookconfigurations.admissionregistration.k8s.io -l kubewarden

您应该会看到以下输出：

NAME                          WEBHOOKS   AGE
clusterwide-privileged-pods   1          9s

一旦 ClusterAdmissionPolicy 激活并且 ValidatingWebhookConfiguration 注册，您可以测试该策略。

首先，您可以在 privileged 模式下创建一个带有容器 not 的 Pod：

kubectl apply -f - <<EOF
apiVersion: v1
kind: Pod
metadata:
  name: unprivileged-pod
spec:
  containers:
    - name: nginx
      image: nginx:latest
EOF

这将产生以下输出：

pod/unprivileged-pod created

Pod 创建成功。

现在，您可以创建一个至少带有一个容器 privileged 标志的 Pod：

kubectl apply -f - <<EOF
apiVersion: v1
kind: Pod
metadata:
  name: privileged-pod
spec:
  containers:
    - name: nginx
      image: nginx:latest
      securityContext:
          privileged: true
EOF

该策略拒绝创建 Pod，您应该看到以下消息：

Error from server: error when creating "STDIN": admission webhook "clusterwide-privileged-pods.kubewarden.admission" denied the request: Privileged container is not allowed

两个示例都没有定义 namespace，这意味着 default 名称空间是目标。然而，正如您在第二个示例中看到的，策略仍然适用。如前所述，这是因为范围是集群级别的，而不是针对特定名称空间。

卸装

您可以通过卸载 helm 图表来去除创建的资源，如下所示：

helm uninstall --namespace kubewarden kubewarden-defaults

helm uninstall --namespace kubewarden kubewarden-controller

helm uninstall --namespace kubewarden kubewarden-crds

在移除 helm 图表后，去除用于部署 Admission Controller 堆栈的 Kubernetes 名称空间：

kubectl delete namespace kubewarden

Admission Controller 包含一个 helm 预删除钩子，该钩子会去除所有 PolicyServer 和 kubewarden-controller。然后 kubewarden-controller 删除所有资源，因此在 helm 卸载执行时，确保 kubewarden-controller 正在运行是很重要的。

Admission Controller 删除 ValidatingWebhookConfiguration 和 MutatingWebhookConfiguration。请使用以下方法检查：

kubectl get validatingwebhookconfigurations.admissionregistration.k8s.io -l "kubewarden"

kubectl get mutatingwebhookconfigurations.admissionregistration.k8s.io -l "kubewarden"

如果这些资源没有被自动去除，请使用以下命令手动去除它们：

kubectl delete -l "kubewarden" validatingwebhookconfigurations.admissionregistration.k8s.io

kubectl delete -l "kubewarden" mutatingwebhookconfigurations.admissionregistration.k8s.io

总结

ClusterAdmissionPolicy 是集群操作员必须管理的内核资源。kubewarden-controller 模块会自动为运行策略所需的其他资源进行配置。

后续操作

现在，您准备好部署 Admission Controller了！查看 artifacthub.io 上的策略，或在 GitHub 上查看，或者重用以下章节中显示的现有 Rego 策略。

ArtifactHub 上可用策略的完整列表