在本文中，我们将介绍 Trivy Operator，一款用于持续监控 Kubernetes 集群中的容器镜像漏洞的工具。我们将从 Trivy Operator 的简介开始，接着介绍如何安装和配置，最后探讨漏洞扫描与呈现，以及其他补充功能。
引言
当下，容器技术已成为企业构建和部署应用的关键组成部分。然而，容器镜像可能会携带软件漏洞，这些漏洞可能导致应用和数据面临安全风险。为了确保 Kubernetes 集群在运行时的持续安全，就需要自动对运行中的容器镜像进行扫描的工具。
很早以前曾经使用 Shell Operator 结合 Trivy 编写了一个小工具，对运行中的镜像进行扫描，然后把扫描结果用 Prometheus 的方式进行输出。
接下来将要介绍的 Trivy-Operator，是一个来自 Aqua 的开源工具，可以自动扫描容器镜像中已知的漏洞，并用最佳实践对 Kubernetes 资源进行验证，从而提高 Kubernetes 集群的运行时安全性。它易于安装，可以顺利地集成到监控系统中；更借助Kubernetes Operator 技术响应集群上的工作负载和其他更改，自动更新安全报告资源。Trivy-Operator 能够显著加强 Kubernetes 集群的安全性，保护其中的应用程序免受潜在威胁。
简介
在深入了解 Trivy-Operator 的使用方法之前，先简单交代一下它的大致功能：
漏洞扫描：Trivy-Operator 基于 Trivy 扫描器，对容器镜像进行全面扫描，识别其中的已知漏洞。这有助于及时发现并修复潜在的安全隐患，保护您的应用程序免受攻击。
Kubernetes 资源验证：通过与 Kubernetes API 的集成，Trivy-Operator 可以自动验证 Kubernetes 资源的配置，确保遵循安全性最佳实践。这样可以避免因配置错误导致的安全风险。
持续监控与报告：Trivy-Operator 自动更新安全报告资源，以响应 Kubernetes 集群上的工作负载和其他更改。这意味着它可以在创建新 Pod 时启动漏洞扫描和配置审核，然后更新扫描报告。这有助于实时了解集群安全状况，及时采取相应措施。
Prometheus 集成：Trivy-Operator 提供 Prometheus 指标端点，使其可以与现有的监控基础设施集成。通过Prometheus，用户可以收集和分析 Trivy-Operator 的指标数据，实现对集群安全的实时监控。通过 Prometheus 之后，还可以和 Grafana、Alert-manager 等联动，进一步提高集群的透明度和可运维性。
安装
可以通过三种方式安装和部署 Trivy Operator，YAML、Helm 和 OLM。
YAML
$ kubectl apply -f \
https://raw.githubusercontent.com/aquasecurity/trivy-operator/v0.12.1/deploy/static/trivy-operator.yaml
customresourcedefinition.apiextensions.k8s.io/clustercompliancereports.aquasecurity.github.io created
...
可以看到，这里创建了几个 CRD，都是以 reports 结尾的，看来都是各种报告，大概几个字面意思：
infraassessmentreports，clusterinfraassessmentreports：基础设施评估报告，包括 Kubernetes 核心组件的配置内容
vulnerabilityreports：漏洞报告
configauditreports、clusterconfigauditreports：配置审计报告
exposedsecretreports：Secret 报告
clusterrbacassessmentreports/rbacassessmentreports：RBAC 评估报告
clusterrbacassessmentreports：集群 RBAC 评估报告
另外还生成了一个叫做 trivy-operator 的 ServiceAccount，可以查看一下它的权限：
$ kubectl rolesum trivy-operator
ServiceAccount: trivy-system/trivy-operator
...
Policies:
...
• [CRB] */trivy-operator ⟶ [CR] */trivy-operator
Resource Name Exclude Verbs G L W C U P D DC
clustercompliancedetailreports.aquasecurity.github.io [*] [-] [-] ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✖
clustercompliancereports.aquasecurity.github.io [*] [-] [-] ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✖
这里用到了 kubectl 的 rolesum 插件
可以看到，它从 trivy-operator 这个 ClusterRole 继承了大量权限，除了前面提到的 CR 之外，还包括了对 Pod、Configmap 等的读取权限，据此可以判断他的工作范围。
Helm
这个安装也比较简单，首先加入 Aqua 的仓库：
$ helm repo add aqua https://aquasecurity.github.io/helm-charts/
helm repo add aqua https://aquasecurity.github.io/helm-charts
"aqua" has been added to your repositories
$ helm repo update
...
$ helm install trivy-operator aqua/trivy-operator \
--namespace trivy-system \
--create-namespace \
--set="trivy.ignoreUnfixed=true" \
--version 0.12.1
...
可以用 helm show values aqua/trivy-operator 看看其中包含的丰富配置。后面也会进行一点讲解。
Operator Lifecycle Manager
OLM这是一种专门用于维护 Operator 生命周期的方式。这里暂时不做更多介绍。具体安装方式可以参照官方文档
配置
Operator Pod（trivy-operator-）支持很多环境变量用于其行为配置，下面列出一些关键内容：
OPERATOR_EXCLUDE_NAMESPACES：排除命名空间
OPERATOR_VULNERABILITY_SCANNER_ENABLED：启用漏洞扫描
OPERATOR_CONFIG_AUDIT_SCANNER_ENABLED：启用配置审计
OPERATOR_RBAC_ASSESSMENT_SCANNER_ENABLED：启用 RBAC 扫描
OPERATOR_CONFIG_AUDIT_SCANNER_BUILTIN：启用内置的配置扫描引擎
OPERATOR_WEBHOOK_BROADCAST_URL：Webhook 地址，置空则禁用该功能
另外，同一个命名空间内还有一个 Configmap，内容：
apiVersion: v1
data:
trivy.additionalVulnerabilityReportFields: ""
trivy.command: image
trivy.dbRepository: ghcr.io/aquasecurity/trivy-db
trivy.dbRepositoryInsecure: "false"
trivy.mode: Standalone
trivy.repository: ghcr.io/aquasecurity/trivy
trivy.resources.limits.cpu: 500m
trivy.resources.limits.memory: 500M
trivy.resources.requests.cpu: 100m
trivy.resources.requests.memory: 100M
trivy.severity: UNKNOWN,LOW,MEDIUM,HIGH,CRITICAL
trivy.slow: "true"
trivy.supportedConfigAuditKinds: Workload,Service,Role,ClusterRole,NetworkPolicy,Ingress,LimitRange,ResourceQuota
trivy.tag: 0.38.2
trivy.timeout: 5m0s
trivy.useBuiltinRegoPolicies: "true"
kind: ConfigMap
metadata:
annotations:
...
name: trivy-operator-trivy-config
namespace: trivy-system
其中的内容，熟悉 Trivy 扫描器的读者应该很容易看得出来——这里基本定义了最常用的几个 Trivy 开关。另外根据官网看来，还可以使用 trivy-operator-trivy-config Secret 的 data.trivy.githubToken 来设置用于抓取 Trivy 特征库的 Github Token。
漏洞扫描和呈现
事实上，Trivy Operator 部署之后直接就会启动扫描，生成漏洞报告（vulnerabilityreports）以及 RBAC 报告（rbacassessment），可以使用 kubectl get xx yy-o wide，或者 kubectl descrbe xx yy 来查看具体内容。例如漏洞报告显示各级别问题都是 0。
新建一个工作负载，例如 kubectl create deployment nginx --image nginx:1.16，创建之后，会发现马上出现一个 scan-vulnerabilityreport-* 的 Pod 启动了，在它完成任务消失之后，我们会看到 vulns 多了一条针对 nginx:1.16 镜像的记录，其中包含高中低各种级别的漏洞若干。
另外还新出现了一个名为 replicaset-nginx-XXX 的 ConfigAuditReport 对象，其中包含了对这个 RS 的审计内容，例如：
- category: Kubernetes Security Check
checkID: KSV015
description: When containers have resource requests specified, the scheduler can
make better decisions about which nodes to place pods on, and how to deal with
resource contention.
messages:
- Container 'nginx' of ReplicaSet 'nginx-54f8f9f495' should set 'resources.requests.cpu'
severity: LOW
success: false
title: CPU requests not specified
这些基本内容都可以通过 Prometheus 监控栈进行监控，并可通过 Grafana Dashboard 进行可视化呈现；或者用 Alert Manager 以及 Webhook 进行告警。
补充
其实除了 YAML 和镜像漏洞的检查之外，这个 Operator 还定义了多种合规性、安全基线方面的内容，并可以通过 REGO 语言进行自定义的基线检查。虽然多数功能还处于非正式版本，但这是一个合理的方向———对集群安全，要进行可视化的、持续的审视，而不是。。我不说了。
