容器运行时漂移检测实战指南基于 Falco 与 Kubernetes 实现不可变基础设施的运行时安全监控【免费下载链接】Anthropic-Cybersecurity-Skills817 structured cybersecurity skills for AI agents · Mapped to 6 frameworks: MITRE ATTCK, 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 加固手段、镜像摘要验证以及 DIEDetect/Isolate/Evict检测—隔离—驱逐响应模型并深入剖析仓库自带的两套 Python 检测脚本帮助安全工程师、DevSecOps 与 SOC 分析师建立从检测到响应的完整闭环能力。一、技能文档总览与适用场景本技能skills/detecting-container-drift-at-runtime/SKILL.md面向容器安全 / 运行时安全子领域版本 1.0作者 mahipal采用 Apache-2.0 许可。其 frontmatter 将本技能映射到两个安全框架NIST CSF 2.0PR.PS-01平台安全、PR.IR-01基础设施韧性、ID.AM-08软件平台与应用的资产清单、DE.CM-01网络与活动的持续监控。在仓库的 NIST CSF 对齐表 中container-security 子域的定位是 Protect保护主导、兼顾 Identify 与 Detect主类别为 PR.PS平台安全与 GV.SC供应链风险。MITRE ATTCKT1610部署容器、T1611逃逸到宿主机、T1609容器管理套件中继、T1525不可信镜像启动容器与 标准参考 中列出的T1059.004Unix Shell 执行、T1105进入容器下载工具共同构成对抗矩阵视角。适用时机调查安全事件时需要检测容器运行时漂移为容器运行时检测构建告警规则或威胁狩猎查询SOC 分析师需要本领域结构化的分析流程验证针对相关攻击技术的安全监控覆盖度。前置条件Kubernetes 集群 v1.24 并配备运行时安全工具Falco 或 Sysdig 用于运行时漂移检测具备可获取镜像 manifest 的容器镜像仓库熟悉 Linux 文件系统层与 OverlayFS 工作原理。二、核心概念容器漂移的类型与检测方法2.1 五类容器漂移二进制漂移Binary drift执行原始镜像中不存在的二进制文件下载的恶意软件、编译工具等。这是最直接、最危险的漂移信号——攻击者在拿到 shell 后通常会下载渗透工具或恶意载荷。文件漂移File drift容器文件系统中文件的创建、修改或删除。配置漂移Configuration drift环境变量、挂载的 Secret 或运行时参数的变更。包漂移Package drift运行时通过 apt、yum、pip 或 npm 安装新软件包。网络漂移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 FilesystemreadOnlyRootFilesystem: true是阻止漂移的最强手段之一。需要可写空间的应用通过emptyDir显式挂载从而把可写区域收敛到明确声明的目录apiVersion: apps/v1 kind: Deployment metadata: name: immutable-app spec: template: spec: containers: - name: app image: app:v1.0sha256: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.0sha256:abc123...摘要格式可复制的部署allowPrivilegeEscalation: false禁止提权runAsNonRoot: true强制非 root 运行emptyDir设置sizeLimit防止临时目录被写爆导致 DoS若应用必须写/tmp、/var/cache等路径一律显式挂载为 emptyDir保持根文件系统只读。4.2 Pod 安全标准Pod Security Standards在命名空间级别强制 Pod Security StandardsPSS的restricted档位从准入层面拒绝违反不可变原则的 PodapiVersion: 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直接拒绝不符合的 Podaudit记录审计事件但不拒绝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 NAMESPACEproduction 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 用户运行 shellMEDIUM。④ 镜像与配置审计check_image_digest()通过container.attrs读取Config.Image、HostConfig.Privileged、HostConfig.ReadonlyRootfs据此补充两条关键发现read_only_rootfs未启用 →mutable_rootfsMEDIUMprivileged为真 →privileged_containerCRITICALprivileged 容器通常意味着逃逸路径。⑤ 风险定级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 的严重度分类表一致指标严重度Privileged 容器CRITICAL敏感文件被修改如 /etc/shadowCRITICAL二进制被添加到系统路径HIGH执行包管理器HIGHRoot shell 活跃MEDIUM根文件系统可写MEDIUM运行方式python agent.py --container my-app-container # 审计单个容器 python agent.py --container abc123 --all # 审计所有运行中容器依赖dockerPython SDKpip install docker输出为 JSON 报告含容器 ID、时间戳、文件系统变更、运行进程、镜像信息、发现项与风险等级。6.2process.py基于 kubectl 的集群级漂移检查process.py 面向 Kubernetes 集群通过 kubectl 拉取集群状态并执行四项检查check_image_tag_drift()镜像标签漂移遍历所有容器凡镜像引用不含sha256:即标记mutable_tagMEDIUM——对应摘要验证方法check_readonly_filesystem()只读文件系统检查 Pod 的securityContext.readOnlyRootFilesystem是否启用未启用则标记writable_filesystemMEDIUMcheck_restart_anomalies()重启异常restartCount达到阈值默认 3的容器标记high_restartsLOW——漂移导致的崩溃循环是重要旁证check_pod_security_standards()PSS 执行检查检查命名空间是否设置了pod-security.kubernetes.io/enforce: restricted或baseline未强制执行则标记no_pss_enforcementMEDIUM。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驱逐配合完整的事件响应流程Detect 检测告警触发Falco、Defender、SysdigValidate 验证确认漂移并非来自已批准进程init 容器、配置热加载等——这是控制误报的关键一步Isolate 隔离对受影响 Pod 应用 deny-all NetworkPolicyInvestigate 调查捕获容器文件系统 diff 与进程列表Evict 驱逐删除漂移 PodReplicaSet 会从干净镜像自动重建Remediate 修复根治问题修补漏洞、更新镜像、收紧 RBAC。workflows.md 进一步将其细化为三个实施阶段阶段周期核心动作Phase 1 可见性第 1-2 周Falco 以 alert-only 模式部署采集各工作负载正常行为基线识别合法运行时变更日志、临时文件、缓存为预期变更建立白名单Phase 2 检测第 3-4 周启用调优阈值后的漂移告警接入 SIEM 关联与看板编写漂移调查 runbook开展容器漂移场景桌面推演Phase 3 预防第 5-8 周全部生产负载启用只读根文件系统Pod Security Standards 切换 enforce 模式清单中实施镜像摘要固定对确认的漂移事件启用自动化驱逐同时可借助技能附带的 评估模板 开展漂移检测覆盖度自查勾选项包括二进制执行监控、文件系统变更监控、包管理器使用检测、镜像摘要验证、只读根文件系统强制、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 ATTCK for ContainersT1610 Deploy Container未授权容器部署T1611 Escape to Host容器边界突破T1059.004 Unix Shell容器内 shell 执行T1105 Ingress Tool Transfer向容器下载工具。合规要求与检测能力对照合规要求框架漂移检测能力变更检测PCI DSS 11.5容器内文件完整性监控未授权软件SOC 2 CC6.8二进制执行漂移告警配置管理ISO 27001 A.12.1镜像摘要验证事件检测NIST CSF DE.CM-7运行时行为异常检测十、最佳实践清单默认不可变所有生产工作负载启用readOnlyRootFilesystem可写目录显式声明为emptyDir并设置sizeLimit镜像摘要固定CI/CD 出口统一改写为imagesha256:...引用禁止latest等可变标签进入生产分层检测Falco 事件流负责实时告警二进制/Shell/包管理器/文件写入process.py做集群配置普查agent.py做单容器深度取证先白名单再告警Phase 1 阶段充分采集合法运行时变更基线为日志、临时文件、缓存目录建立 allowlist否则告警噪音会让漂移检测形同虚设验证优先告警后先确认是否来自 init 容器、配置重载等已批准进程再进入隔离与驱逐响应自动化对确认的漂移事件实施 NetworkPolicy deny-all Pod 驱逐的自动化响应缩短 DIE 闭环时间合规联动将漂移检测能力映射到 PCI DSS 11.5、SOC 2 CC6.8、ISO 27001 A.12.1 与 NIST CSF DE.CM 等控制项作为审计证据沉淀。参考资料技能主体SKILL.md源码实现agent.py、process.pyAPI 参考api-reference.md标准与合规standards.md实施工作流workflows.md评估模板template.md框架对齐NIST CSF 对齐表、MITRE ATTCK 覆盖汇总本文所有命令、规则与脚本均以当前仓库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 ATTCK, 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考