1. 安全扫描前先弄明白Kubernetes集群到底有哪些安全风险先说我自己的经历。干了这么多年运维Kubernetes这块踩过的坑不少但真正让我下定决心把安全扫描当成“必做项”的是有一次线上集群被安全通告点名说某个存量镜像存在高危CVE而且已经对外暴露了端口。当时最大的问题不是“漏洞怎么修”而是“这个漏洞到底在哪、有多少个镜像受影响、哪些命名空间在跑”我们居然答不上来。那一刻我才意识到Kubernetes环境里如果连“资产画像”都没建立起来安全扫描就是无源之水。很多刚接触Kubernetes安全的人第一反应是“我装个Trivy扫一下镜像不就行了”这话对了一半。镜像扫描确实是最基础的一环但Kubernetes集群的安全风险和传统虚拟机时代完全是两码事。我习惯把集群内的安全风险拆成五个维度镜像漏洞、配置漂移、运行时异常、权限过载、依赖供应链。这五个维度的攻防视角完全不同扫描工具也完全不重叠。先说镜像漏洞。这是最直观的也是安全团队最爱盯的。Docker镜像里藏着大量的系统包、语言依赖库、二进制文件任何一个上游组件出了CVE你的镜像就可能被打穿。但这里有个关键误区镜像扫描只能告诉你“镜像里有什么漏洞”它无法告诉你“这个漏洞在当前运行环境里是否真的可利用”。比如某个CVE只在特定内核版本下生效而你的宿主内核早已修复那这个漏洞在运行时就是“假阳性”。所以镜像扫描的产出一定要结合运行时上下文来看不能见洞就堵。再说配置漂移。Kubernetes是声明式架构所有的期望状态都写在YAML里——Pod是不是允许以root身份运行、有没有开启特权模式、容器是否设置了CPU限制、Secret有没有明文写在环境变量里这些全部可以通过静态配置扫描来检测。我见过不少团队镜像扫得干干净净结果deployment里直接写着privileged: true或者把ServiceAccount绑到了cluster-admin这种漏洞比镜像CVE更容易被利用也更容易被忽视。运行时异常是另一个维度。镜像和配置都是“静态检查”但攻击往往是动态发生的。你无法通过扫描镜像来发现“这个容器正在尝试读取宿主机的/etc/shadow”也无法知道“有人从外部网络在容器内启动了反弹shell”。这类问题需要运行时安全检测工具比如Falco通过内核事件和系统调用来判断容器行为是否越界。权限过载则是Kubernetes特有的风险放大器。RBAC基于角色的访问控制设计得再好也需要持续审计。很多集群里业务Pod带着高权限的ServiceAccountPod的automountServiceAccountToken也没关攻击者一旦打进容器直接就拿到了调用Kubernetes API的凭证。权限扫描要做的是把这些过度授权的账号、绑定、角色一个个揪出来而不是等出了事再复盘。最后是依赖供应链。这个维度很多人会忽略但实际影响很大。你引入的Helm Chart是否来自可信仓库Chart里有没有嵌套恶意镜像基础镜像的tag是不是latest这种漂移标签这些都属于供应链安全的范畴。好在现在很多镜像扫描工具已经支持SBOM软件物料清单生成可以把你镜像里所有组件清单化、版本化这是后续做漏洞溯源的基础。把这五个维度写在前面是为了让大家先建立全局观因为它决定了你后面选工具、定流程、设阈值时眼睛该往哪里看。接下来的内容我按照“静态扫描→运行时检测→策略联动→故障排查”这条主线把每个环节的落地细节和踩到的坑都讲一清二楚。2. 镜像安全扫描用Trivy把第一道防线建起来2.1 为什么镜像扫描是第一个要做的我得说句实话如果你所在团队目前对Kubernetes安全完全没概念那就从镜像扫描开始。理由很简单——它是所有安全手段里“投入产出比”最高的。镜像扫描只需要在CI流水线里加一步或者在镜像仓库里挂一个定时任务就能在“源头”拦截绝大多数已知漏洞不需要理解复杂的Kubernetes调度和准入控制机制。对比一下大家常用的几种工具Trivy、Clair、Anchore。Clair是CoreOS开源的老牌扫描器设计上偏向服务端部署需要搭配PostgreSQL数据库比较重Anchore Engine功能全面但同样部署成本高。Trivy从一开始就定位于“又快又准又轻量”单个二进文件就能跑漏洞库更新也频繁还内置了多种语言的依赖扫描支持所以我个人推荐把Trivy作为镜像扫描第一选择。Trivy还有一个很实用的特性它不只是扫系统包还能扫描应用依赖比如Python的requirements.txt、Node.js的package-lock.json里的已知漏洞。这就意味着即使你的镜像基础层干干净净应用层引入了一个有漏洞的第三方库Trivy也能扫得出来。2.2 Trivy从命令行到CI流水线的快速落地先看最基本的命令。假设我们要扫描一个nginx镜像在本地直接执行trivy image --exit-code 1 --severity HIGH,CRITICAL nginx:1.24这里--severity指定了关注等级--exit-code 1表示“只要扫出高危或致命漏洞就返回非零退出码”。这个退出码非常关键后续接CI流水线时就是靠它来决定“构建是继续还是失败”的。实际跑一次你会发现Trivy扫描速度快得惊人扫描一个常见的nginx镜像通常只需要几秒这得益于它采用“先离线下载漏洞库再按镜像层级和包管理器特征去匹配”的策略而不是像某些商业扫描器那样在线查询每个包。离线环境下也只需要先用trivy image --download-db-only把漏洞库镜像拉下来后续扫描直接复用不依赖公网。扫出来的结果一般是表格或者JSON格式。我建议在CI阶段把完整JSON报告归档到制品库这样后续做漏洞追踪时有据可查。生成的概览大概是这个画风漏洞ID组件版本严重性已修复版本CVE-2024-24989nginx1.24.0HIGH1.25.0CVE-2023-4863libwebp1.2.4CRITICAL1.3.2到了CI集成环节以GitLab CI为例可以在.gitlab-ci.yml里加一个stageimage_scan: stage: test image: docker.io/aquasec/trivy:0.51.0 script: - trivy image --exit-code 1 --severity HIGH,CRITICAL --no-progress $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA only: - main这里有几个细节值得注意。第一--no-progress是因为CI日志里不需要进度条否则日志会被刷屏第二扫描的镜像是$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA也就是“当前待发布的镜像”而不是latest——用漂移标签会导致扫描结果分不清是哪个版本后面排查的时候非常痛苦。2.3 漏洞阈值、忽略机制和SBOM管理很多人配置完CI就以为万事大吉了。实际上“扫描通过”和“真的安全”之间隔着一层很厚的理解。你需要先确定“怎样的镜像输出才允许上线”。我见过两种极端一种是太宽松只扫CRITICAL导致一堆HIGH漏洞带病上线另一种是太严格见漏洞就fail结果开发抵制最终整个扫描环节被绕过。我个人的建议是新发布的镜像要求“CRITICAL必须清零”HIGH可以容忍24小时内给出修复计划MEDIUM及以下走常规流程即可。但这只是个起点。Trivy有一个--ignore-unfixed参数它只报告有已修复版本的漏洞。这个参数非常实用——没有修复方案的高危漏洞你就算fail了流水线也只能干瞪眼不如先放行但记录在案。此外有些CVE确实影响到了你的镜像但你评估过业务场景后认为不可利用可以通过.trivyignore文件来声明# .trivyignore CVE-2023-12345 CVE-2023-67890.trivyignore文件必须放在代码仓库里并且每一次忽略都要通过commit记录写清楚原因这样后面审计的时候能追到底。千万别在命令行里悄悄加--ignore-unfixed那样会把“真正无修复方案”和“不作为”混为一谈。再往深一层说镜像扫描的终极形态是“生成并维护SBOM”。Trivy支持输出CycloneDX格式的清单trivy image --format cyclonedx --output result.cdx.json nginx:1.24SBOM是你软件供应链的底账里面每个组件、版本、依赖关系都一目了然。以后企业做合规审计、出了0day需要“排查影响面”时这份清单能让你在几分钟内回答“我哪些镜像受影响”而不是翻半天CI日志。我建议从第一天起就把SBOM生成集成到发布流水线中成本极低收益却可能在关键时刻救火。3. 集群配置与运行时检测把视角从镜像提升到集群3.1 用kube-bench对照CIS基线做配置体检镜像扫干净了不代表集群就安全了。Kubernetes集群本身的主机组件API Server、kubelet、etcd也存在大量安全配置项这些配置项业界有标准参照——CIS Kubernetes Benchmark。kube-bench就是专门用来检查集群是否符合CIS基线的工具。kube-bench的用法非常直白。在节点上直接跑kube-bench run --targets master,node --version 1.28它会输出类似下面的检查结果[PASS] 1.2.1 Ensure that the --anonymous-auth argument is set to false (Automated) [FAIL] 1.2.2 Ensure that the --token-auth-file parameter is not set (Automated) [WARN] 1.2.5 Ensure that the --kubelet-certificate-authority argument is set as appropriate (Automated)每一条FAIL都要人工确认。比如--token-auth-file这个老旧的静态令牌认证方式在云托管的Kubernetes里一般不会启用所以FAIL了也正常。但如果是自建的集群你就需要认真处理。kube-bench同样可以部署成Kubernetes Job每个节点跑一个Pod去检查宿主机配置。官方仓库里提供了job.yaml直接用就行。跑出来的结果要存档建议至少按月跑一次每次结果都保存到对象存储里方便做趋势对比。这里有个大坑我必须提醒在托管型Kubernetes比如云厂商的托管集群上你无法修改API Server的启动参数。kube-bench会报出一大堆FAIL但其中相当一部分是托管侧已经替你加固过了只是你无法查看宿主机配置而已。所以托管集群上跑kube-bench重点看它对你“可见节点”就是你的Node节点那一部分的检查结果master节点的项直接结合云厂商的合规文档来评估不要盲目逐条修复。3.2 用Falco盯运行时异常行为镜像扫描和配置扫描解决的是“部署前”的问题但攻击者真正打进集群往往发生在“运行后”。Falco是CNCF旗下的运行时安全项目它的做法很聪明利用内核的eBPF或者内核模块捕获系统调用再通过规则匹配判断容器行为是否越界。Falco默认规则覆盖得比较全包括但不限于容器内启动了新的shell、读取了敏感文件比如/etc/shadow、创建了可疑的网络连接、挂载了宿主机目录。你可以这样起一个快速验证falco -r /etc/falco/falco_rules.yaml然后故意在容器里执行cat /etc/shadowFalco立刻会在输出里打出类似这样的告警17:28:04.000000000: Error File below /etc opened for reading by non-trusted program (userroot commandcat /etc/shadow)告警事件里会带上Container ID、Pod名字、镜像名、用户等等有了这些上下文信息排查定位的速度会快很多。Falco在集群里一般以DaemonSet形式部署每个节点一个Pod。部署时可以只启核心规则集把事件输出到stdout再用采集组件比如Vector汇聚到告警平台。性能上Falco的开销实测在5%以内具体取决于节点负载和规则复杂度在大多数业务场景中是可接受的。不过要注意Falco默认的规则触发量很大如果集群里业务Pod很活跃告警会被刷爆一定要设置好告警聚合和降噪策略。3.3 权限扫描把过度授权暴露出来最后一个是权限的健康度检查。Kubernetes的RBAC非常灵活但灵活的另一面是“人人都能创建RoleBinding没人知道权限到底给了谁”。kubeaudit这个工具可以自动化扫描常见的权限问题比如Pod是否设置了privileged、是否以root运行、是否挂载了docker socket、ServiceAccount是否绑定了过大的角色。直接跑一下kubeaudit all它会扫描当前kubeconfig指向的所有资源输出------------------ Results for ----------- automountServiceAccountToken: true Container app has a privileged container Container app is not running as a non-root user每一行都指向一个具体的YAML字段问题修复方式也简单比如加一段securityContext: runAsNonRoot: true allowPrivilegeEscalation: false capabilities: drop: [ALL]这里我强烈建议把runAsNonRoot作为新服务必须遵守的硬性要求。原因是绝大多数容器逃逸漏洞利用的前提是“能以root身份在容器内执行代码”一旦你强制runAsNonRoot即使攻击者拿到了RCE也无法获得宿主机的root权限攻击链就被截断了。老服务可以给过渡期但新服务必须从第一天就带上这个配置。4. 从扫描到拦截用准入控制把“不安全”挡在集群外4.1 流水线里的扫描和集群入口的拦截要分清楚前面讲的扫描无论做得多完善本质上都是“事后检查”。CI里的扫描失败最多是拦住“某个镜像不打标签”但如果开发者直接绕过CI手动kubectl apply一个资源或者CI配置本身出了问题安全策略就形同虚设了。所以真正可靠的做法是在Kubernetes的API入口处加一道“准入控制”Admission Control让集群自己拒绝不符合安全要求的资源。Kubernetes的准入控制分为“变更准入”和“校验准入”我们这里主要用校验型。通过部署一个ValidatingWebhook可以在资源真正写入etcd之前拦截并校验这个Pod或Deployment是否满足安全条件。眼下实现策略即代码最主流的两套方案是OPA Gatekeeper和Kyverno。Gatekeeper基于OPAOpen Policy Agent用的是Rego语言写策略能力强但学习曲线陡峭Kyverno直接以Kubernetes资源的方式写策略YAML即策略上手更容易也比较适合运维团队维护。4.2 用Kyverno写一个“拒绝高危镜像”策略我直接给一个实战示例拦截“来自非可信仓库的镜像”和“以root运行的容器”。apiVersion: kyverno.io/v1 kind: ClusterPolicy metadata: name: require-run-as-nonroot-check-image spec: validationFailureAction: enforce rules: - name: check-image-annotations match: any: - resources: kinds: - Pod validate: message: 镜像必须来自registry.example.com且不允许以root运行。 anyPattern: - context: - name: imageData imageRegistry: reference: {{ request.object.spec.containers[*].image }} pattern: spec: containers: - image: registry.example.com/* securityContext: runAsNonRoot: true这个策略的validationFailureAction设为enforce意思是“不满足就直接拒绝创建”而不是只记录警告。建议先在测试命名空间用audit模式跑一段时间观察误杀率后再切换成enforce否则上线第一天可能把业务方的合法部署全拦了到时候运维是众矢之的。Kyverno还有一个加分项它能在资源创建时自动给Pod注入安全配置。比如你不想强迫开发改YAML可以写一条策略自动给所有新Pod加上runAsNonRoot: true和automountServiceAccountToken: false这属于“变更”玩法适合老业务渐进式改造比强制拦截更平滑。4.3 三个必须做的准入拦截项根据我在生产环境的经验最开始做准入控制时不需要写几十条策略抓大放小重点盯三件事第一件事镜像来源限制。集群里只允许跑来自指定私有仓库的镜像杜绝开发者把个人Docker Hub上的镜像直接往集群里扔。这既是安全要求也是供应链可追溯的前提。第二件事禁止特权容器。privileged: true的容器拥有宿主机的全部权限等于把节点钥匙直接发给了业务容器必须默认拒绝。如果确有特殊需求比如某些系统组件单独开一个命名空间并写上充分的审批说明。第三件事强制资源限制。虽然严格来说这和“安全扫描”不是一码事但资源限制CPU/memory的requests和limits能有效防止容器出现内存逃逸、CPU耗尽等放大型攻击它是运行时稳定性的基础。这三条拦住了集群的“安全水位”就上了一个大台阶。等稳定运行一两个月后再逐步叠加镜像漏洞等级、禁用挂载宿主机目录、限制ServiceAccount权限等更精细的策略。5. 安全扫描落地的常见问题与故障排查实录5.1 扫描工具跑不动的典型场景我先把实战中经常遇到的几个问题列出来这些问题几乎每个团队在引入安全扫描的初期都绕不开。问题表现可能原因排查思路与解决Trivy扫描特别慢耗时好几分钟镜像层数多且每次扫描都在重新下载漏洞库预先用trivy image --download-db-only定期拉库离线环境还要配--offline-scan扫描时不要每次在线更新CI里trivy扫描大镜像时OOM被杀容器内存限制太小给trivy扫描job单独设置内存比如resources: requests: 512Mi, limits: 2Gi也可以加--timeout 10m防止超时kube-bench在托管集群上FAIL一大堆托管集群控制面不可见基线检查项有相当一部分不适用不要逐条修先对照云厂商的“共享责任模型”文档把master节点检查项标记为“由平台提供”只看node节点结果Kyverno上线后业务Deployment被拦截策略写得过严或者模式设置错误先用validationFailureAction: audit跑一周看audit日志确认误报率再切enforce同时做好Exception资源豁免特定命名空间Falco事件刷屏告警几乎没法看默认规则集过于宽泛业务自身行为触发了大量告警保留核心规则合理配置-o输出过滤并将相同Pod、相同类型的告警做聚合在告警平台上设置阈值扫描报告显示有漏洞但开发不认开发认为漏洞不影响代码运行不要只看CVE结合trivy image --list-all-pkgs把受影响组件和调用链列出来带着证据去沟通同时要定义好“可接受风险”流程而不是让开发自行评估5.2 我踩过的三个大坑先说第一坑扫描结果“漂移”。早期我把镜像扫描放在CI的最后一步但扫描用的镜像是latest标签结果版本一更新CI历史记录里的扫描报告就全串了。后来改成每次构建都打上Git commit SHA的不可变标签扫描这个标签报告才能对应到代码版本。这个过程特别像我们日常做Kubernetes故障排查时“先确认Pod的UID和所属Deployment是否匹配”——版本和资产对应不对齐后面全白干。第二个坑只在“入口”扫描忽略了“存量资产”。许多团队把CI扫描做好了但线上集群里已经跑着几百个历史镜像这些存量资产才是最大的风险敞口。后来我专门写了一个定时任务定期扫描当前集群里所有正在运行的镜像通过kubectl get pods -A -o jsonpath提取镜像列表喂给Trivy并把结果按命名空间汇总优先处理“对外暴露服务”的命名空间。第三个坑准入控制策略和镜像扫描“脱节”。我见过一个环境Kyverno只校验“镜像仓库前缀”和“是否root运行”但镜像里的CVE完全不管结果等于“合格仓库里的坏镜像”照样进去。正确做法是让准入控制与漏洞数据库联动比如Kyverno配合Trivy的Trivy-Image策略一旦镜像的CRITICAL漏洞数量超过阈值准入就直接拒绝。Kubernetes安全不是靠某一个工具单打独斗它是一套“你中有我”的策略组合。5.3 安全扫描与Kubernetes故障排查的串联思路最后举个很常见的“从Pod到集群”的排查例子帮助你把安全扫描和日常故障处理结合起来想。场景某个Pod一直起不来事件里报CreateContainerConfigError或者ImagePullBackOff。很多人只会去翻镜像仓库的凭证但这时候第一反应应该是“ACL有没有变镜像是不是被扫描策略拦了”如果配置了准入控制Pod创建时会经历“API Server→Webhook→Trivy漏洞检查→策略校验”多条链路。任何一环出现问题在kubectl describe pod里都可能显示成Internal error occurred: failed calling webhook validate.kyverno.svc-fail。此时不要慌先看Webhook的日志再检查Kyverno策略是否误拦了合法镜像而不是直接在业务方侧排查镜像拉取问题。反过来说有些ImagePullBackOff是因为CI流水线里镜像扫描用了--exit-code 1导致“安全性校验失败镜像压根没推上去”。这种联动问题单一视角很难定位。我的经验是安全扫描体系上线之后运维的“故障排查地图”要重新梳理一遍。原来只要会看Pod状态、Events、kubelet日志就行现在还需要会看Scan Report、Webhook日志、Policy Engine事件和告警中心。问题定位的思路从“这条链哪挂了”变成了“这条链的哪个环节断了、是网络断了还是安全策略断了”。这套技能树更新完之后排查故障的效率其实比之前更高因为很多问题在安全策略这一层就被显式拦下来了反而是“透明的好处”。6. 给想要实践的人一份最小落地清单安全扫描最容易犯的错不是“没有方案”而是“什么都想上”结果一个也没落地。如果你所在团队Kubernetes环境刚起步安全水位还很浅我建议按这个顺序来每一步都能独立产生价值不需要等前面的步骤完美了才做下一步。第一步部署Trivy先把CI流水线里的镜像扫描跑起来至少做到“新镜像有CRITICAL漏洞不允许合入”。这一步最快半天到一天就能见效。第二步把SBOM生成加进发布流水线每次构建产出一份CycloneDX格式的清单文件并归档。这一步不改变发布流程只是多存一份元数据但对后续安全审计和漏洞溯源意义很大。第三步跑一次kube-bench和kubeaudit把当前集群的配置和权限现状摸清楚。目标是产出“现状报告修复计划”不追求一次全改完但至少要让团队知道“我们目前哪些地方是裸奔的”。第四步在测试命名空间部署Kyverno先写三条核心策略镜像来源、拒绝特权、runAsNonRoot用audit模式观察一周确认无误后切enforce。第五步叠加Falco做运行时监控先接告警再过滤降噪。运行时监控可以晚一点做因为前面几步已经把“入口的风险”大幅降低了。这套流程走完你的Kubernetes集群就从“知道有哪些漏洞”进化到了“能在源头拦截大部分不安全因素”而且每一步都不依赖商业产品社区开源生态完全够用。最后再说两句心里话。Kubernetes安全扫描这件事本质上不是“上个工具扫一遍”那么轻松它更像是一套持续运转的流程——扫描出报告只是开始报告里每一项判定的处置、责任人、时间点才是真正消耗精力的地方。我见过集群里躺着几百条未处理的漏洞报告也见过团队为了“扫描通过”而把阈值调到形同虚设这两种极端都不可取。安全扫描真正的价值是让“不安全的变更”在到达集群之前就被识别和拦截而不是在事故发生之后靠人工打补丁。从一个小镜像仓库开始从一条准入策略开始一点一点收紧这是我在多次踩坑之后最想分享的建议。 
长河君 · 2026/9/9 15:02:44 · 阅读 1.2k Kubernetes安全扫描实操：镜像漏洞、配置漂移与准入控制全解析
1. 安全扫描前先弄明白Kubernetes集群到底有哪些安全风险先说我自己的经历。干了这么多年运维Kubernetes这块踩过的坑不少但真正让我下定决心把安全扫描当成“必做项”的是有一次线上集群被安全通告点名说某个存量镜像存在高危CVE而且已经对外暴露了端口。当时最大的问题不是“漏洞怎么修”而是“这个漏洞到底在哪、有多少个镜像受影响、哪些命名空间在跑”我们居然答不上来。那一刻我才意识到Kubernetes环境里如果连“资产画像”都没建立起来安全扫描就是无源之水。很多刚接触Kubernetes安全的人第一反应是“我装个Trivy扫一下镜像不就行了”这话对了一半。镜像扫描确实是最基础的一环但Kubernetes集群的安全风险和传统虚拟机时代完全是两码事。我习惯把集群内的安全风险拆成五个维度镜像漏洞、配置漂移、运行时异常、权限过载、依赖供应链。这五个维度的攻防视角完全不同扫描工具也完全不重叠。先说镜像漏洞。这是最直观的也是安全团队最爱盯的。Docker镜像里藏着大量的系统包、语言依赖库、二进制文件任何一个上游组件出了CVE你的镜像就可能被打穿。但这里有个关键误区镜像扫描只能告诉你“镜像里有什么漏洞”它无法告诉你“这个漏洞在当前运行环境里是否真的可利用”。比如某个CVE只在特定内核版本下生效而你的宿主内核早已修复那这个漏洞在运行时就是“假阳性”。所以镜像扫描的产出一定要结合运行时上下文来看不能见洞就堵。再说配置漂移。Kubernetes是声明式架构所有的期望状态都写在YAML里——Pod是不是允许以root身份运行、有没有开启特权模式、容器是否设置了CPU限制、Secret有没有明文写在环境变量里这些全部可以通过静态配置扫描来检测。我见过不少团队镜像扫得干干净净结果deployment里直接写着privileged: true或者把ServiceAccount绑到了cluster-admin这种漏洞比镜像CVE更容易被利用也更容易被忽视。运行时异常是另一个维度。镜像和配置都是“静态检查”但攻击往往是动态发生的。你无法通过扫描镜像来发现“这个容器正在尝试读取宿主机的/etc/shadow”也无法知道“有人从外部网络在容器内启动了反弹shell”。这类问题需要运行时安全检测工具比如Falco通过内核事件和系统调用来判断容器行为是否越界。权限过载则是Kubernetes特有的风险放大器。RBAC基于角色的访问控制设计得再好也需要持续审计。很多集群里业务Pod带着高权限的ServiceAccountPod的automountServiceAccountToken也没关攻击者一旦打进容器直接就拿到了调用Kubernetes API的凭证。权限扫描要做的是把这些过度授权的账号、绑定、角色一个个揪出来而不是等出了事再复盘。最后是依赖供应链。这个维度很多人会忽略但实际影响很大。你引入的Helm Chart是否来自可信仓库Chart里有没有嵌套恶意镜像基础镜像的tag是不是latest这种漂移标签这些都属于供应链安全的范畴。好在现在很多镜像扫描工具已经支持SBOM软件物料清单生成可以把你镜像里所有组件清单化、版本化这是后续做漏洞溯源的基础。把这五个维度写在前面是为了让大家先建立全局观因为它决定了你后面选工具、定流程、设阈值时眼睛该往哪里看。接下来的内容我按照“静态扫描→运行时检测→策略联动→故障排查”这条主线把每个环节的落地细节和踩到的坑都讲一清二楚。2. 镜像安全扫描用Trivy把第一道防线建起来2.1 为什么镜像扫描是第一个要做的我得说句实话如果你所在团队目前对Kubernetes安全完全没概念那就从镜像扫描开始。理由很简单——它是所有安全手段里“投入产出比”最高的。镜像扫描只需要在CI流水线里加一步或者在镜像仓库里挂一个定时任务就能在“源头”拦截绝大多数已知漏洞不需要理解复杂的Kubernetes调度和准入控制机制。对比一下大家常用的几种工具Trivy、Clair、Anchore。Clair是CoreOS开源的老牌扫描器设计上偏向服务端部署需要搭配PostgreSQL数据库比较重Anchore Engine功能全面但同样部署成本高。Trivy从一开始就定位于“又快又准又轻量”单个二进文件就能跑漏洞库更新也频繁还内置了多种语言的依赖扫描支持所以我个人推荐把Trivy作为镜像扫描第一选择。Trivy还有一个很实用的特性它不只是扫系统包还能扫描应用依赖比如Python的requirements.txt、Node.js的package-lock.json里的已知漏洞。这就意味着即使你的镜像基础层干干净净应用层引入了一个有漏洞的第三方库Trivy也能扫得出来。2.2 Trivy从命令行到CI流水线的快速落地先看最基本的命令。假设我们要扫描一个nginx镜像在本地直接执行trivy image --exit-code 1 --severity HIGH,CRITICAL nginx:1.24这里--severity指定了关注等级--exit-code 1表示“只要扫出高危或致命漏洞就返回非零退出码”。这个退出码非常关键后续接CI流水线时就是靠它来决定“构建是继续还是失败”的。实际跑一次你会发现Trivy扫描速度快得惊人扫描一个常见的nginx镜像通常只需要几秒这得益于它采用“先离线下载漏洞库再按镜像层级和包管理器特征去匹配”的策略而不是像某些商业扫描器那样在线查询每个包。离线环境下也只需要先用trivy image --download-db-only把漏洞库镜像拉下来后续扫描直接复用不依赖公网。扫出来的结果一般是表格或者JSON格式。我建议在CI阶段把完整JSON报告归档到制品库这样后续做漏洞追踪时有据可查。生成的概览大概是这个画风漏洞ID组件版本严重性已修复版本CVE-2024-24989nginx1.24.0HIGH1.25.0CVE-2023-4863libwebp1.2.4CRITICAL1.3.2到了CI集成环节以GitLab CI为例可以在.gitlab-ci.yml里加一个stageimage_scan: stage: test image: docker.io/aquasec/trivy:0.51.0 script: - trivy image --exit-code 1 --severity HIGH,CRITICAL --no-progress $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA only: - main这里有几个细节值得注意。第一--no-progress是因为CI日志里不需要进度条否则日志会被刷屏第二扫描的镜像是$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA也就是“当前待发布的镜像”而不是latest——用漂移标签会导致扫描结果分不清是哪个版本后面排查的时候非常痛苦。2.3 漏洞阈值、忽略机制和SBOM管理很多人配置完CI就以为万事大吉了。实际上“扫描通过”和“真的安全”之间隔着一层很厚的理解。你需要先确定“怎样的镜像输出才允许上线”。我见过两种极端一种是太宽松只扫CRITICAL导致一堆HIGH漏洞带病上线另一种是太严格见漏洞就fail结果开发抵制最终整个扫描环节被绕过。我个人的建议是新发布的镜像要求“CRITICAL必须清零”HIGH可以容忍24小时内给出修复计划MEDIUM及以下走常规流程即可。但这只是个起点。Trivy有一个--ignore-unfixed参数它只报告有已修复版本的漏洞。这个参数非常实用——没有修复方案的高危漏洞你就算fail了流水线也只能干瞪眼不如先放行但记录在案。此外有些CVE确实影响到了你的镜像但你评估过业务场景后认为不可利用可以通过.trivyignore文件来声明# .trivyignore CVE-2023-12345 CVE-2023-67890.trivyignore文件必须放在代码仓库里并且每一次忽略都要通过commit记录写清楚原因这样后面审计的时候能追到底。千万别在命令行里悄悄加--ignore-unfixed那样会把“真正无修复方案”和“不作为”混为一谈。再往深一层说镜像扫描的终极形态是“生成并维护SBOM”。Trivy支持输出CycloneDX格式的清单trivy image --format cyclonedx --output result.cdx.json nginx:1.24SBOM是你软件供应链的底账里面每个组件、版本、依赖关系都一目了然。以后企业做合规审计、出了0day需要“排查影响面”时这份清单能让你在几分钟内回答“我哪些镜像受影响”而不是翻半天CI日志。我建议从第一天起就把SBOM生成集成到发布流水线中成本极低收益却可能在关键时刻救火。3. 集群配置与运行时检测把视角从镜像提升到集群3.1 用kube-bench对照CIS基线做配置体检镜像扫干净了不代表集群就安全了。Kubernetes集群本身的主机组件API Server、kubelet、etcd也存在大量安全配置项这些配置项业界有标准参照——CIS Kubernetes Benchmark。kube-bench就是专门用来检查集群是否符合CIS基线的工具。kube-bench的用法非常直白。在节点上直接跑kube-bench run --targets master,node --version 1.28它会输出类似下面的检查结果[PASS] 1.2.1 Ensure that the --anonymous-auth argument is set to false (Automated) [FAIL] 1.2.2 Ensure that the --token-auth-file parameter is not set (Automated) [WARN] 1.2.5 Ensure that the --kubelet-certificate-authority argument is set as appropriate (Automated)每一条FAIL都要人工确认。比如--token-auth-file这个老旧的静态令牌认证方式在云托管的Kubernetes里一般不会启用所以FAIL了也正常。但如果是自建的集群你就需要认真处理。kube-bench同样可以部署成Kubernetes Job每个节点跑一个Pod去检查宿主机配置。官方仓库里提供了job.yaml直接用就行。跑出来的结果要存档建议至少按月跑一次每次结果都保存到对象存储里方便做趋势对比。这里有个大坑我必须提醒在托管型Kubernetes比如云厂商的托管集群上你无法修改API Server的启动参数。kube-bench会报出一大堆FAIL但其中相当一部分是托管侧已经替你加固过了只是你无法查看宿主机配置而已。所以托管集群上跑kube-bench重点看它对你“可见节点”就是你的Node节点那一部分的检查结果master节点的项直接结合云厂商的合规文档来评估不要盲目逐条修复。3.2 用Falco盯运行时异常行为镜像扫描和配置扫描解决的是“部署前”的问题但攻击者真正打进集群往往发生在“运行后”。Falco是CNCF旗下的运行时安全项目它的做法很聪明利用内核的eBPF或者内核模块捕获系统调用再通过规则匹配判断容器行为是否越界。Falco默认规则覆盖得比较全包括但不限于容器内启动了新的shell、读取了敏感文件比如/etc/shadow、创建了可疑的网络连接、挂载了宿主机目录。你可以这样起一个快速验证falco -r /etc/falco/falco_rules.yaml然后故意在容器里执行cat /etc/shadowFalco立刻会在输出里打出类似这样的告警17:28:04.000000000: Error File below /etc opened for reading by non-trusted program (userroot commandcat /etc/shadow)告警事件里会带上Container ID、Pod名字、镜像名、用户等等有了这些上下文信息排查定位的速度会快很多。Falco在集群里一般以DaemonSet形式部署每个节点一个Pod。部署时可以只启核心规则集把事件输出到stdout再用采集组件比如Vector汇聚到告警平台。性能上Falco的开销实测在5%以内具体取决于节点负载和规则复杂度在大多数业务场景中是可接受的。不过要注意Falco默认的规则触发量很大如果集群里业务Pod很活跃告警会被刷爆一定要设置好告警聚合和降噪策略。3.3 权限扫描把过度授权暴露出来最后一个是权限的健康度检查。Kubernetes的RBAC非常灵活但灵活的另一面是“人人都能创建RoleBinding没人知道权限到底给了谁”。kubeaudit这个工具可以自动化扫描常见的权限问题比如Pod是否设置了privileged、是否以root运行、是否挂载了docker socket、ServiceAccount是否绑定了过大的角色。直接跑一下kubeaudit all它会扫描当前kubeconfig指向的所有资源输出------------------ Results for ----------- automountServiceAccountToken: true Container app has a privileged container Container app is not running as a non-root user每一行都指向一个具体的YAML字段问题修复方式也简单比如加一段securityContext: runAsNonRoot: true allowPrivilegeEscalation: false capabilities: drop: [ALL]这里我强烈建议把runAsNonRoot作为新服务必须遵守的硬性要求。原因是绝大多数容器逃逸漏洞利用的前提是“能以root身份在容器内执行代码”一旦你强制runAsNonRoot即使攻击者拿到了RCE也无法获得宿主机的root权限攻击链就被截断了。老服务可以给过渡期但新服务必须从第一天就带上这个配置。4. 从扫描到拦截用准入控制把“不安全”挡在集群外4.1 流水线里的扫描和集群入口的拦截要分清楚前面讲的扫描无论做得多完善本质上都是“事后检查”。CI里的扫描失败最多是拦住“某个镜像不打标签”但如果开发者直接绕过CI手动kubectl apply一个资源或者CI配置本身出了问题安全策略就形同虚设了。所以真正可靠的做法是在Kubernetes的API入口处加一道“准入控制”Admission Control让集群自己拒绝不符合安全要求的资源。Kubernetes的准入控制分为“变更准入”和“校验准入”我们这里主要用校验型。通过部署一个ValidatingWebhook可以在资源真正写入etcd之前拦截并校验这个Pod或Deployment是否满足安全条件。眼下实现策略即代码最主流的两套方案是OPA Gatekeeper和Kyverno。Gatekeeper基于OPAOpen Policy Agent用的是Rego语言写策略能力强但学习曲线陡峭Kyverno直接以Kubernetes资源的方式写策略YAML即策略上手更容易也比较适合运维团队维护。4.2 用Kyverno写一个“拒绝高危镜像”策略我直接给一个实战示例拦截“来自非可信仓库的镜像”和“以root运行的容器”。apiVersion: kyverno.io/v1 kind: ClusterPolicy metadata: name: require-run-as-nonroot-check-image spec: validationFailureAction: enforce rules: - name: check-image-annotations match: any: - resources: kinds: - Pod validate: message: 镜像必须来自registry.example.com且不允许以root运行。 anyPattern: - context: - name: imageData imageRegistry: reference: {{ request.object.spec.containers[*].image }} pattern: spec: containers: - image: registry.example.com/* securityContext: runAsNonRoot: true这个策略的validationFailureAction设为enforce意思是“不满足就直接拒绝创建”而不是只记录警告。建议先在测试命名空间用audit模式跑一段时间观察误杀率后再切换成enforce否则上线第一天可能把业务方的合法部署全拦了到时候运维是众矢之的。Kyverno还有一个加分项它能在资源创建时自动给Pod注入安全配置。比如你不想强迫开发改YAML可以写一条策略自动给所有新Pod加上runAsNonRoot: true和automountServiceAccountToken: false这属于“变更”玩法适合老业务渐进式改造比强制拦截更平滑。4.3 三个必须做的准入拦截项根据我在生产环境的经验最开始做准入控制时不需要写几十条策略抓大放小重点盯三件事第一件事镜像来源限制。集群里只允许跑来自指定私有仓库的镜像杜绝开发者把个人Docker Hub上的镜像直接往集群里扔。这既是安全要求也是供应链可追溯的前提。第二件事禁止特权容器。privileged: true的容器拥有宿主机的全部权限等于把节点钥匙直接发给了业务容器必须默认拒绝。如果确有特殊需求比如某些系统组件单独开一个命名空间并写上充分的审批说明。第三件事强制资源限制。虽然严格来说这和“安全扫描”不是一码事但资源限制CPU/memory的requests和limits能有效防止容器出现内存逃逸、CPU耗尽等放大型攻击它是运行时稳定性的基础。这三条拦住了集群的“安全水位”就上了一个大台阶。等稳定运行一两个月后再逐步叠加镜像漏洞等级、禁用挂载宿主机目录、限制ServiceAccount权限等更精细的策略。5. 安全扫描落地的常见问题与故障排查实录5.1 扫描工具跑不动的典型场景我先把实战中经常遇到的几个问题列出来这些问题几乎每个团队在引入安全扫描的初期都绕不开。问题表现可能原因排查思路与解决Trivy扫描特别慢耗时好几分钟镜像层数多且每次扫描都在重新下载漏洞库预先用trivy image --download-db-only定期拉库离线环境还要配--offline-scan扫描时不要每次在线更新CI里trivy扫描大镜像时OOM被杀容器内存限制太小给trivy扫描job单独设置内存比如resources: requests: 512Mi, limits: 2Gi也可以加--timeout 10m防止超时kube-bench在托管集群上FAIL一大堆托管集群控制面不可见基线检查项有相当一部分不适用不要逐条修先对照云厂商的“共享责任模型”文档把master节点检查项标记为“由平台提供”只看node节点结果Kyverno上线后业务Deployment被拦截策略写得过严或者模式设置错误先用validationFailureAction: audit跑一周看audit日志确认误报率再切enforce同时做好Exception资源豁免特定命名空间Falco事件刷屏告警几乎没法看默认规则集过于宽泛业务自身行为触发了大量告警保留核心规则合理配置-o输出过滤并将相同Pod、相同类型的告警做聚合在告警平台上设置阈值扫描报告显示有漏洞但开发不认开发认为漏洞不影响代码运行不要只看CVE结合trivy image --list-all-pkgs把受影响组件和调用链列出来带着证据去沟通同时要定义好“可接受风险”流程而不是让开发自行评估5.2 我踩过的三个大坑先说第一坑扫描结果“漂移”。早期我把镜像扫描放在CI的最后一步但扫描用的镜像是latest标签结果版本一更新CI历史记录里的扫描报告就全串了。后来改成每次构建都打上Git commit SHA的不可变标签扫描这个标签报告才能对应到代码版本。这个过程特别像我们日常做Kubernetes故障排查时“先确认Pod的UID和所属Deployment是否匹配”——版本和资产对应不对齐后面全白干。第二个坑只在“入口”扫描忽略了“存量资产”。许多团队把CI扫描做好了但线上集群里已经跑着几百个历史镜像这些存量资产才是最大的风险敞口。后来我专门写了一个定时任务定期扫描当前集群里所有正在运行的镜像通过kubectl get pods -A -o jsonpath提取镜像列表喂给Trivy并把结果按命名空间汇总优先处理“对外暴露服务”的命名空间。第三个坑准入控制策略和镜像扫描“脱节”。我见过一个环境Kyverno只校验“镜像仓库前缀”和“是否root运行”但镜像里的CVE完全不管结果等于“合格仓库里的坏镜像”照样进去。正确做法是让准入控制与漏洞数据库联动比如Kyverno配合Trivy的Trivy-Image策略一旦镜像的CRITICAL漏洞数量超过阈值准入就直接拒绝。Kubernetes安全不是靠某一个工具单打独斗它是一套“你中有我”的策略组合。5.3 安全扫描与Kubernetes故障排查的串联思路最后举个很常见的“从Pod到集群”的排查例子帮助你把安全扫描和日常故障处理结合起来想。场景某个Pod一直起不来事件里报CreateContainerConfigError或者ImagePullBackOff。很多人只会去翻镜像仓库的凭证但这时候第一反应应该是“ACL有没有变镜像是不是被扫描策略拦了”如果配置了准入控制Pod创建时会经历“API Server→Webhook→Trivy漏洞检查→策略校验”多条链路。任何一环出现问题在kubectl describe pod里都可能显示成Internal error occurred: failed calling webhook validate.kyverno.svc-fail。此时不要慌先看Webhook的日志再检查Kyverno策略是否误拦了合法镜像而不是直接在业务方侧排查镜像拉取问题。反过来说有些ImagePullBackOff是因为CI流水线里镜像扫描用了--exit-code 1导致“安全性校验失败镜像压根没推上去”。这种联动问题单一视角很难定位。我的经验是安全扫描体系上线之后运维的“故障排查地图”要重新梳理一遍。原来只要会看Pod状态、Events、kubelet日志就行现在还需要会看Scan Report、Webhook日志、Policy Engine事件和告警中心。问题定位的思路从“这条链哪挂了”变成了“这条链的哪个环节断了、是网络断了还是安全策略断了”。这套技能树更新完之后排查故障的效率其实比之前更高因为很多问题在安全策略这一层就被显式拦下来了反而是“透明的好处”。6. 给想要实践的人一份最小落地清单安全扫描最容易犯的错不是“没有方案”而是“什么都想上”结果一个也没落地。如果你所在团队Kubernetes环境刚起步安全水位还很浅我建议按这个顺序来每一步都能独立产生价值不需要等前面的步骤完美了才做下一步。第一步部署Trivy先把CI流水线里的镜像扫描跑起来至少做到“新镜像有CRITICAL漏洞不允许合入”。这一步最快半天到一天就能见效。第二步把SBOM生成加进发布流水线每次构建产出一份CycloneDX格式的清单文件并归档。这一步不改变发布流程只是多存一份元数据但对后续安全审计和漏洞溯源意义很大。第三步跑一次kube-bench和kubeaudit把当前集群的配置和权限现状摸清楚。目标是产出“现状报告修复计划”不追求一次全改完但至少要让团队知道“我们目前哪些地方是裸奔的”。第四步在测试命名空间部署Kyverno先写三条核心策略镜像来源、拒绝特权、runAsNonRoot用audit模式观察一周确认无误后切enforce。第五步叠加Falco做运行时监控先接告警再过滤降噪。运行时监控可以晚一点做因为前面几步已经把“入口的风险”大幅降低了。这套流程走完你的Kubernetes集群就从“知道有哪些漏洞”进化到了“能在源头拦截大部分不安全因素”而且每一步都不依赖商业产品社区开源生态完全够用。最后再说两句心里话。Kubernetes安全扫描这件事本质上不是“上个工具扫一遍”那么轻松它更像是一套持续运转的流程——扫描出报告只是开始报告里每一项判定的处置、责任人、时间点才是真正消耗精力的地方。我见过集群里躺着几百条未处理的漏洞报告也见过团队为了“扫描通过”而把阈值调到形同虚设这两种极端都不可取。安全扫描真正的价值是让“不安全的变更”在到达集群之前就被识别和拦截而不是在事故发生之后靠人工打补丁。从一个小镜像仓库开始从一条准入策略开始一点一点收紧这是我在多次踩坑之后最想分享的建议。