企业官网建设流程全解析

通过 GitOps 安装 Trivy Operator：ArgoCD 与 FluxCD 完整实战指南

【免费下载链接】trivyFind vulnerabilities, misconfigurations, secrets, SBOM in containers, Kubernetes, code repositories, clouds and more项目地址: https://gitcode.com/GitHub_Trending/tr/trivy

本文以 Trivy 开源仓库中的官方教程 docs/tutorials/kubernetes/gitops.md 为骨架，系统讲解如何在 Kubernetes 集群中通过 ArgoCD 与 FluxCD 两大 GitOps 平台声明式地安装 Trivy Operator。读完本文，你将掌握两种 GitOps 工具各自的 CLI 与 Kubernetes 清单两种部署路径、values 覆盖技巧、同步与验证流程，并结合 Trivy 源码理解其 Helm Chart 关键配置与集群扫描能力，从而把容器安全扫描真正纳入"以 Git 为唯一事实来源"的交付体系。

背景：为什么通过 GitOps 部署 Trivy Operator

Trivy Operator 是 Trivy 官方提供的 Kubernetes Operator，它把 Trivy 安装进集群内部，自动、持续地扫描工作负载与集群本身的安全问题（详见 docs/ecosystem/prod.md）。与命令式的一次性扫描（如trivy k8s）不同，Operator 遵循 Kubernetes Operator 模型：扫描任务以 CRD（自定义资源）的形式保存在集群中，安全扫描器与扫描结果本身都是 Kubernetes 资源，默认每六小时自动重扫一轮，天然适合对接 Prometheus 告警等生态（参见 docs/tutorials/kubernetes/cluster-scanning.md）。

GitOps 的核心思想是"声明式 + 自动收敛"：集群的期望状态全部以 YAML 清单形式沉淀在 Git 仓库中，ArgoCD / FluxCD 负责把集群实际状态拉齐到期望状态。用 GitOps 安装 Trivy Operator 的好处在于：

• 可审计：安装参数、版本、values 覆盖全部留下 Git 变更记录；
• 自动漂移纠正：有人误删或改动 Operator 资源时，GitOps 工具会自动恢复（self-heal）；
• 多集群一致性：同一份清单可反复应用到开发、预发、生产多个集群；
• 升级可回滚：修改targetRevision/version后，一次同步即可完成 Helm Chart 升级。

本仓库的helm/trivy目录提供了 Trivy 自身的 Helm Chart（helm/trivy/Chart.yaml，当前 chart 版本 0.26.0、appVersion 0.74.0），而 Trivy Operator 有独立维护的 Helm Chart，托管在 Helm 仓库https://aquasecurity.github.io/helm-charts/，这正是下文两种 GitOps 安装方案的共同数据源。

前置准备

开始前需要满足以下条件：

1. 一个可用的 Kubernetes 集群，且已安装并运行 ArgoCD（对应下文方案一）或 FluxCD（对应下文方案二）。本地 kind、Docker Desktop、microk8s 集群均可。
2. kubectl已配置好集群访问（默认使用~/.kube/config中的当前上下文）。
3. 一个用于存放 Operator 的目标命名空间，教程统一使用trivy-system：

kubectl create ns trivy-system

说明：下文所有argocd、flux命令均来自各自 CLI 工具，请确保本机已安装对应命令行客户端。

方案一：通过 ArgoCD 安装

ArgoCD 安装 Trivy Operator 有两条路径：使用argocdCLI 命令，或直接应用一个Application类型的 Kubernetes 清单。两者最终都会在 ArgoCD 中注册一个 Application，由 ArgoCD 负责把 Helm Chart 渲染并同步到集群。

方式一：使用 argocd CLI

创建命名空间后，直接通过argocd app create声明一个指向官方 Helm Chart 的应用：

kubectl create ns trivy-system argocd app create trivy-operator \ --repo https://github.com/aquasecurity/trivy-operator \ --path deploy/helm \ --dest-server https://kubernetes.default.svc \ --dest-namespace trivy-system

参数含义：

注意：这种安装方式直接关联 Trivy Operator 官方 Helm Chart。如果需要修改任何 Chart 参数，建议创建一个独立的values.yaml文件，通过--values参数或 ArgoCD Application 的helm.values字段传入，而不是改动 Chart 本身。

方式二：使用 Kubernetes 清单（Application CRD）

更符合 GitOps 理念的做法是维护一个trivy-operator.yaml清单，把整个 Application 定义提交到 Git：

apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: trivy-operator namespace: argocd spec: project: default source: chart: trivy-operator repoURL: https://aquasecurity.github.io/helm-charts/ targetRevision: 0.0.3 helm: values: | trivy: ignoreUnfixed: true destination: server: https://kubernetes.default.svc namespace: trivy-system syncPolicy: automated: prune: true selfHeal: true

关键字段解读：

