真准入确认

mutate 填写所有者标签，validate 需要所有者存在。如果没有其他拒绝条件怎么办？

• 由于修改后的请求得到验证，因此可以满足所有者条件。
• 由于仅验证原始请求，因此无法满足所有者条件。
• 因为是保存后修改的，所以第一次创建总是被拒绝。
• 两个策略的创建时间必须相同才能满足所有者条件。

有一个生成目标Namespace，控制器日志中留下了ConfigMap创建Forbidden。接下来怎么办？

• 将验证规则从审核更改为强制，然后重试。
• 检查后台服务帐号的目标资源权限。
• 增加变异 Webhook 等待检查的超时秒数。
• 清除目标命名空间标签并再次调用所有规则。

提交的 Pod 违反了其中一项审核政策。对于也有不同政策的集群，我们可以肯定地说什么呢？

• 如果至少有一项审核策略，则也会跳过其他验证。
• 如果存在审核违规，Pod 必须保持待处理状态。
• 此政策允许违规行为，但其他政策可能会拒绝违规行为
• 审计违规响应将被拒绝，并发出名为“警告”的失败操作。

kube-system except 已添加到标签策略中。我们还应该检查哪些内容，以确保系统请求即使在服务器发生故障时也能避免 Webhook 调用？

• 使用 PolicyReport 中的成功次数确认排除 Webhook 调用。
• 创建策略时检查 API 服务器上过滤器的应用情况。
• 根据现有系统Pod的运行状态检查新请求。
• 检查实际 WebhookConfiguration 的规则和选择器。

failurePolicy 设置为 Ignore 的 Webhook 返回 allowed:false 作为正常响应。这个请求怎么办？

• 由于显式拒绝有效，因此请求被拒绝
• 忽略设置优先，因此请求将被保存。
• 将验证更改为审核并重新提交请求。
• 清除 Webhook 注册并自动重试请求。

注册的 Fail webhook 超时。哪项陈述最准确地描述了残疾的范围？

• 所有现有 Pod 均被终止，所有 API 读取均被拒绝。
• 事实上，作为 webhook 调用目标的请求可能会被拒绝
• 策略对象消失，绕过所有新请求的验证。
• 如果存在规则排除，则始终忽略调用失败。