准入插件 | 架构 | OpenShift Dedicated

关于准入插件
默认准入插件
Webhook 准入插件
Webhook 准入插件的类型
- 变更准入插件
- 验证准入插件
其他资源

准入插件用于帮助规范 OpenShift Dedicated 的功能。

关于准入插件

准入插件拦截对主 API 的请求以验证资源请求。在请求经过身份验证和授权后，准入插件确保遵循任何相关的策略。例如，它们通常用于执行安全策略、资源限制或配置要求。

准入插件作为准入链按顺序运行。如果序列中的任何准入插件拒绝请求，则整个链将中止并返回错误。

OpenShift Dedicated 为每种资源类型启用了一组默认的准入插件。这些对于集群的正常运行是必需的。准入插件会忽略它们不负责的资源。

除了默认值之外，还可以通过调用自定义 Webhook 服务器的 Webhook 准入插件动态扩展准入链。Webhook 准入插件有两种类型：变更准入插件和验证准入插件。变更准入插件首先运行，它可以修改资源和验证请求。验证准入插件验证请求并在变更准入插件之后运行，以便也可以验证变更准入插件触发的修改。

通过变更准入插件调用 Webhook 服务器可能会对与目标对象相关的资源产生副作用。在这种情况下，必须采取步骤来验证最终结果是否符合预期。

应谨慎使用动态准入，因为它会影响集群控制平面操作。在 OpenShift Dedicated 中通过 Webhook 准入插件调用 Webhook 服务器时，请确保已完整阅读文档并测试了突变的副作用。如果请求未通过整个准入链，请包含将资源恢复到突变之前的原始状态的步骤。

默认准入插件

OpenShift Dedicated 中启用了默认的验证和准入插件。这些默认插件有助于基本控制平面功能，例如入口策略、集群资源限制覆盖和配额策略。

不要在默认项目中运行工作负载或共享对默认项目的访问权限。默认项目保留用于运行核心集群组件。

以下默认项目被认为是高度特权的：`default`、`kube-public`、`kube-system`、`openshift`、`openshift-infra`、`openshift-node`以及其他具有 `openshift.io/run-level` 标签设置为 `0` 或 `1` 的系统创建的项目。依赖于准入插件的功能（例如 Pod 安全准入、安全上下文约束、集群资源配额和镜像引用解析）在高度特权的项目中不起作用。

以下列表包含默认准入插件

验证准入插件

LimitRanger
ServiceAccount
PodNodeSelector
Priority
PodTolerationRestriction
OwnerReferencesPermissionEnforcement
PersistentVolumeClaimResize
RuntimeClass
CertificateApproval
CertificateSigning
CertificateSubjectRestriction
autoscaling.openshift.io/ManagementCPUsOverride
authorization.openshift.io/RestrictSubjectBindings
scheduling.openshift.io/OriginPodNodeEnvironment
network.openshift.io/ExternalIPRanger
network.openshift.io/RestrictedEndpointsAdmission
image.openshift.io/ImagePolicy
security.openshift.io/SecurityContextConstraint
security.openshift.io/SCCExecRestrictions
route.openshift.io/IngressAdmission
config.openshift.io/ValidateAPIServer
config.openshift.io/ValidateAuthentication
config.openshift.io/ValidateFeatureGate
config.openshift.io/ValidateConsole
operator.openshift.io/ValidateDNS
config.openshift.io/ValidateImage
config.openshift.io/ValidateOAuth
config.openshift.io/ValidateProject
config.openshift.io/DenyDeleteClusterConfiguration
config.openshift.io/ValidateScheduler
quota.openshift.io/ValidateClusterResourceQuota
security.openshift.io/ValidateSecurityContextConstraints
authorization.openshift.io/ValidateRoleBindingRestriction
config.openshift.io/ValidateNetwork
operator.openshift.io/ValidateKubeControllerManager
校验Webhook
资源配额
quota.openshift.io/ClusterResourceQuota

更改admission插件

命名空间生命周期
LimitRanger
ServiceAccount
节点限制
根据条件污染节点
PodNodeSelector
Priority
默认容忍秒数
PodTolerationRestriction
默认存储类
存储对象正在使用保护
RuntimeClass
默认 Ingress 类
autoscaling.openshift.io/ManagementCPUsOverride
scheduling.openshift.io/OriginPodNodeEnvironment
image.openshift.io/ImagePolicy
security.openshift.io/SecurityContextConstraint
security.openshift.io/DefaultSecurityContextConstraints
更改Admission Webhook

Webhook admission 插件

除了 OpenShift Dedicated 默认的 admission 插件外，还可以通过调用 webhook 服务器的 webhook admission 插件来实现动态 admission，以扩展 admission 链的功能。Webhook 服务器通过 HTTP 在定义的端点进行调用。

OpenShift Dedicated 中有两种类型的 webhook admission 插件

在 admission 过程中，*更改 admission 插件*可以执行一些任务，例如注入亲和性标签。

在 admission 过程结束时，可以使用*校验 admission 插件*来确保对象配置正确，例如确保亲和性标签符合预期。如果验证通过，OpenShift Dedicated 将按照配置调度对象。

当 API 请求到来时，更改或校验 admission 插件将使用配置中的外部 webhook 列表并并行调用它们。

如果所有 webhook 都批准了请求，则 admission 链将继续。
如果任何 webhook 拒绝了请求，则 admission 请求将被拒绝，拒绝的原因基于第一个拒绝。
如果多个 webhook 拒绝了 admission 请求，则只将第一个拒绝原因返回给用户。
如果在调用 webhook 时遇到错误，则根据设置的错误策略拒绝请求或忽略 webhook。如果错误策略设置为忽略，则在发生故障时无条件接受请求。如果策略设置为失败，则拒绝失败的请求。使用忽略可能会导致所有客户端出现不可预测的行为。