• source.chart+source.repoURL：声明从 Helm 仓库拉取名为trivy-operator的 Chart，这是与 CLI 方式（--repo+--path指向 Git 仓库内 Chart 目录）不同的两种 Chart 来源写法；
• source.targetRevision：Chart 版本。建议锁定具体版本以保证可重复性，升级时修改此字段即可；
• source.helm.values：内联 values 覆盖，示例中通过trivy.ignoreUnfixed: true让 Operator 扫描时忽略"无修复版本"的漏洞，避免海量未修复告警淹没真正需要处理的问题；
• syncPolicy.automated.prune：自动删除集群中已从 Git 清单移除的资源；
• syncPolicy.automated.selfHeal：当集群实际状态偏离期望状态时自动修正，这是 GitOps 防漂移的关键；
• destination.namespace：trivy-system，Operator 及扫描产物将部署于此。

应用清单并触发同步

清单在本地时，用kubectl直接应用：

kubectl apply -f trivy-operator.yaml application.argoproj.io/trivy-operator created

若清单存放在 Git 仓库中，可让 ArgoCD 直接拉取远程文件应用：

kubectl apply -n argocd -f https://raw.githubusercontent.com/AnaisUrlichs/argocd-starboard/main/starboard/argocd-starboard.yaml

后者方式下，你可以直接修改远程仓库中的 YAML 清单，ArgoCD 会自动感知变更并注册更新。

部署完成后，需要显式触发一次同步，让 ArgoCD 把集群从实际状态拉齐到期望状态：

argocd app sync trivy-operator

在 ArgoCD UI 中查看部署结果

同步完成后，打开 ArgoCD UI 即可看到trivy-operator应用及其资源树（如何访问 UI 请参考 ArgoCD 官方文档）：

上图是部署 Trivy Operator 后 ArgoCD 的 Applications 视图：资源树中央是trivy-operator应用节点，向外辐射出 configmap、secret、deployment、service、role、rolebinding、cronjob 等子资源，顶部状态标签显示 SYNC/HEALTHY，说明应用已同步且健康。

需要特别说明的已知限制：ArgoCD 无法把 Trivy 的 CRD 显示为 synced 状态。这是因为 CRD 属于集群级资源，其管理方式与 ArgoCD 对普通应用资源的追踪逻辑存在差异，看到 CRD 不显示同步状态属正常现象，不影响 Operator 实际功能。

方案二：通过 FluxCD 安装

FluxCD 的安装思路与 ArgoCD 类似，同样提供 CLI 与清单两种路径，底层机制换成 Flux 的HelmRepository+HelmRelease两个 CRD。

方式一：使用 Flux CLI

kubectl create ns trivy-system flux create source helm trivy-operator \ --url https://aquasecurity.github.io/helm-charts \ --namespace trivy-system flux create helmrelease trivy-operator \ --chart trivy-operator \ --source HelmRepository/trivy-operator \ --chart-version 0.0.3 \ --namespace trivy-system

• flux create source helm：创建一个HelmRepository对象，指向 Trivy 官方 Helm 仓库；
• flux create helmrelease：创建一个HelmRelease对象，声明要安装的 Chart、来源与版本。

方式二：使用 Kubernetes 清单（HelmRepository + HelmRelease）

将下面内容保存为trivy-operator.yaml，一份文件同时定义两个资源（---分隔）：

apiVersion: source.toolkit.fluxcd.io/v1beta2 kind: HelmRepository metadata: name: trivy-operator namespace: flux-system spec: interval: 60m url: https://aquasecurity.github.io/helm-charts/ --- apiVersion: helm.toolkit.fluxcd.io/v2beta1 kind: HelmRelease metadata: name: trivy-operator namespace: trivy-system spec: chart: spec: chart: trivy-operator sourceRef: kind: HelmRepository name: trivy-operator namespace: flux-system version: 0.10.1 interval: 60m values: trivy: ignoreUnfixed: true install: crds: CreateReplace createNamespace: true

与 ArgoCD 清单对应的关键点：

• HelmRepository.spec.interval：Flux 定期刷新 Helm 仓库索引的时间间隔（这里 60 分钟），用于感知新 Chart 版本；
• HelmRelease.spec.chart.spec.sourceRef：通过kind、name、namespace三要素引用上文定义的HelmRepository；
• HelmRelease.spec.values：与 ArgoCD 的helm.values等价，示例同样设置了trivy.ignoreUnfixed: true；
• install.crds: CreateReplace：安装时创建（存在则替换）CRD，这是 Operator 类 Chart 的常见要求，确保 Trivy 的 CRD 正确安装；
• install.createNamespace: true：目标命名空间trivy-system不存在时自动创建。

应用清单：

kubectl apply -f trivy-operator.yaml

Flux 控制器会依据interval轮询，自动完成从拉取 Chart 到渲染、安装的全过程，无需像 ArgoCD 那样手动触发同步。

安装后的验证

