请求抵达 etcd 之前 — 准入这个位置

一句话总结

政策引擎不是魔法，而是让API服务器在保存请求之前问别人的一个钩子，要知道那个钩子插在哪里，才能理解政策为什么不被接受，为什么会停止群集。

为什么需要这个？

RBAC回答了“谁可以做什么”。如果给开发者赋予创建板块的权限，就可以创建板块。但是组织真正想要的是下一个问题。**“可以创建，但必须是这样的形状。”**图像只有在内部注册表中，资源限制必须，latest标签是禁止的，标签会遵循标准。RBAC的动词（verb）和资源类型无法表达这个条件。因为权限是“创建”这一行为单位，而创建的对象的内容是没有眼睛的。

所以人们长期以来一直用人来填补这个差距。在维基百科上写标准，在PR评论中指出，在发布后用扫描仪回过头来发现错误。这三种方法都有同样的弱点。**没有强制力，或者已经进入后才发现。**不通过评论的路线（kubectl apply如果有一项直接执行、CI绕过、其他团队的头盔排行榜），规则就会重新开始。

访问控制通过结构解决了这个问题。规则放在不是人而是API服务器必须经过的十字路口。没有不经过那个十字路口进入群集的对象，所以无论路径有多少条，规则只要放在一个地方就可以了。

怎么行动

kubectl apply一次在API服务器中经过的顺序是这样的。

요청 → 인증(Authentication) → 인가(Authorization/RBAC)
     → 뮤테이팅 어드미션(Mutating Admission)
     → 스키마 검증(Object Schema Validation)
     → 밸리데이팅 어드미션(Validating Admission)
     → etcd 저장

在这里必须抓住的四个事实是。

**第一，授权先于一切。**如果没有权限，政策根本不会被评估。政策不是代替RBAC的东西，而是再次跳过通过RBAC的请求的东西。如果把两个顺序颠倒过来，就会出现“通过政策授予权限”这样的错误设计。

**第二，变形比验证更重要。**这个顺序不是偶然，而是设计。填充基本值后才进行检查，才会形成“虽然没有写资源限制，但政策填充了，所以通过”这样的流程。同时陷阱也由此而来。**验证规则所看到的对象是变形规则操作后的对象。**如果同时设置了注入侧卡的变形政策和要求所有容器设置限制的验证政策，但没有在注入规格中设置限制，那么发布就会被阻止，日志上就会写上用户没有使用的容器名称。这是自己政策所约束的典型形式。

**第三，模式验证就在中间。**如果变形规则创建了模式中没有的字段，就会在这里遇到问题。政策创造的结果最终也必须是容器对象。

**第四，网络钩子是网络呼叫。**API服务器向外部页面发送HTTP请求，等待回复。所以两个安全机制附着在网络钩子设置上。

设置	含义	写错的话
timeoutSeconds	等待响应的时间（基本10秒，最大30秒）	如果长时间等待，在发生故障时，API服务器会被挂住。
failurePolicy: Fail	如果Webhook无法响应，则拒绝请求	政策引擎死亡时，整个群集的所有写入都将被阻止。
failurePolicy: Ignore	如果Webhook无法响应，请求通过	在政策引擎死机期间，无需检查即可全部接收。
namespaceSelector	只让特定命名空间进入Webhook	如果不进入，甚至依赖kube-system的Webhook

failurePolicy是这条路线中最重要的一条。Fail虽然保护了安全，但政策引擎的可用性就是群集的可用性的意思。如果所有访问控制器板都下线，板、配置图甚至试图恢复该控制器的部署都会被阻止。陷入循环。所以namespaceSelector罗kube-system关于政策引擎，将自己的命名空间从Webhook对象中移除不是个人喜好，而是留出出口。在实际运营中，完全删除Webhook设置并恢复群集的程序也一样，原因也在于运行手册中包含了相关流程。

将所有资源匹配为野生卡的政策危险的原因也由此而来。该政策的成本不是政策本身的执行时间，而是API服务器接收的所有请求的延迟费。将匹配范围缩小到种类和命名空间的工作不是性能调优，而是可用性工作。

在现场相遇的样子

**第一，“政策一点也不阻止”。无论怎么盯着政策YAML看，都没有答案。一般原因是网络钩子没有被注册，或者匹配块与实际请求不匹配，什么都不匹配。什么都不匹配的政策会悄悄地全部通过，所以在政策制定时，需要养成把要通过的资源和要阻止的资源都放进去试试的习惯。**所以，在制定政策时，需要把要通过的资源和要阻止的资源都放进去试试的习惯。

**第二，网络钩子故障扩散为全面故障时。**三个访问控制器聚集在同一个节点上，然后该节点丢失的话failurePolicy: Fail以下，整个群集的写入停止。增加副本、设置PodDisruptionBudget、强制节点分散是政策引入的必经程序。

第三，这个实践环境的真实局限性。这个环境的kwok群集虽然有真正的etcd·API服务器·控制器管理器·调度器，但政策引擎控制器并不漂浮。所以错误的padkubectl apply即使这样，聚类也不会阻止。后台扫描也不会运行，generate规则创建的资源也不会实际生成。相反kyverno通过CLI将政策引擎本地运行，可以查看相同的判断逻辑。本文的网页链接顺序·failurePolicy·超时不是实践，而是通过阅读和测验来掌握，在实践中培养使用政策本身的能力。

在下次确认中看到的东西

在接下来的测验中，录取顺序、网络链接超时和failurePolicy，Audit·Enforce的 首先区分适用时间。确认了那个概念后，在下一个模块要求必备标签的 ClusterPolicy写上通过·拒绝的图片。