文章总结: 本文介绍容器安全监控落地三步法:用trivy扫描镜像并签名验签、用falco监控运行时异常行为、收紧k8sAPI权限并关闭匿名访问,同时强调告警分级闭环。核心观点是小团队优先覆盖高频风险,零成本当天见效,建议立即开启审计日志并集成trivy。 综合评分: 82 文章分类: 云安全,安全建设,安全工具,安全运营
甲方运维收藏:容器监控落地三步, 镜像扫描到运行时
宝十八 宝十八
网络安全老宋
2026年9月30日 12:00 山东
在小说阅读器读本章
去阅读
在公众号小说中沉浸阅读
导语: 你好,我是网络安全老宋。安全攻防干货准时送达!
网络安全老宋// 云原生安全 · 实操落地
// 云原生安全 · 实操落地
甲方运维收藏:容器监控落地三步, 镜像扫描到运行时
Trivy 扫镜像、Falco 盯运行时、K8s 权限收死——高频风险盖住八成,零成本当天见效。
🔑 一句话精华 别一上来就想搭”完美体系”,先把镜像扫了、运行时盯了、API 收了,高频风险就覆盖了八成。
目录 · Table of Contents
01镜像供应链:从构建就卡死
02运行时:Falco 盯住异常行为
03控制平面:把权限收死
04告警要闭环,不然就是噪音
上篇聊了容器为什么难监控、三大盲区在哪。这篇直接给落地,不整虚的。老宋翻过一份容器安全内训材料,里面有个特别实在的建议:小团队资源有限,就三步走——Trivy 扫镜像、开 Kubernetes 审计日志、Falco 盯运行时。在此基础上老宋补一条,也是最多人翻车的地方:把 K8s 的 API 权限也收紧。
这三步做完,镜像供应链、运行时异常、控制平面权限这几个最高频的风险面就都盖住了。下面一个一个拆。
01镜像供应链:从构建就卡死
容器安全问题的源头在镜像。一个带后门的基础镜像,会被几十上百个业务容器继承,影响面是以”继承树”的方式爆炸的。所以监控的第一道闸,得卡在构建和入库环节。
CI/CD 里集成 Trivy 扫描。镜像推送前先扫,扫出 Critical 或 High 直接拒绝推送。命令很简单,很多流水线直接挂一步:
⏺ Shell · Trivy 镜像扫描
发现高危漏洞即返回非零退出码,中断流水线
trivy image –severity CRITICAL,HIGH –exit-code 1 my-registry/app:latest
--exit-code 1 的意思是:发现高危就中断流水线,不让带病镜像出厂。这一步能把”已知漏洞”挡在门外,成本几乎为零。
镜像签名 + 验签。光扫描还不够,得确认镜像来源可信。用 Cosign 给生产镜像签名,运行时(或准入控制器)验签,没签名的镜像一律不让起 Pod。某央企的真实教训:CI/CD 凭据泄露,攻击者在基础镜像里埋后门,后续所有业务镜像都继承了它,直接影响约 30 个业务容器。如果当时有签名验签,这步就能拦下。
基础镜像白名单。只允许从审批过的私有仓库拉基础镜像,公共仓库的”官方”镜像也得先过白名单。2025 年有个 arm64 版 Alpine 被投毒,植入挖矿程序,影响了 5 万多个生产部署——这类事件靠白名单+签名能挡掉大半。
02运行时:Falco 盯住异常行为
镜像再干净,运行时也可能出事——漏洞利用、配置缺陷、内部人员作妖。这一层靠 eBPF 在内核态抓系统调用,不用在容器里装 Agent,对业务零侵入,性能开销一般不到宿主机 CPU 的 3%。重点盯四类异常:
| | |
| — | — |
| W1 | 反弹 Shell攻击者拿到 Web 容器后第一件事往往是起个 Shell 回连。Falco 有现成规则检测容器内突然出现的 bash/sh 反弹连接。 |
| W2 | 挖矿进程CPU 异常飙升 + 出现 xmrig 之类进程名,直接告警。上篇说的政务云挖矿,靠这条就能在分钟级发现。 |
| W3 | 容器逃逸特征调用监控 mount、ptrace、setns 这类敏感系统调用,配合 runc 逃逸三连击(CVE-2025-31133 / CVE-2025-52565 / CVE-2025-52881)的检测规则,能在逃逸刚发生时就报警。上篇提到的 CVE-2024-1086 内核提权,也能在系统调用层被看见。 |
| W4 | 特权容器与 Docker socket 挂载这两样是逃逸的”高速公路”,一旦创建就该告警。 |
给一条 Falco 检测的雏形规则,感受下它的写法:
⏺ Falco · 检测容器内交互式 Shell
检测容器内出现反弹 Shell 类进程
- rule: Terminal Shell in Container
desc: 容器内启动交互式 shell
condition: >
spawned_process and container.id != host
and shell_procs and not trusted_images
output: “容器内出现 shell”
priority: WARNING
规则的核心就一句话:容器里出现了 shell 进程、且镜像不在可信名单里,就报。实际用直接套官方规则集,再按你们的业务加白名单就行。
▲ 运行时监控:eBPF 在内核层盯住异常进程与敏感调用
03控制平面:把权限收死
这是老宋要重点强调的一步,也是最容易被忽略的。镜像扫了、运行时盯了,结果 API Server 匿名都能访问,前面全白搭。
关掉匿名访问。某运营商的真实事件:kube-apiserver 开了 --anonymous-auth=true,外加 RBAC 放行匿名,攻击者直接枚举出 Pod 列表、Service 信息,虽没造成数据泄露,但等于把集群家底亮给了全网。配置里把这个关掉,加上 API Server 访问监控,对匿名和异常 IP 访问一律告警。
警惕 IngressNightmare。CVE-2025-1974,Ingress-NGINX Controller 的未授权远程代码执行,Wiz 的研究说约 43% 的云环境受影响,超过 6500 个集群把脆弱的准入控制器暴露到了公网。如果你的集群用了 Ingress-NGINX,先确认版本和是否对外暴露,这一条优先级最高。
| | | | | — | — | — | | 43% 云环境受影响 IngressNightmare(Wiz 研究) | 6500+ 集群暴露公网 脆弱的准入控制器被扫到 | 45% RBAC 配置有误 存在严重权限配置错误(Unit 42) |
RBAC 最小权限。Unit 42 在 2026 年的分析里说,45% 的 Kubernetes 环境存在严重 RBAC 配置错误,最常见的就是把应用 Pod 绑了 cluster-admin,或者用了 verbs: ["*"] 这种通配权限然后忘了。应用真的只需要读某个 namespace 的 deployment,就只给它读 deployment 的权限,别多给。
收紧 Service Account Token 与 etcd。默认很多 Pod 自动挂载 token,攻击者拿到就能调 API。能不挂就不挂;etcd 必须加密存储,且只给安全团队读权限,否则集群所有 Secret 等于明文摆着。
04告警要闭环,不然就是噪音
三步都上了,告警会多到淹没人。这儿有个关键动作:分级 + 去重 + 闭环。告警按严重程度分四级,响应时限各不相同:
| | | | | — | — | — | | 级别 | 典型场景 | 响应要求 | | P0 紧急 | 容器逃逸、集群被接管、数据泄露 | 15 分钟内响应,电话+短信 | | P1 严重 | 恶意进程、横向移动、特权容器创建 | 30 分钟内响应 | | P2 警告 | 镜像 Critical 漏洞、API 异常调用 | 2 小时内响应 | | P3 提示 | 配置不合规、低危漏洞 | 8 小时内处理 |
同一 Pod 5 分钟内的同类告警聚合成一条,P0 触发时自动抑制同一对象的低级别告警,避免告警风暴。Sysdig 提过一个”555 基准”:5 秒检测、5 分钟关联、5 分钟响应。意思是,真正有效的监控不是”能报”,而是从发现到处置要在分钟级完成。对运维来说,先把 P0/P1 的自动隔离、Pod 驱逐、NetworkPolicy 下发接上,比堆一堆看板实在得多。
// 老宋说:容器安全监控的本质,是把”检测”从边缘推进到运行时和编排层——边界防火墙和主机 HIDS 看不清容器内和东西向,这是架构决定的,不是你设备买少了。业内还停留在”买个盒子就安全”的思维,但容器的攻击面在镜像、运行时、控制平面三层同时展开,盒子的覆盖永远有缝。你现在能做的第一步,比任何规划都重要:今天就去开 Kubernetes 审计日志,把 Trivy 挂进流水线,这俩零成本、当天就能见效。
网络安全老宋 · 转载请注明出处
防御,不是在演练期间发现攻击,而是在演练开始前就把攻击面收敛到最小。
end
不想错过文章内容?读完请点一下“在看”,加个“关注”,您的支持是我创作的动力
期待您的一键三连支持(点赞、在看、分享~)
免责声明:
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景,旨在提升网络安全防护能力,具有明确的技术研究属性。
任何单位或个人未经授权,将本文内容用于攻击、破坏等非法用途的,由此引发的全部法律责任、民事赔偿及连带责任,均由行为人独立承担,本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布,若存在版权侵权或其他异议,请通过邮件联系处理,具体联系方式可点击页面上方的联系我。
本文转载自:网络安全老宋 宝十八 宝十八《甲方运维收藏:容器监控落地三步, 镜像扫描到运行时》
版权声明
本站仅做备份收录,仅供研究与教学参考之用。
读者将信息用于其他用途的,全部法律及连带责任由读者自行承担,本站不承担任何责任。









评论