准入插件 | 架构 | Red Hat OpenShift Service on AWS

关于准入插件
默认准入插件
Webhook 准入插件
Webhook 准入插件类型
- 修改型准入插件
- 验证型准入插件
其他资源

准入插件用于帮助规范 Red Hat OpenShift Service on AWS 的运行方式。

关于准入插件

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

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

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

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

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

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

编辑

默认准入插件

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

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

以下默认项目被认为是高度特权的：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
ValidatingAdmissionWebhook
ResourceQuota
quota.openshift.io/ClusterResourceQuota

修改型准入插件

NamespaceLifecycle
LimitRanger
ServiceAccount
NodeRestriction
TaintNodesByCondition
PodNodeSelector
Priority
DefaultTolerationSeconds
PodTolerationRestriction
DefaultStorageClass
StorageObjectInUseProtection
RuntimeClass
DefaultIngressClass
autoscaling.openshift.io/ManagementCPUsOverride
scheduling.openshift.io/OriginPodNodeEnvironment
image.openshift.io/ImagePolicy
security.openshift.io/SecurityContextConstraint
security.openshift.io/DefaultSecurityContextConstraints
MutatingAdmissionWebhook

编辑

Webhook 准入插件

除了 Red Hat OpenShift Service on AWS 默认准入插件外，还可以通过调用 webhook 服务器的 webhook 准入插件实现动态准入，以扩展准入链的功能。Webhook 服务器通过 HTTP 在定义的端点上被调用。

Red Hat OpenShift Service on AWS 中有两种类型的 webhook 准入插件

在准入过程中，修改型准入插件可以执行诸如注入亲和性标签之类的任务。

在准入流程结束时，可以使用验证准入插件来确保对象的配置正确，例如确保亲和性标签符合预期。如果验证通过，Red Hat OpenShift Service on AWS 会按照配置调度对象。

当 API 请求到来时，变异或验证准入插件会使用配置中的外部 Webhook 列表并并行调用它们。

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

下图说明了调用多个 Webhook 服务器的顺序准入链流程。

图 1. 带有变异和验证准入插件的 API 准入链

Webhook 准入插件的一个示例用例是所有 Pod 都必须具有共同的标签集。在此示例中，变异准入插件可以注入标签，而验证准入插件可以检查标签是否符合预期。Red Hat OpenShift Service on AWS 随后将调度包含所需标签的 Pod 并拒绝不包含所需标签的 Pod。

一些常见的 Webhook 准入插件用例包括：

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

Red Hat OpenShift Service on AWS 中最大的默认 Webhook 超时值为 13 秒，并且无法更改。

Webhook 准入插件类型

集群管理员可以通过 API 服务器准入链中的变异准入插件或验证准入插件调用 Webhook 服务器。

编辑

变异准入插件

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

变异准入插件配置示例

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

在 Red Hat OpenShift Service on AWS 中，用户或控制循环通过变异准入插件创建的对象可能会返回意外的结果，尤其是在初始请求中设置的值被覆盖的情况下，这并不推荐。

验证准入插件

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

验证准入插件配置示例

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

编辑

其他资源

Pod 优先级名称