容器运行时漂移检测实战指南：基于 Falco 与 Kubernetes 实现不可变基础设施的运行时安全监控

容器运行时漂移检测实战指南：基于 Falco 与 Kubernetes 实现不可变基础设施的运行时安全监控

【免费下载链接】Anthropic-Cybersecurity-Skills817 structured cybersecurity skills for AI agents · Mapped to 6 frameworks: MITRE ATT&CK, NIST CSF 2.0, MITRE ATLAS, D3FEND, NIST AI RMF & MITRE F3 (Fight Fraud) · agentskills.io standard · Works with Claude Code, GitHub Copilot, Codex CLI, Cursor, Gemini CLI & 20+ platforms · 29 security domains · Apache 2.0项目地址: https://gitcode.com/GitHub_Trending/an/Anthropic-Cybersecurity-Skills

容器漂移（Container Drift）指运行中的容器偏离其原始镜像状态——包括未经授权的文件修改、意外二进制执行、配置变更或运行时安装软件包。由于容器应被视为不可变基础设施（Immutable Infrastructure），任何漂移都可能是入侵指标（IoC）。本指南以本仓库skills/detecting-container-drift-at-runtime技能为骨架，系统讲解漂移的类型与检测方法、Falco 规则编写、Kubernetes 加固手段、镜像摘要验证，以及 DIE（Detect/Isolate/Evict，检测—隔离—驱逐）响应模型，并深入剖析仓库自带的两套 Python 检测脚本，帮助安全工程师、DevSecOps 与 SOC 分析师建立从检测到响应的完整闭环能力。

一、技能文档总览与适用场景

本技能（skills/detecting-container-drift-at-runtime/SKILL.md）面向"容器安全 / 运行时安全"子领域，版本 1.0，作者 mahipal，采用 Apache-2.0 许可。其 frontmatter 将本技能映射到两个安全框架：

• NIST CSF 2.0：PR.PS-01（平台安全）、PR.IR-01（基础设施韧性）、ID.AM-08（软件平台与应用的资产清单）、DE.CM-01（网络与活动的持续监控）。在仓库的 NIST CSF 对齐表 中，container-security 子域的定位是 Protect（保护）主导、兼顾 Identify 与 Detect，主类别为 PR.PS（平台安全）与 GV.SC（供应链风险）。
• MITRE ATT&CK：T1610（部署容器）、T1611（逃逸到宿主机）、T1609（容器管理套件中继）、T1525（不可信镜像启动容器），与 标准参考 中列出的T1059.004（Unix Shell 执行）、T1105（进入容器下载工具）共同构成对抗矩阵视角。

适用时机

• 调查安全事件时需要检测容器运行时漂移；
• 为容器运行时检测构建告警规则或威胁狩猎查询；
• SOC 分析师需要本领域结构化的分析流程；
• 验证针对相关攻击技术的安全监控覆盖度。

前置条件

• Kubernetes 集群 v1.24+ 并配备运行时安全工具；
• Falco 或 Sysdig 用于运行时漂移检测；
• 具备可获取镜像 manifest 的容器镜像仓库；
• 熟悉 Linux 文件系统层与 OverlayFS 工作原理。

二、核心概念：容器漂移的类型与检测方法

2.1 五类容器漂移

1. 二进制漂移（Binary drift）：执行原始镜像中不存在的二进制文件（下载的恶意软件、编译工具等）。这是最直接、最危险的漂移信号——攻击者在拿到 shell 后通常会下载渗透工具或恶意载荷。
2. 文件漂移（File drift）：容器文件系统中文件的创建、修改或删除。
3. 配置漂移（Configuration drift）：环境变量、挂载的 Secret 或运行时参数的变更。
4. 包漂移（Package drift）：运行时通过 apt、yum、pip 或 npm 安装新软件包。
5. 网络漂移（Network drift）：出现工作负载不应有的新监听端口或出站连接。

2.2 三类检测方法

基于镜像比对（Image-Based Comparison）：将运行中容器的文件系统与源镜像对比，识别新增、修改或删除的文件。Docker 的container.diff()API 正是为此而生，仓库中的agent.py脚本将其作为核心检测手段（详见下文）。

