测验：镜像验证与供应链

容器镜像签名证明了什么？

• 来源：图像来自特定密钥或特定管道标识
• 图像中没有已知的漏洞
• 镜像使用最新的基础镜像
• 图像的SBOM正确

当我向证明者再添加一个密钥时，所有图像突然都无法验证。最可能的原因是什么？

• 由于未指定 attestors.count，因此所有条目都应该通过，但图像未使用新密钥进行签名。
• rekor.url 不正确
• mutateDigest 已关闭
• 由于在 imageReferences 字段中使用变量，匹配不匹配。

在我打开 mutateDigest: true 的第二天，本应覆盖标签并删除 pod 以接收新图像的管道什么也没做。为什么？

• Pod 规范中留下的参考不是标签，而是用 @sha256: 修复的摘要，新的 Pod 也使用第一个固定图像。
• 策略正在阻止 Pod 删除
• 注册表缓存 TTL 为 60 分钟，因此在此期间不会使用新映像进行更新。
• verifyDigest 阻止 pod 重新创建

在无密钥验证中指定主体和发行人的最准确原因是什么？

• 通过完全跳过Rekor透明度日志查询来加速图像验证
• 用于注册表身份验证
• 计算摘要
• 修复哪个签名是由哪个 OIDC 提供商以及哪个身份（甚至是工作流路径和参考标签）创建的，确保没有有效的签名通过。

关于图像验证缓存，以下哪项是正确的？

• 这是一个安装级别设置，默认启用，最大密钥 1000，TTL 60 分钟。
• 为每个规则设置为策略中的一个字段
• 默认禁用，必须开启
• 缓存仅存储Rekor响应，不存储签名验证结果。

将映像移至内部镜像注册表后，所有签名验证均失败。最常见的原因和措施是什么？

• 镜像仅复制图像，并没有移动签名工件。在将签名位置指定为存储库或修改镜像管道之前，不应打开 Enforce。
• 镜像注册表的摘要与原始的不同。只需关闭验证摘要即可
• keyless不支持后视镜。应该改为静态密钥
• Kyverno版本较低。可以通过升级解决