Skip to main content

Command Palette

Search for a command to run...

借助 Shell Operator 监控集群中的镜像漏洞

Published
•1 min read•View as Markdown

在使用 Shell-Operator,让 Pod 继承节点标签一文中,展示了使用 Shell Operator 在创建工作负载时从对应节点拷贝指定标签的方法。Shell Operator 还有个功能就是生成 Prometheus Metrics,本文就是从这个角度出发,用 Shell Operator 定时调用 Trivy 扫描指定命名空间下的所有在用镜像,并输出指标给 Prometheus,最终可以进行展示和告警。

Shell Operator 除了上次提到的根据 Kubernetes 事件进行触发之外,还包含了在启动时和定期运行两种触发方式,这里我们用定时触发的方式:

configVersion: v1
schedule:
- name: "scan images each 5 min"
  crontab: "*/5 * * * *"
  allowFailure: true

这里我定义了一个 5 分钟触发一次的任务。镜像接受一个缺省为 NS_LABEL="trivy=true" 的标签,每次触发时,会根据这个标签选择命名空间,获取选定命名空间中运行的镜像,并调用 trivy i -f json [image] 输出结果,将结果转换为 Prometheus 指标进行输出。

FROM flant/shell-operator:v1.0.0-rc.2
ENV TRIVY_CACHE_DIR=/data/trivy \
    TRIVY_QUIET=true \
    GITHUB_TOKEN="" \
    NS_LABEL="trivy=true"
RUN apk --no-cache add python3=3.8.8-r0
COPY trivy-scanner.py /hooks
COPY trivy /usr/local/bin
VOLUME [ "/data/trivy", "/data/cache" ]

上文中的几个环境变量:

  • TRIVY_CACHE_DIR:指定 Trivy 缓存目录,可以在 Kubernetes 中把 Trivy 工作目录持久化。
  • TRIVY_QUIET:Trivy 环境变量,指定 Trivy 用静默方式运行。
  • GITHUB_TOKEN:Trivy 会使用该 Token 更新漏洞库,防止触发 Rate Limit。
  • NS_LABLE:仅对符合标签的命名空间进行扫描。

在脚本中执行的任务还是很简单的三部曲:

  • kubectl get ns
  • kubectl get po
  • trivy

可以看到这里需要列表查看 Namespace 和 Pod 对象,因此我们的 RBAC 需要进行相应的配置,例如设置 ClusterRole:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: trivy-scanner
rules:
- resources:
  - pods
  - namespaces
  verbs:
  - get
  - watch
  - list

实际上也可以通过之前用到的 Kubernetes 事件进行触发。因此这里还保留了 watch 事件。

Deployment 需要注意一点是,Shell Operator 使用 9115 端口的 /metrics 开放指标数据供 Prometheus 抓取,因此需要使用 annotations 对此进行标注。

使用 Trivy 获取到 JSON 格式出具的扫描结果之后,就可以利用 Shell Operator 的指标输出能力,把数据整理为如下格式:

{"name":"so_vulnerabilities","set":0,"labels":{"image":"dustise/sleep:v0.9.6","severity":"UNKNOWN"}}
{"name":"so_vulnerabilities","set":1,"labels":{"image":"dustise/sleep:v0.9.6","severity":"HIGH"}}

每行一条记录,输出到 $METRICS_PATH 环境变量指定的文本文件中,Shell Operator 会把它转换为 Prometheus 指标:

so_vulnerabilities{hook="trivy-scanner.py",image="dustise/sleep:v0.9.6",severity="CRITICAL"} 1
so_vulnerabilities{hook="trivy-scanner.py",image="dustise/sleep:v0.9.6",severity="HIGH"} 11
so_vulnerabilities{hook="trivy-scanner.py",image="dustise/sleep:v0.9.6",severity="LOW"} 2
so_vulnerabilities{hook="trivy-scanner.py",image="dustise/sleep:v0.9.6",severity="MEDIUM"} 9
so_vulnerabilities{hook="trivy-scanner.py",image="dustise/sleep:v0.9.6",severity="UNKNOWN"} 0

接下来就可以在 Prometheus 中检查输出内容,出具监控图表或者制定告警规则了。

More from this blog

AI Agent 的“莫兰迪时刻”

一个新范式真正走向大众,往往不是从所有人都正确理解它开始,而是从它开始被反复引用、简化、误读,甚至滥用开始。 今天的 AI Agent,可能正走到这样一个时刻。 这篇文章的念头,来自我最近收听《大内密谈》vol.1434《审美升级or消费主义?从莫兰迪在中国聊起》时的一些联想。节目从莫兰迪色在中国的走红,谈到作品价格、知识产权、商业流量与消费主义。[9] 我听着听着想到另一个熟悉的技术史问题:为

Oct 5, 20263 min read

FDE 是传统运维产品厂商的出路吗?

很多传统运维产品厂商,已经不缺产品了。 从 ITSM、CMDB、监控、自动化,到 IAM、数据中心管理和各类大屏,一个成熟厂商往往都能拿出一张很完整的产品地图。销售材料上看,客户运维部门的日常工作几乎都被覆盖了。 但项目一落地,味道就变了。 产品越多,集成越重;模块越全,边界越模糊;客户越大,定制越深。到了后期,项目成功本身也会变成麻烦:现场改出来的东西回不到主干,配置越来越像黑箱,谁都不敢轻易升

Jun 29, 20263 min read

绵里藏针才是 AIOps 的本质?

Agent 让运维编排变得柔性、可变、甚至自演进;但真正敢进入生产环境的 AIOps,仍然离不开坚实、受控、可审计、可回退的自动化底座。 从 Gartner 提出 AIOps 概念到现在,也大概有十年了。这么多年来,这个领域好像发生了很多变化,又好像没什么“本质”的变化。技术上,我们经历了传统机器学习、深度学习和神经网络、以及大模型和智能体这样“翻天覆地”的变化;业务上,我们面对的是更多品种、更大

May 31, 20263 min read

龙虾恐慌:AIOps 又要改名了?

ChatGPT 开始,把 AI 拉近到普罗大众的面前,让无数人感受到 AI 的亲民魅力。而龙虾,则把大模型驱动的自动化能力,突然间变得水灵灵、活泼泼地走进千家万户。它不只是“风口上的猪”,而是风口本身。热度高到让 Mac mini 一度断货,不知道这在不在库克的预料之内。 每代人都有每代人的鸡蛋,春节期间,我就领了我的鸡蛋。翻出古老的 MacBook Air M1,充值各种大模型。当然了,这个工具

Mar 9, 20261 min read
【

【伪】架构师

346 posts