行为监控（Behavioral Monitoring）：使用 eBPF 或内核级监控检测偏离预期行为的进程执行、文件访问与网络活动。Falco 即采用此路线——它以内核模块或 eBPF 探针挂载 syscall 级事件，配合规则引擎实时判定。

摘要验证（Digest Verification）：持续验证运行中容器镜像摘要与已批准部署清单是否一致。凡使用可变标签（app:latest）而非@sha256:摘要的部署，都无法保证"部署的即批准的"。

三、Falco 实现：从规则到告警

Falco 规则的核心是condition字段——由spawned_process、container、proc.*、fd.*等事件字段组成的谓词表达式。以下规则均可在 api-reference.md 中找到对应的最小形式，此处给出完整可落地的版本。

3.1 检测新二进制执行（核心规则）

Falco 提供的proc.is_exe_upper_layer字段能够直接判断"被执行的二进制是否位于容器镜像的 upper layer"——即执行的文件不在原始镜像中。这一字段是二进制漂移检测的基石：

- rule: Drift Detected (Container Image Modified Binary) desc: Detect execution of a binary not present in the original container image condition: > spawned_process and container and not proc.pname in (container_entrypoint) and proc.is_exe_upper_layer = true output: > Drift detected: new binary executed in container (user=%user.name command=%proc.cmdline container=%container.name image=%container.image.repository:%container.image.tag exe_path=%proc.exepath) priority: WARNING tags: [container, drift]

• proc.is_exe_upper_layer = true：二进制文件来自容器文件系统的可写 upper layer，而非只读镜像层；
• not proc.pname in (container_entrypoint)：排除容器入口点进程的正常启动链，降低误报；
• %proc.exepath输出可执行文件路径，便于后续取证。

3.2 检测容器内交互 Shell

不可变容器中不应出现交互式 Shell，任何 shell 的启动都值得警惕：

- rule: Container Shell Spawned desc: Detect interactive shell in a container that should be immutable condition: > spawned_process and container and proc.name in (bash, sh, dash, zsh, csh, ksh) and not proc.pname in (container_entrypoint) output: > Shell spawned in container (user=%user.name shell=%proc.name container=%container.name image=%container.image.repository) priority: WARNING tags: [container, drift, shell]

3.3 检测包管理器执行（包漂移）

运行时执行包管理器几乎等于"攻击者正在安装工具或恶意依赖"：

- rule: Package Manager Execution in Container desc: Detect use of package managers indicating drift condition: > spawned_process and container and proc.name in (apt, apt-get, yum, dnf, apk, pip, pip3, npm, gem, cargo) output: > Package manager executed in container (user=%user.name command=%proc.cmdline container=%container.name image=%container.image.repository) priority: ERROR tags: [container, drift, package-manager]

注意此规则的优先级为ERROR（高于二进制漂移的WARNING），因为包管理器执行几乎不存在正当场景——若业务确实需要在启动时装包，应通过镜像构建阶段解决，而非运行时。

3.4 检测文件系统写入（文件漂移）

对容器可写层（upper layer）的写操作进行监控，需要排除正常的临时目录与日志目录，否则会产生大量误报：

- rule: Container File System Write desc: Detect writes to container upper layer filesystem condition: > open_write and container and fd.typechar = 'f' and not fd.name startswith /tmp and not fd.name startswith /var/log and not fd.name startswith /proc output: > File write in container (user=%user.name file=%fd.name container=%container.name) priority: NOTICE tags: [container, drift, filesystem]

四、Kubernetes 强制措施：从源头阻止漂移

检测漂移是"事后发现"，而更优的策略是让漂移不可能发生。

4.1 只读根文件系统（Read-Only Root Filesystem）

readOnlyRootFilesystem: true是阻止漂移的最强手段之一。需要可写空间的应用通过emptyDir显式挂载，从而把"可写区域"收敛到明确声明的目录：

apiVersion: apps/v1 kind: Deployment metadata: name: immutable-app spec: template: spec: containers: - name: app image: app:v1.0@sha256:abc123... securityContext: readOnlyRootFilesystem: true allowPrivilegeEscalation: false runAsNonRoot: true volumeMounts: - name: tmp mountPath: /tmp - name: cache mountPath: /var/cache volumes: - name: tmp emptyDir: sizeLimit: 100Mi - name: cache emptyDir: sizeLimit: 50Mi

