Kyverno准入控制器未拦截未签名镜像：无密钥签名镜像验证策略失效排查

我明白你现在遇到的头疼问题——明明参照教程配置了Kyverno的无密钥镜像验证策略，但它就是不拦截未签名的镜像，反而让不符合要求的Pod顺利创建了。结合你给出的策略文件和场景，我整理了几个核心排查方向，你可以一步步核对：

1. 镜像匹配规则是否精准匹配实际部署的镜像 #

你的策略里imageReferences指定的是"localhost:5000/nginx_signed"，这里要注意几个细节：

• 实际部署的镜像是否带有标签？比如如果你部署的是localhost:5000/nginx_signed:v1，而策略里没带标签，Kyverno的精确匹配会忽略这个镜像，导致策略不生效。可以改成通配符匹配该仓库下所有镜像："localhost:5000/nginx_signed*"，或者带上具体标签确保完全匹配。
• 检查镜像名的拼写、大小写是否完全一致，镜像名是严格区分大小写的，哪怕一个字符错了都会导致匹配失败。

2. 无密钥验证的参数是否与签名时完全一致 #

策略里的subject和issuer必须和你用Cosign签名时的参数完全匹配：

• 确认签名时使用的邮箱确实是xxx@gmail.com，有没有拼写错误（比如少了字符、域名写错）。
• 虽然你配置的Rekor URL是正确的，但可以检查Kyverno Pod能否正常访问Rekor服务：进入Kyverno Pod执行curl https://rekor.sigstore.dev，如果网络不通，Kyverno无法拉取签名记录，会直接跳过验证。

3. 策略的作用范围是否覆盖了实际的资源类型 #

你的策略当前只匹配Pod资源，但如果是通过Deployment、StatefulSet这类控制器创建的Pod，Kyverno默认会先验证控制器资源而非直接验证Pod。可以扩展match规则里的资源类型，覆盖常见的工作负载：

match:
  any:
    - resources:
        kinds:
          - Pod
          - Deployment
          - StatefulSet
          - DaemonSet

另外，ClusterPolicy是集群级资源，不需要在metadata里指定namespace，虽然不会报错，但建议去掉这个冗余配置，避免潜在的范围问题。

4. 手动验证镜像签名的有效性 #

先跳过Kyverno，用Cosign手动验证你的镜像，确认签名本身是有效的：

cosign verify --keyless --issuer https://accounts.google.com --subject xxx@gmail.com localhost:5000/nginx_signed

如果手动验证失败，说明签名过程本身有问题，需要重新执行签名命令：

cosign sign --oidc-issuer https://accounts.google.com localhost:5000/nginx_signed

签名时要确保你授权的邮箱是xxx@gmail.com，避免用错账号。

5. 查看Kyverno日志定位具体问题 #

最直接的排查方式是查看Kyverno Pod的日志，搜索你的策略名kyverno，看看有没有执行时的报错信息：

kubectl logs -n kyverno <kyverno-pod-name> | grep "kyverno"

常见的报错比如failed to verify image、no matching attestors found、Rekor API request failed等，这些日志能直接告诉你策略失效的具体原因。

备注：内容来源于stack exchange，提问作者Som