集群准入环节对镜像来源的约束，核心答案是把好仓库白名单和签名验证两道关，在调度之前拦截一切不可信来源。这并非复杂的安全加固,而是Kubernetes供应链防线中最关键的一环。
为什么镜像来源约束必须卡在准入环节
镜像拉取发生在Pod调度之后、容器运行之前的Kubelet工作流中，如果只在拉取阶段做校验，风险点在于节点凭据泄露、镜像被篡改后替换、以及恶意工作负载已混入运行时。准入控制器（Admission Controller）在API Server层拦截请求，是整个集群唯一能在资源落盘前完成校验的关卡。
业内专家指出，大部分供应链攻击集中在镜像投毒和仓库劫持两个环节，准入环节的镜像来源约束能提前阻断这两类问题，避免运行时检测带来的延迟和误报，它管理的是“谁能把镜像跑起来”，而不是“镜像跑起来之后怎么处理”，这种前置拦截的思路，对多云、多集群环境尤其有效，集群规模越大,生产环境镜像来源管控的手段就越应该前置。
镜像仓库白名单和签名校验有哪些区别
两者的定位完全不同，仓库白名单解决的是“从哪拉”的问题，签名校验解决的是“是否被篡改”的问题，评测一个集群的镜像安全状态,只看其中一项都有遗漏。
仓库白名单适合处理已知的信任边界，比如企业只允许从内部Harbor或私有的镜像仓库拉取镜像，把docker.io、quay.io等公共仓库全部列入黑名单，这种策略直白、易执行，但无法防止内部仓库中镜像被恶意上传或篡改。
签名校验更进一步，使用cosign、Notation这类工具，在构建时对镜像进行签名；集群侧通过准入策略要求镜像必须携带有效签名才允许创建，它能识别出镜像是否被恶意替换、标签移动甚至中间人攻击，对比来看,两者存在明显差异：
- 校验时机：白名单发生在拉取源判断阶段，签名校验发生在镜像内容验证阶段
- 安全性：白名单是粗粒度管控，签名校验是内容级信任
- 运维成本：白名单几乎为零成本，签名校验需要接入CI流水线和密钥体系
- 适用场景：白名单适合快速收敛来源，签名校验适合生产环境强制合规
国内企业落地时，多数情况先做仓库白名单，再逐步引入签名校验，两个一起用,才能形成完整约束。
集群准入镜像来源控制怎么配置
具体操作可以从三个层面层层叠加，首先是静态配置层面的镜像仓库白名单，其次是动态校验层面的策略引擎,最后是自动化校验链路的签名机制。
用Pod Security Admission限制仓库地址
Kubernetes自带的Pod Security Standards并不直接支持镜像仓库过滤，但通过ValidatingAdmissionPolicy，可以用几行CEL表达式实现,以下是一个校验镜像仓库前缀的配置示例：
apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata:
name: image-source-policy
spec:
failurePolicy: Fail
matchConstraints:
resourceRules:
- apiGroups: [""]
apiVersions: ["v1"]
operations: ["CREATE", "UPDATE"]
resources: ["pods"]
validations:
- expression: "object.spec.containers.all(c, c.image.startsWith('harbor.internal.example.com/'))"
message: "镜像来源仅允许内网Harbor仓库"
将这类策略绑定到特定命名空间后，凡是绕过白名单的镜像创建请求都会在准入阶段被拒绝，这层控制直接、轻量，适合作为基础防线，相比kube-apiserver配置文件中的ImagePolicyWebhook方案，ValidatingAdmissionPolicy在配置复杂度上更低,也更容易在GitOps流水线中版本化管理。
用Kyverno做多仓库差异化管控
跨多个环境或租户时，不同团队可能使用不同镜像仓库，Kyverno这类策略引擎可以对不同命名空间应用不同规则，配置一个ClusterPolicy，按命名空间标签区分镜像源，可以做到某套业务只能使用对应仓库中的镜像,从而避免镜像被误用或混淆。
操作路径也简单：安装Kyverno Helm Chart，随后创建ClusterPolicy，编写最简单版本时只需要声明validate规则，检查image.registry字段是否匹配预期值，webhook模式下非匹配资源仍会放行,但生效范围内的Pod都会实时校验。
接入cosign强制签名验证
对镜像做完整校验，还需要在构建流水线中嵌入cosign，签名过程不占用集群资源，只在CI端增加一步执行操作，以GitLab CI为例，构建镜像之后加一个签名任务，用私钥对镜像摘要签名，之后在Kubernetes中禁用cosign verify-admission即可只运行已验证镜像。这套链路在Kubernetes 1.24以上版本中兼容性较好，整体改造量集中在一个小时左右的流水线维护。
生产环境落地避坑清单
准入环节的镜像约束，一旦配置不当会直接影响业务发布,以下踩坑点来自生产环境中比较常见的源头问题：
- 忽略InitContainer和临时容器的镜像来源，导致非受控镜像通过辅助容器混入Pod
- 先放行后审计的策略造成策略风险敞口扩大，上线后去掉审计模式时，拦截列表可能已经积累了不合规镜像
- 调度阶段绕过校验，部分场景下Pod通过CRD创建时未触发Webhook
- 策略范围过宽，给系统命名空间也加上了强制规则，导致部分系统组件本身无法启动
- 签名验证只覆盖最终镜像，没有覆盖镜像索引和生成清单本身
- 以成本为由跳过签名校验，只做仓库地址匹配
落地过程中，内部定一个明确的镜像来源分级标准会更接地气，例如把Harbor仓库划分为一级可信仓库（只接受签名镜像）、二级半可信仓库（运行非核心业务）、三级非可信仓库（需要命名空间隔离），这条分级标准可以根据企业的实际情况灵活调整,避免各团队各自为政。
多集群场景下还存在策略分散的问题，中大型企业普遍有3套以上集群，如果每个集群分别维护镜像约束策略，策略更新时带有时间差，风险窗口就会拉长，建议的做法是把策略声明集中存放在统一Git仓库中，通过GitOps方式分发到各集群，让“镜像来源约束”在全公司范围内保持完全一致。
哪些场景下镜像约束会失效
- Helm模板变量注入镜像地址的场景，如果用户在values中自定义了仓库地址，则需要策略引擎能识别最终的镜像值
- 节点层面直接拉取指定镜像，准入控制器只能管Pod对象，不介入kubelet的静态Pod和镜像预拉取行为
- 通过CRD的status字段更新镜像，因为只检查
CREATE、UPDATE操作是不够的 - 服务网格初始化容器，在注入sidecar容器时的镜像地址需要策略引擎针对webhook的注入结果再做一次校验
生产环境落地时，行业共识认为“先做镜像仓库白名单，再做签名验证，然后处理Webhook的排除和放行逻辑”这个顺序最为理性,直接切签名验证往往会因为CI链路不匹配导致业务阻断。
审计与可观测性设计
准入策略做得再好，没有日志和审计支撑就难以发现问题，部署生效后，需要从三个维度观察准入环节的拦截情况：阻断次数（有多少次被拒的调度请求）、拦截原因分布（哪些策略规则最好用）、误拦截率（策略目标与实际不匹配导致失败），这些指标可以帮助排除故障、持续优化策略。
时把集群名、命名空间、请求用户、目标镜像地址纳入日志字段，后续溯源时有据可查，让步策略绕过白名单时,也应在审计日志中保留相应记录。
镜像来源约束的演进方向
镜像来源约束正在从“准入拦截”向“供应链全链路验证”演进，不只是约束“哪儿来的镜像”，还要回答“这个镜像可信吗”“这个镜像去哪里了”，签名从本地密钥向KMS、TUF混合密钥管理演进；校准从单点Webhook向全链路策略执行演进。
政策层面，国内云安全合规要求（等保2.0和行业监管）对镜像来源可信有明确要求，实施策略前置的企业比重正在提升，从云原生计算基金会（CNCF）的供应链安全白皮书来看，容器镜像的准入控制已被列为软件供应链安全的基础实践，在规模较大的生产环境中，“可解释的镜像来源”几乎等同于工程团队的底线能力。
常见问题解答
问：集群准入已经只允许私有仓库来源了，还需要加签名校验吗？
需要，私有仓库无法防御内部人员误传入篡改后的镜像，如果某次提交含有恶意代码并被打上了合法标签，而YAML里引用的正好是该标签，Kubelet会直接拉取该镜像，签名校验能在准入环节识别“内容是否与构建时一致”,这是仓库地址过滤做不到的。
问：准入控制策略影响性能吗？
链式调用Webhook会增加API Server的请求延迟，不过实践中一般在个位数毫秒级别，对频繁调度批次的影响很小，如果策略复杂且包含外部API调用，建议按命名空间分流,只对关键业务启用全量校验。
问：多集群情况下可以通过统一策略管理镜像来源吗？
可以，使用GitOps方式将Kyverno Policy或ValidatingAdmissionPolicy统一分发到目标集群，由CI流水线完成策略更新，这样各集群的镜像来源约束保持同一套标准，策略变更通过代码审查再发布到集群,相比逐集群手动维护更可控。