要点：

• 镜像引用采用app:v1.0@sha256:abc123...摘要格式（可复制的部署）；
• allowPrivilegeEscalation: false禁止提权，runAsNonRoot: true强制非 root 运行；
• emptyDir设置sizeLimit防止临时目录被写爆导致 DoS；
• 若应用必须写/tmp、/var/cache等路径，一律显式挂载为 emptyDir，保持根文件系统只读。

4.2 Pod 安全标准（Pod Security Standards）

在命名空间级别强制 Pod Security Standards（PSS）的restricted档位，从准入层面拒绝违反不可变原则的 Pod：

apiVersion: v1 kind: Namespace metadata: name: production labels: pod-security.kubernetes.io/enforce: restricted pod-security.kubernetes.io/audit: restricted pod-security.kubernetes.io/warn: restricted

三个标签的作用：

• enforce：直接拒绝不符合的 Pod；
• audit：记录审计事件但不拒绝；
• warn：向用户返回警告但不拒绝。

4.3 补充加固项

api-reference.md 中还给出了 securityContext 的完整加固形态：

securityContext: readOnlyRootFilesystem: true # prevent drift allowPrivilegeEscalation: false runAsNonRoot: true capabilities: drop: ["ALL"]

drop: ["ALL"]丢弃全部 Linux capabilities，配合非 root 运行，即使攻击者拿到容器内代码执行能力，也难以进行提权或逃逸操作。

五、镜像摘要持续验证

使用可变标签（如latest）的容器存在"漂移而不自知"的风险——镜像内容可能在部署后发生变化。以下是 SKILL.md 提供的持续摘要监控脚本，扫描命名空间内所有 Pod，标记使用可变标签的容器：

#!/bin/bash # Compare running container digests against approved manifest NAMESPACE="production" kubectl get pods -n "$NAMESPACE" -o json | jq -r ' .items[] | .spec.containers[] | "\(.image) \(.imageID)" ' | while read IMAGE IMAGE_ID; do APPROVED_DIGEST=$(kubectl get deploy -n "$NAMESPACE" -o json | \ jq -r ".items[].spec.template.spec.containers[] | select(.image==\"$IMAGE\") | .image") if [[ "$IMAGE" != *"@sha256:"* ]]; then echo "[WARN] Container using mutable tag: $IMAGE" fi done

脚本逻辑：从 Pod 的.spec.containers[].image与.imageID提取运行引用，与 Deployment 清单中的批准镜像比对，凡不含@sha256:即判定为可变标签并告警。生产建议：在 CI/CD 出口统一改写为摘要引用，从根本上消除可变标签。

六、仓库源码级实现：两套漂移检测脚本

技能目录下附带两个可直接运行/参考的 Python 实现，分别从Docker 单机视角与Kubernetes 集群视角落地漂移检测，是对前述检测方法的工程化印证。

6.1agent.py：基于 Docker SDK 的单容器审计

agent.py 实现"镜像比对 + 进程行为"的复合检测，核心链路如下：

① 文件系统比对（镜像比对方法）：get_container_diff()调用 Docker SDK 的container.diff()，得到容器相对源镜像的变更列表，并按Kind分类——0=修改、1=新增、2=删除（参见 api-reference.md 中的 Kind 语义），分别归入added/modified/deleted三类。

② 进程采集：get_running_processes()通过docker top <container> -eo pid,user,comm,args获取容器进程树。

③ 漂移指标判定：detect_drift_indicators()内置三类黑白名单，是检测规则的"脚本化"形态：

PACKAGE_MANAGERS = {"apt", "apt-get", "yum", "dnf", "apk", "pip", "pip3", "npm", "gem"} SHELLS = {"bash", "sh", "dash", "zsh", "csh", "ash"} SUSPICIOUS_BINARIES = {"curl", "wget", "nc", "ncat", "netcat", "socat", "python", "perl", "gcc", "cc", "make", "nmap", "tcpdump"}

判定逻辑包括：新增可疑二进制（HIGH）、新增到/usr/bin//usr/sbin的系统路径二进制（HIGH）、/etc/passwd//etc/shadow//etc/sudoers被修改（CRITICAL）、/etc/cron*被修改（HIGH）、运行包管理器（HIGH）、root 用户运行 shell（MEDIUM）。

