某天早上，运维小李刚泡好咖啡，就收到告警：生产环境的一个容器 CPU 占用突然飙升到 90% 以上。登录查看后发现，一个本该只运行 Web 服务的容器，竟然在悄悄挖矿。问题根源很快查清——攻击者通过一个未打补丁的 Nginx 镜像进入系统，植入了恶意进程。
这并不是孤例。随着 K8s 和 Docker 在企业中普及，容器成了攻击的新入口。相比传统服务器，容器生命周期短、动态性强，传统的防火墙和主机防护工具往往跟不上节奏。于是，入侵检测系统（IDS）在容器环境中的部署，变得尤为关键。
为什么容器需要专门的入侵检测？
普通 IDS 多基于主机或网络层，但容器共享内核、频繁启停，行为模式更复杂。比如一个容器启动后立刻尝试访问敏感路径 /proc/sys/kernel/core_pattern，这在物理机上少见，但在容器逃逸攻击中却是典型动作。常规规则很难识别这类异常。
更麻烦的是，很多团队还在用“镜像打好就不管”的老思路。实际上，即便镜像本身干净，运行时也可能被注入恶意代码。因此，必须在运行阶段持续监控行为，而不是只依赖静态扫描。
选型与部署：以 Falco 为例
Falco 是 CNCF 毕业项目，专为容器环境设计，能实时捕获系统调用级别的异常行为。它通过内核模块或 eBPF 抓取事件，再用规则匹配可疑操作。
在我们的测试环境中，使用 Helm 快速部署：
helm repo add falcosecurity https://falcosecurity.github.io/charts
helm install falco falcosecurity/falco --namespace falco --create-namespace默认配置下，Falco 已经内置了几十条规则，比如检测 shell 进入容器、文件篡改、提权操作等。我们曾遇到开发误操作触发告警，虽然虚惊一场，但也说明规则足够灵敏。
自定义规则：让检测更贴合业务
默认规则覆盖常见场景，但每个业务都有独特性。比如我们有个服务必须写入 /tmp 目录，而这条行为恰好触发了“非预期写入”告警。解决办法是添加白名单规则：
- rule: Ignore tmp writes in my-service
desc: Allow writes to /tmp for specific container
condition: <container.name> = "my-service" and <evt.type> = open and <fd.name> startswith "/tmp"
output: Ignored write to /tmp in my-service
priority: INFO
tags: [filesystem]规则语法清晰，支持字段过滤和逻辑组合，调整起来并不难。
告警不等于盲动，闭环处理才是关键
部署后第一天，系统报了 200 多条告警。团队一度想关掉，后来发现大部分是开发测试环境的误报。于是我们做了三件事：按命名空间区分环境、设置不同告警级别、把生产环境告警接入钉钉机器人。
现在，一旦生产容器出现 execve 系统调用且命令包含 wget/curl，告警立刻推送。响应流程也明确：暂停容器、取证日志、回滚镜像、更新规则。
有次告警提示某个 Pod 尝试连接已知 C2 服务器 IP，安全团队 10 分钟内完成隔离，避免了横向扩散。这种快速反应，正是入侵检测的价值所在。
容器不是法外之地。部署入侵检测不是为了应付合规，而是让看不见的风险变得可见。就像装了摄像头的办公室，不一定天天抓贼，但出事时能迅速定位。对技术团队来说，多一层监控，少一分焦虑。