下图说明了其中调用多个 webhook 服务器的顺序 admission 链过程。

图 1. 带有更改和校验 admission 插件的 API admission 链

Webhook admission 插件的一个示例用例是所有 Pod 都必须具有通用标签集。在此示例中，更改 admission 插件可以注入标签，而校验 admission 插件可以检查标签是否符合预期。随后，OpenShift Dedicated 将调度包含所需标签的 Pod 并拒绝不包含所需标签的 Pod。

一些常见的 webhook admission 插件用例包括：

命名空间预留。
限制由 SR-IOV 网络设备插件管理的自定义网络资源。
Pod 优先级类验证。

OpenShift Dedicated 中最大的默认 webhook 超时值为 13 秒，并且无法更改。

Webhook admission 插件类型

集群管理员可以通过 API 服务器 admission 链中的更改 admission 插件或校验 admission 插件来调用 webhook 服务器。

更改 admission 插件

更改 admission 插件在 admission 过程的更改阶段被调用，允许在资源持久化之前修改资源内容。一个可以通过更改 admission 插件调用的 webhook 示例是 Pod 节点选择器功能，它使用命名空间上的注释来查找标签选择器并将其添加到 pod 规范中。

更改 admission 插件配置示例

apiVersion: admissionregistration.k8s.io/v1beta1
kind: MutatingWebhookConfiguration (1)
metadata:
  name: <webhook_name> (2)
webhooks:
- name: <webhook_name> (3)
  clientConfig: (4)
    service:
      namespace: default (5)
      name: kubernetes (6)
      path: <webhook_url> (7)
    caBundle: <ca_signing_certificate> (8)
  rules: (9)
  - operations: (10)
    - <operation>
    apiGroups:
    - ""
    apiVersions:
    - "*"
    resources:
    - <resource>
  failurePolicy: <policy> (11)
  sideEffects: None

1	指定更改 admission 插件配置。
2	`MutatingWebhookConfiguration` 对象的名称。将`<webhook_name>`替换为适当的值。
3	要调用的 webhook 的名称。将`<webhook_name>`替换为适当的值。
4	关于如何连接、信任和向 webhook 服务器发送数据的信息。
5	创建前端服务的命名空间。
6	前端服务的名称。
7	用于 admission 请求的 webhook URL。将`<webhook_url>`替换为适当的值。
8	签署 webhook 服务器使用的服务器证书的 PEM 编码 CA 证书。将`<ca_signing_certificate>`替换为 base64 格式的适当证书。
9	定义 API 服务器何时应使用此 webhook admission 插件的规则。
10	一个或多个触发 API 服务器调用此 webhook admission 插件的操作。可能的值为`创建`、`更新`、`删除`或`连接`。将`<operation>`和`<resource>`替换为适当的值。
11	指定如果 webhook 服务器不可用，策略应如何继续。将`<policy>`替换为`忽略`（在发生故障时无条件接受请求）或`失败`（拒绝失败的请求）。使用`忽略`可能会导致所有客户端出现不可预测的行为。

在 OpenShift Dedicated 中，用户或通过更改 admission 插件的控制循环创建的对象可能会返回意外的结果，尤其是在初始请求中设置的值被覆盖时，这是不推荐的。

校验 admission 插件

校验 admission 插件在 admission 过程的验证阶段被调用。此阶段允许对特定 API 资源强制执行不变性，以确保资源不再更改。Pod 节点选择器也是校验 admission 插件调用的 webhook 示例，以确保所有nodeSelector字段都受命名空间上的节点选择器限制约束。

校验 admission 插件配置示例

apiVersion: admissionregistration.k8s.io/v1beta1
kind: ValidatingWebhookConfiguration (1)
metadata:
  name: <webhook_name> (2)
webhooks:
- name: <webhook_name> (3)
  clientConfig: (4)
    service:
      namespace: default  (5)
      name: kubernetes (6)
      path: <webhook_url> (7)
    caBundle: <ca_signing_certificate> (8)
  rules: (9)
  - operations: (10)
    - <operation>
    apiGroups:
    - ""
    apiVersions:
    - "*"
    resources:
    - <resource>
  failurePolicy: <policy> (11)
  sideEffects: Unknown

1	指定校验 admission 插件配置。
2	`ValidatingWebhookConfiguration` 对象的名称。将`<webhook_name>`替换为适当的值。
3	要调用的 webhook 的名称。将`<webhook_name>`替换为适当的值。
4	关于如何连接、信任和向 webhook 服务器发送数据的信息。
5	创建前端服务的命名空间。
6	前端服务的名称。
7	用于 admission 请求的 webhook URL。将`<webhook_url>`替换为适当的值。
8	签署 webhook 服务器使用的服务器证书的 PEM 编码 CA 证书。将`<ca_signing_certificate>`替换为 base64 格式的适当证书。
9	定义 API 服务器何时应使用此 webhook admission 插件的规则。
10	一个或多个触发 API 服务器调用此 webhook admission 插件的操作。可能的值为`创建`、`更新`、`删除`或`连接`。将`<operation>`和`<resource>`替换为适当的值。
11	指定如果 webhook 服务器不可用，策略应如何继续。将`<policy>`替换为`忽略`（在发生故障时无条件接受请求）或`失败`（拒绝失败的请求）。使用`忽略`可能会导致所有客户端出现不可预测的行为。

其他资源

Pod 优先级名称