④ 镜像与配置审计：check_image_digest()通过container.attrs读取Config.Image、HostConfig.Privileged、HostConfig.ReadonlyRootfs，据此补充两条关键发现：

• read_only_rootfs未启用 →mutable_rootfs（MEDIUM）；
• privileged为真 →privileged_container（CRITICAL，privileged 容器通常意味着逃逸路径）。

⑤ 风险定级：audit_container()汇总上述结果生成风险等级：

risk = "CRITICAL" if any(f["severity"] == "CRITICAL" for f in findings) else \ "HIGH" if total_changes > 20 or any(f["severity"] == "HIGH" for f in findings) else \ "MEDIUM" if total_changes > 5 else "LOW"

即：任一 CRITICAL → CRITICAL；变更文件超 20 个或含 HIGH → HIGH；变更超 5 个 → MEDIUM；否则 LOW。该定级与 api-reference.md 的严重度分类表一致：

运行方式：

python agent.py --container my-app-container # 审计单个容器 python agent.py --container abc123 --all # 审计所有运行中容器

依赖dockerPython SDK（pip install docker），输出为 JSON 报告（含容器 ID、时间戳、文件系统变更、运行进程、镜像信息、发现项与风险等级）。

6.2process.py：基于 kubectl 的集群级漂移检查

process.py 面向 Kubernetes 集群，通过 kubectl 拉取集群状态并执行四项检查：

• check_image_tag_drift()（镜像标签漂移）：遍历所有容器，凡镜像引用不含@sha256:即标记mutable_tag（MEDIUM）——对应摘要验证方法；
• check_readonly_filesystem()（只读文件系统）：检查 Pod 的securityContext.readOnlyRootFilesystem是否启用，未启用则标记writable_filesystem（MEDIUM）；
• check_restart_anomalies()（重启异常）：restartCount达到阈值（默认 3）的容器标记high_restarts（LOW）——漂移导致的崩溃循环是重要旁证；
• check_pod_security_standards()（PSS 执行检查）：检查命名空间是否设置了pod-security.kubernetes.io/enforce: restricted或baseline，未强制执行则标记no_pss_enforcement（MEDIUM）。

python process.py --namespace production # 指定命名空间 python process.py --all-namespaces # 全集群扫描 python process.py --namespace production --format json --restart-threshold 5

参数说明：--namespace指定扫描命名空间（默认全部）；--format可选text或json（默认 text）；--restart-threshold设置重启阈值（默认 3）。generate_report()按 CRITICAL/HIGH/MEDIUM/LOW 四级汇总输出文本或 JSON 报告，并给出容器数统计与逐条发现详情（含命名空间、Pod、容器名）。

6.3 两套脚本的互补定位

• agent.py回答"某个容器当前是否已漂移"——深度审计单容器，适合事件响应取证；
• process.py回答"集群里哪些工作负载存在漂移风险"——广度扫描集群配置，适合日常合规巡检。

二者结合 Falco 的实时事件流，可构成"实时告警（Falco）→ 单点取证（agent.py）→ 集群普查（process.py）"的纵深体系。

七、Microsoft Defender for Containers 集成

在 Azure Kubernetes 环境（AKS）中，Microsoft Defender for Containers 提供开箱即用的二进制漂移检测。其告警模型以K8S.NODE_ImageBinaryDrift为例，SKILL.md 给出的告警结构如下：

{ "alertType": "K8S.NODE_ImageBinaryDrift", "severity": "Medium", "description": "Binary executed that was not part of the original container image", "remediationSteps": [ "Investigate the binary origin and purpose", "Check if the container was compromised", "Rebuild the container from a clean image", "Enable readOnlyRootFilesystem" ] }

修复步骤与本文第四节的加固措施完全同构：调查二进制来源 → 判定是否失陷 → 从干净镜像重建 → 启用只读根文件系统。接入 SIEM 时建议将K8S.NODE_ImageBinaryDrift与可疑出站连接、Secret 访问异常等信号关联，以提升判读置信度。

八、漂移响应剧本（DIE 模型）

