我已经在谷歌的容器注册表中为我的图像启用了自动漏洞扫描，现在我正在考虑使用二进制授权，让我的云运行服务只为通过策略的图像部署。
我通读了文档https://cloud.google.com/binary-authorization/docs/creating-attestations-kritis因此，我需要创建一个证明人，使用这个kritis签名人签署一个图像，并根据我的策略创建证明，然后才能部署云运行服务。
我想知道这一切对我来说是否真的有必要。
在我的Github Actions CI/CD管道中，我可以使用gcloud命令gcloud beta container images describe HOSTNAME/PROJECT_ID/IMAGE_ID@sha256:HASH --show-package-vulnerability来查看新上传和扫描的映像的漏洞，如果我在使用新映像部署云运行服务之前发现任何严重性(例如严重性(的漏洞，甚至忽略某些CVE，我的管道就会失败。所以我基本上可以实现与这里政策中可用的选项相同的效果https://github.com/grafeas/kritis/blob/HEAD/samples/signer/policy.yaml由kritis签名者使用。
gcloud命令似乎比实现使用kritis签名器工具、创建证明等整个过程简单得多。
那么，为什么我应该使用二进制授权并遵循该过程，而不是在我的CI/CD管道中使用gcloud过滤器检查，有什么优势或安全原因吗？
提前感谢您的帮助。
有两个不同的层：
- 一方面，您检查您的容器是否包含任何已知的漏洞
- 另一方面，二进制授权，检查您是否从授权的注册表部署了容器
想象一下这种情况：
- 您正确检查了CI/CD管道中的容器CVE，并将其存储在注册表中
- 有人从另一个注册表部署容器
即使您在注册表中检查了您的容器，也无法保护Cloud Run免受来自其他注册表的部署的影响。
所以，你所有的努力都是徒劳的！