# 持续监控集群中的镜像漏洞——Trivy Operator 简介

> 在本文中，我们将介绍 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

```plaintext
$ 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，可以查看一下它的权限：

```plaintext
$ 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 插件](https://github.com/Ladicle/kubectl-rolesum)

可以看到，它从 `trivy-operator` 这个 `ClusterRole` 继承了大量权限，除了前面提到的 CR 之外，还包括了对 Pod、Configmap 等的读取权限，据此可以判断他的工作范围。

### Helm

这个安装也比较简单，首先加入 Aqua 的仓库：

```plaintext
$ 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](https://github.com/operator-framework/operator-lifecycle-manager/)这是一种专门用于维护 Operator 生命周期的方式。这里暂时不做更多介绍。具体安装方式可以参照[官方文档](https://aquasecurity.github.io/trivy-operator/v0.12.1/getting-started/installation/olm/)

## 配置

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，内容：

```yaml
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 的审计内容，例如：

```yaml
  - 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](https://github.com/dotdc/grafana-dashboards-kubernetes/blob/master/dashboards/trivy) 进行可视化呈现；或者用 Alert Manager 以及 Webhook 进行告警。

## 补充

其实除了 YAML 和镜像漏洞的检查之外，这个 Operator 还定义了多种合规性、安全基线方面的内容，并可以通过 REGO 语言进行自定义的基线检查。虽然多数功能还处于非正式版本，但这是一个合理的方向———对集群安全，要进行可视化的、持续的审视，而不是。。我不说了。