SKILL.md 将响应过程收敛为 DIE 模型——Detect（检测）→ Isolate（隔离）→ Evict（驱逐），配合完整的事件响应流程：

1. Detect 检测：告警触发（Falco、Defender、Sysdig）；
2. Validate 验证：确认漂移并非来自已批准进程（init 容器、配置热加载等）——这是控制误报的关键一步；
3. Isolate 隔离：对受影响 Pod 应用 deny-all NetworkPolicy；
4. Investigate 调查：捕获容器文件系统 diff 与进程列表；
5. Evict 驱逐：删除漂移 Pod（ReplicaSet 会从干净镜像自动重建）；
6. Remediate 修复：根治问题（修补漏洞、更新镜像、收紧 RBAC）。

workflows.md 进一步将其细化为三个实施阶段：

同时可借助技能附带的 评估模板 开展漂移检测覆盖度自查，勾选项包括：二进制执行监控、文件系统变更监控、包管理器使用检测、镜像摘要验证、只读根文件系统强制、Pod Security Standards enforce 模式，并按严重度统计发现项与整改状态。

九、标准与合规映射

standards.md 将容器漂移检测锚定到多个行业标准：

NIST SP 800-190（应用容器安全指南）

• 第 3.3 节：运行时被修改的容器表明可能失陷；
• 第 4.2 节：监控容器的未授权变更；
• 建议将容器视为不可变基础设施。

CIS Kubernetes Benchmark v1.9

• 控制项 5.2.8：最小化容器的 readOnlyRootFilesystem；
• 控制项 5.7.3：为 Pod 应用 securityContext；
• 控制项 5.7.4：默认命名空间限制。

MITRE ATT&CK for Containers

• T1610 Deploy Container：未授权容器部署；
• T1611 Escape to Host：容器边界突破；
• T1059.004 Unix Shell：容器内 shell 执行；
• T1105 Ingress Tool Transfer：向容器下载工具。

合规要求与检测能力对照：

十、最佳实践清单

1. 默认不可变：所有生产工作负载启用readOnlyRootFilesystem，可写目录显式声明为emptyDir并设置sizeLimit；
2. 镜像摘要固定：CI/CD 出口统一改写为image@sha256:...引用，禁止latest等可变标签进入生产；
3. 分层检测：Falco 事件流负责实时告警（二进制/Shell/包管理器/文件写入），process.py做集群配置普查，agent.py做单容器深度取证；
4. 先白名单再告警：Phase 1 阶段充分采集合法运行时变更基线，为日志、临时文件、缓存目录建立 allowlist，否则告警噪音会让漂移检测形同虚设；
5. 验证优先：告警后先确认是否来自 init 容器、配置重载等已批准进程，再进入隔离与驱逐；
6. 响应自动化：对确认的漂移事件实施 NetworkPolicy deny-all + Pod 驱逐的自动化响应，缩短 DIE 闭环时间；
7. 合规联动：将漂移检测能力映射到 PCI DSS 11.5、SOC 2 CC6.8、ISO 27001 A.12.1 与 NIST CSF DE.CM 等控制项，作为审计证据沉淀。

参考资料

• 技能主体：SKILL.md
• 源码实现：agent.py、process.py
• API 参考：api-reference.md
• 标准与合规：standards.md
• 实施工作流：workflows.md
• 评估模板：template.md
• 框架对齐：NIST CSF 对齐表、MITRE ATT&CK 覆盖汇总

本文所有命令、规则与脚本均以当前仓库skills/detecting-container-drift-at-runtime目录下的实际内容为准。Falco 规则与 Kubernetes 清单在应用前应根据自身集群版本（Kubernetes v1.24+）与工作负载特征进行适配与调优。

【免费下载链接】Anthropic-Cybersecurity-Skills817 structured cybersecurity skills for AI agents · Mapped to 6 frameworks: MITRE ATT&CK, NIST CSF 2.0, MITRE ATLAS, D3FEND, NIST AI RMF & MITRE F3 (Fight Fraud) · agentskills.io standard · Works with Claude Code, GitHub Copilot, Codex CLI, Cursor, Gemini CLI & 20+ platforms · 29 security domains · Apache 2.0项目地址: https://gitcode.com/GitHub_Trending/an/Anthropic-Cybersecurity-Skills