Trivy-Operator 通过周期性轮询 Kubernetes API 获取镜像并调用 Trivy 离线扫描,非实时 hook;需确保声明一致、策略合理、凭证可达,并配置 scanAllRunningPods、注解、命名空间筛选、私有仓库认证、缓存刷新及漏洞库更新,再集成 Prometheus、Policy Reporter 或 CI/CD 实现安全闭环。

Trivy-Operator 并不实时 hook 容器启动过程,它的“持续监控”本质是周期性轮询 Kubernetes API,提取 Pod、Deployment 等资源中声明的镜像字段,再调用 Trivy 扫描器执行离线分析。要让这套机制真正覆盖集群中正在运行的镜像,关键在于确保声明与实际一致、扫描策略配置合理、凭证与网络可达。
让新 Pod 被及时扫描
默认情况下,Trivy-Operator 每 60 分钟轮询一次(ReconcilePeriod),刚创建的 Pod 不会立刻触发扫描。想缩短延迟,有以下可行方式:
- 在 Helm values 或 TrivyConfig 中启用 scanAllRunningPods: true,它会主动遍历所有 Running 状态的 Pod 进行扫描
- 为工作负载资源(如 Deployment)添加注解:trivy-operator.aquasecurity.github.io/scan: "true"
- 限制扫描范围,避免性能压力:配合 namespaceSelector 只作用于高敏感命名空间(例如
production或security-critical)
正确扫描私有仓库镜像
能否拉取镜像,取决于 Trivy 扫描 Job 是否能复用原 Pod 的拉取凭据。常见遗漏点包括:
评估 Kubernetes 集群安全态势,覆盖 RBAC、工作负载安全、网络策略、基础设施即代码(IaC)、运行时监控和密钥管理等 30 项控制项……
- 确保目标命名空间中已存在有效的 imagePullSecrets,且 Operator 部署时通过
trivy.imagePullSecrets(Helm)或credentials字段(TrivyConfig CR)明确引用 - 若镜像地址含端口(如
harbor.example.com:8443/app:v1),需确认 Operator 所在节点可访问该地址,并处理证书信任问题(可通过insecureRegistries临时跳过验证,生产环境建议导入 CA) - 示例 TrivyConfig 片段中,
registry值必须与镜像 URL 中的 registry host + port 完全匹配,否则凭证不会被使用
避免扫描结果陈旧
Trivy-Operator 默认启用两级缓存,容易导致报告未更新。排查方向如下:
- 检查 ConfigMap 缓存是否生效:扫描 Job 会在命名空间中创建名为
trivy-cache的 ConfigMap,存储历史扫描摘要;可手动删除该 ConfigMap 强制刷新 - 确认镜像 digest 是否未变:Trivy 默认跳过相同 digest 的重复扫描;如果只是 tag 更新但底层 digest 不变(如反复 push 同一构建产物),漏洞结果就不会刷新
- 同步漏洞数据库:Trivy 内置的漏洞库需定期更新;可通过设置
trivy.dbRepository指向可信镜像仓库,并启用自动更新(trivy.autoUpdate: true)
把扫描结果变成可用的安全信号
原始 VulnerabilityReport CR 只是数据载体,需进一步集成才能形成闭环:
- 对接 Prometheus:启用
metrics.serviceMonitor.enabled和prometheusRule.enabled,利用trivy_vulnerability_count{severity=~"CRITICAL|HIGH"}设置告警阈值 - 接入 Policy Reporter:部署
trivy-operator-polr-adapter,将 VulnerabilityReport 自动转成标准PolicyReport,即可在 Grafana Dashboard 查看趋势、导出合规报表、推送 Slack 告警 - 在 CI/CD 流水线中前置拦截:通过
kubectl get vulnerabilityreports -l trivy-operator.aquasecurity.github.io/report-type=vulnerability --field-selector status.scanStatus=Completed查询结果,结合jq提取 HIGH+CRITICAL 数量做门禁判断

