无论使用哪种 GitOps 工具，安装完成后都应确认 Operator 正常运行。检查trivy-system命名空间下的 Deployment：

kubectl get deployment -n trivy-system

看到 Trivy Operator 相关 Deployment 处于READY状态即为安装成功。接下来可以观察 Operator 自动为集群内工作负载生成的安全报告（漏洞、配置错误、密钥扫描）。

对于想立即体验集群整体扫描效果的场景，也可以绕过 Operator 直接使用 Trivy CLI 的trivy k8s命令做一次性验证：

trivy k8s --report=summary

上图展示了trivy k8s --report summary的典型输出，分为 Workload Assessment（工作负载评估）与 Infra Assessment（基础设施评估）两部分，分别统计各命名空间/资源的漏洞（Vulnerabilities）、配置错误（Misconfigurations）与密钥（Secrets）数量，并按 C=CRITICAL、H=HIGH、M=MEDIUM、L=LOW、U=UNKNOWN 分级。详细的trivy k8s用法（--include-namespaces、--exclude-kinds、--report all、RBAC 权限要求、compliance 报告等）可参考 docs/guide/target/kubernetes.md 与 docs/tutorials/kubernetes/cluster-scanning.md。

结合源码：Helm Chart 配置参数与 GitOps values 实践

GitOps 安装 Trivy Operator 的核心工作之一就是编写 values 覆盖。虽然 Trivy Operator 的 Chart 在独立仓库维护，但本仓库helm/trivy目录下的 Trivy 自身 Chart（helm/trivy/values.yaml）可以作为理解 Trivy 相关配置项的最佳参照，两者的配置哲学一脉相承。结合该文件，下面是 GitOps 场景下最常用的配置维度：

在 GitOps 清单中，这些参数通过spec.source.helm.values（ArgoCD）或spec.values（FluxCD）传入。推荐的实践是：

1. 版本锁定：固定targetRevision/version，升级时先在测试集群验证；
2. 敏感信息外置：Token、镜像仓库凭据不要明文写入 Git 清单，通过existingSecret引用 Kubernetes Secret（配合 Sealed Secrets / External Secrets 等方案）；
3. 离线环境适配：修改dbRepository与image.repository指向内网镜像，配置httpProxy/httpsProxy/noProxy（helm/trivy/values.yaml 中均有对应字段）；
4. 告警降噪：如教程示例所示设置trivy.ignoreUnfixed: true，聚焦存在修复版本的漏洞。

从 Trivy 源码侧看，集群扫描能力由 pkg/k8s/k8s.go 中的ScanKubernetes实现，它组合 OS 包扫描器（ospkg）、语言包扫描器（langpkg）与漏洞客户端完成扫描。与之配套的 CLI 参数定义在 pkg/flag/kubernetes_flags.go，包括--include-namespaces/--exclude-namespaces（二者互斥，源码ToOptions中有明确校验）、--skip-images（跳过集群资源镜像下载与扫描）、--disable-node-collector（禁用节点采集 Job）、--tolerations（让节点采集 Job 调度到被污点标记的节点）等。理解这些参数，有助于在 Operator 自动化扫描之外，针对特定场景做命令式补充扫描或调优。

常见问题与注意事项

• ArgoCD 不显示 CRD 同步状态：前文已述，这是 ArgoCD 对集群级 CRD 资源追踪的限制，属预期行为，可放心忽略。
• 版本字段不一致：教程示例中 ArgoCD 清单使用targetRevision: 0.0.3，FluxCD 清单使用version: 0.10.1，两者均为历史示例版本。实际使用时请查询 Trivy Operator 官方 Helm 仓库的最新稳定版本，并保持两个环境中锁定的版本一致。
• values 变更的生效方式：ArgoCD 下修改helm.values后需argocd app sync触发；FluxCD 下由interval轮询自动收敛，也可用flux reconcile helmrelease trivy-operator立即触发。
• 清理安装：ArgoCD 场景删除Application并配合prune: true可一并清理部署的资源；FluxCD 场景删除对应HelmRelease即可，注意确认trivy-system命名空间中的残留资源。
• RBAC 与集群扫描权限：若在 Operator 之外使用trivy k8s扫描集群，需要具备相应 API 组的list权限（core、apps、batch、networking.k8s.io、rbac.authorization.k8s.io），启用节点采集时还需额外权限，详见 docs/guide/target/kubernetes.md 的 "Required roles" 一节。

通过本文的两种 GitOps 路径，Trivy Operator 的部署、升级与配置变更都能以声明式清单的方式纳入版本管理，配合自动同步与自愈策略，即可在持续交付流水线中稳定落地 Kubernetes 容器安全扫描能力。

【免费下载链接】trivyFind vulnerabilities, misconfigurations, secrets, SBOM in containers, Kubernetes, code repositories, clouds and more项目地址: https://gitcode.com/GitHub_Trending/tr/trivy