测验：安全与策略执行

尽管 CI 拒绝未签名的图像，但还有其他分发途径。最合适的补充是什么？

• 我们增加了 CI 日志的保留期限，并确定所有 API 路径也被阻止。
• 检查现有资源的报告取代了对未来 API 请求的拒绝。
• 审查准入范围和例外情况并实际测试授予/拒绝请求
• 仅检查 webhook 的准备情况并跳过任何不符合策略的输入测试。

我使用标准 NetworkPolicy 限制了连接范围。关于服务之间的身份验证和加密的正确决策是什么？

• TLS 和身份认证是分开的，必须在 Mesh 或应用程序中配置。
• 不需要单独的身份验证，因为允许的 pod 标签会替换证书标识。
• 只需允许 TCP 443，API 将验证证书，从而保证 mTLS。
• 如果有默认拒绝，则接受的连接的正文也会自动加密。

审核策略中的第一条规则是针对所有请求的 RequestResponse，然后是针对 Secret 的元数据规则。正确的做法是什么？

• Secret 是 base64，因此它保留顺序并且仅缩短保留期
• 后面的具体规则优先，因此保留设置并仅确认收集。
• 将 Secret 更改为 None 将取消先前规则正文的集合。
• 首先放置敏感资源规则并测试记录存在和身体不存在

您应该检查使用该标签部署的服务的运行版本。处理证据的适当方式是什么？

• 查找当前标签指向的镜像，并将其视为所有过去 Pod 的可执行副本。
• 收集运行时 imageID 和部署记录以链接摘要/构建证据
• 由于我们是通过tag部署的，所以我们也无法从当前pod中获取镜像识别信息。
• 获得摘要后，您还可以从哈希中恢复作者和源提交。

图像签名验证通过，并收到单独的 SBOM 文件。在决定部署之前我还应该检查哪些内容？

• 由于图像签名还验证相邻文件，因此只需匹配 SBOM 的文件名即可。
• 如果 SBOM 中至少有一个包，则该图像的链接也被视为已确认。
• 分别验证 SBOM 证据和目标摘要连接的可靠性
• 如果一起存储在注册表中，则跳过构建者身份验证

转换策略填充了缺失的标签，验证策略允许该请求。哪个结论是有效的？

• 验证可以检查修改的对象，因此不能仅仅允许就认为未执行。
• 由于验证仅查看原始对象，因此 API 服务器会忽略策略冲突。
• 成功转换的请求会被接受，因为它们会自动跳过验证步骤。
• 首先运行验证以允许未标记的对象，然后完成转换。