trivy k8s 默认仅扫描工作负载镜像，需加 --include-all-namespaces --report all --include-resources clusterroles,clusterrolebindings,roles,rolebindings 覆盖配置、密钥、漏洞三类风险，并用 --severity CRITICAL,HIGH 聚焦高危问题。
直接用 trivy k8s 扫描，别手写解析器——它能覆盖镜像漏洞、错误配置、密钥硬编码三类核心风险，且结果可直接对接 CI/CD 阻断逻辑。
trivy k8s 命令怎么选参数才不漏报
默认扫描只检查工作负载引用的镜像，容易忽略 ConfigMap、Secret、RBAC 等配置风险。必须显式加 --include-all-namespaces 和 --report all：
-
--report all输出完整 JSON，含misconfiguration、secret、vulnerability三类结果；--report summary会丢掉具体规则 ID 和资源路径 - 扫描 RBAC 权限问题必须加
--include-resources clusterroles,clusterrolebindings,roles,rolebindings，否则 Trivy 默认跳过 - 想快速定位高危密钥（如 AWS_ACCESS_KEY），加
--severity CRITICAL,HIGH，避免被中低危噪声淹没 - 若集群有大量自定义 CRD，需用
--config trivy-config.yaml指定规则白名单，否则可能因未知字段解析失败而跳过整个资源
为什么不用 go-yaml + 自定义规则做静态检查
Trivy 内置的 misconfiguration 检查不是简单正则匹配，而是基于 Open Policy Agent（OPA）引擎执行 Rego 规则，能理解 Kubernetes 资源语义关系。比如判断 PodSecurityPolicy 是否允许特权容器，需要同时解析 securityContext.privileged 和 allowedCapabilities 的组合逻辑——手写 YAML 解析器极易漏掉嵌套条件或字段别名（如 runAsNonRoot: null 和 runAsNonRoot: false 语义不同）。
常见踩坑点：
立即学习“go语言免费学习笔记（深入）”；
- 用
yaml.Unmarshal直接映射到 struct 时，未定义字段会被静默丢弃，导致规则检查对象不完整 - 忽略 Kubernetes 版本兼容性：1.25+ 已废弃
PodSecurityPolicy，但旧规则仍会误报；Trivy 的规则集按 K8s 版本自动启用/禁用 - 没处理
envFrom引用的 Secret，只检查env字段——Trivy 会递归展开所有 env 来源
如何把 trivy k8s 集成进 GitOps 流水线
关键不是“扫完就发报告”，而是让扫描结果驱动决策。在 Argo CD 或 Flux 的 pre-sync hook 中运行：
trivy k8s --report all --format json --output scan-report.json . && \ jq -e '.Results[] | select(.Type == "misconfiguration") | select(.Severity == "CRITICAL")' scan-report.json > /dev/null
如果 jq 匹配成功（即存在 CRITICAL 配置问题），该命令退出码为 0，hook 可设 continueOnError: false 直接阻断部署。注意：
- 不要用
trivy k8s <context>扫集群——CI 环境通常无 kubeconfig，应扫本地 YAML 文件（trivy k8s --input manifests/） - 扫描
Secret时，Trivy 不解密 base64，而是对解码后明文做关键词匹配（如password、api_key），所以无需额外权限 - 若使用
trivy-operator，其 CRDScanJob的ignoreUnfixed: true字段会影响漏洞过滤逻辑，和 CLI 行为不一致，CI 中建议坚持用 CLI
最易被忽略的是命名空间隔离：trivy k8s 默认扫描所有命名空间，但 CI 流水线通常只变更单个 namespace 的 YAML。若未用 --include-namespaces 限定，可能因其他 namespace 的违规配置导致误阻断——安全扫描必须和变更范围严格对齐。
