欢迎光临
我们一直在努力

持续监控集群中的镜像漏洞——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

$ 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-XXXConfigAuditReport 对象,其中包含了对这个 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 语言进行自定义的基线检查。虽然多数功能还处于非正式版本,但这是一个合理的方向———对集群安全,要进行可视化的、持续的审视,而不是。。我不说了。

文章来源于互联网:持续监控集群中的镜像漏洞——Trivy Operator 简介

赞(0)
未经允许不得转载:莱卡云 » 持续监控集群中的镜像漏洞——Trivy Operator 简介