测验：策略方向与证据

API IP为200，但服务名称超时。更改出口后，哪个比较最有用？

• 维护同源IP控制组并检查DNS 53流量和策略。
• 由于服务器的Ready为true，所以首先改变客户端的HTTP方法。
• 只有名称请求失败，因此增加服务器副本并再次合并两个路径。
• 由于HTTP 000是服务器错误，因此只能通过API日志确认故障级别。

NamespaceSelector 和 podSelector 一起包含在标准 NetworkPolicy 的一项中。怎么读呢？

• 在两个选择器中，第一个同步的选择器确定通信伙伴的范围。
• 在所选命名空间内选择满足 Pod 选择器的合作伙伴。
• 由于每个选择器都是不同的允许语句，因此两个选择器中只有一个是正确的。
• 由于存在namespaceSelector，因此API会忽略podSelector。

两个命名空间的客户端 Pod 都有 role=client。如何比较Cilium身份？

• 由于是同一角色，因此即使数字ID不同，也会记录相同的身份。
• 如果您只比较不同的 IP，则无需阅读身份标签。
• 查看安全标签集，包括命名空间和 CEP 身份。
• 如果 Pod 名称和容器镜像相同，则数字 ID 也将永久相同。

允许红色客户端的标准 NP 被添加到允许蓝色客户端的 CNP 中。如果没有单独拒绝，我应该检查什么？

• 检查是否只剩下满足两个策略的起点。
• 检查名称中的最后一个策略是否替换了现有的 CNP。
• CNP 优先于标准 NP，因此红队始终确保他们被阻止。
• 将两条允许的路径合并起来，以确保蓝队和红队都能通过。

虽然标准NP允许红色客户端访问API，但CNP ingressDeny也匹配该请求。预期结果是什么？

• 由于显式拒绝优先，因此红色请求会被拒绝，并且还会比较正常控制。
• 标准 Kubernetes API 优先，因此红色请求照常通过。
• 由于只读取最近创建的对象，因此需要创建时间来进行判断。
• 如果CNP和标准NP一起使用，则两者都无效，并且允许所有请求。

哈勃缓冲区中有一条 DROPPED 线。还需要做什么才能得出我们刚刚发送的 API 请求被策略阻止的结论？

• 单个 DROPPED 行就足够了，因此省略了 HTTP 响应。
• 匹配出发地、目的地、源端口、时间和身份并比较 HTTP 结果。
• 在应用策略之前，选择最旧的 DROPPED 作为基线。
• 如果仅服务器名称相同，则来自不同命名空间的流将被视为同一请求。