1、Docker安全概述：容器安全的重要性、Docker安全模型、常见安全威胁与攻击面

为什么容器安全如此重要？

说实话，我刚接触Docker那会儿，也觉得容器就是个轻量级虚拟机。直到有一次，我在生产环境里发现了一个被挖矿程序感染的容器——嗯，那感觉就像家里进了贼，你还给他留了门。

容器安全为什么重要？说白了，有三大原因：

• 共享内核的风险：容器和宿主机共用同一个内核。这意味着一旦容器内的进程突破了隔离，整个宿主机就暴露了。我见过一个案例，攻击者通过容器内的漏洞直接拿到了宿主机的root权限。
• 镜像供应链问题：你从Docker Hub拉下来的镜像，可能本身就藏着后门。我记得有一次审计，发现团队用的Node.js基础镜像里被人植入了挖矿脚本。
• 配置不当的后果：默认配置往往是最不安全的。比如容器以root运行、挂载了宿主机敏感目录——这些坑，我几乎每个项目都见过。

Docker安全模型：三层防御

Docker的安全模型，我习惯把它理解成「三层防御」：

第一层：内核级隔离

Docker利用Linux内核的命名空间（Namespaces）和控制组（Cgroups）来实现隔离。说白了，就是给每个容器一个「假世界」——它有自己的进程树、网络栈、文件系统，但这一切都是虚拟的。

但这里有个坑：命名空间隔离不是万能的。比如/proc文件系统，如果容器以特权模式运行，就能看到宿主机的进程信息。我曾经在项目中遇到过，开发人员为了方便调试，给容器加了--privileged参数，结果安全扫描直接亮红灯。

第二层：Docker守护进程安全

Docker守护进程（dockerd）本身是root权限运行的。这意味着，谁能控制dockerd，谁就能控制宿主机。我建议：

• 永远不要将Docker socket暴露给不信任的用户
• 使用TLS证书加密守护进程的通信
• 限制谁可以执行docker run命令

第三层：镜像与容器安全

这一层是我们最常打交道的。包括：

• 镜像签名验证（Content Trust）
• 镜像漏洞扫描
• 运行时安全策略（如Seccomp、AppArmor）

我个人习惯，每次构建镜像前都会先跑一遍docker scan。别嫌麻烦，这能帮你省下不少事后擦屁股的时间。

常见安全威胁与攻击面

这些年做安全审计，我总结了几类最常见的威胁：

威胁类型	具体表现	我见过的案例
镜像投毒	恶意代码藏在基础镜像或依赖层中	某团队用的Node镜像里藏了挖矿程序，运行三天才被发现
容器逃逸	利用内核漏洞或配置缺陷突破容器	通过--privileged模式挂载宿主机目录，直接写入了SSH密钥
资源滥用	容器占用过多CPU/内存，影响其他服务	一个没限制内存的容器，把整个节点的OOM Killer触发了
配置泄露	环境变量、配置文件中的敏感信息	有人在Dockerfile里硬编码了数据库密码，镜像还推到了公开仓库

攻击面分析：从攻击者的视角看

你想想看，如果你是攻击者，你会从哪里下手？

• 攻击面1：镜像仓库——拉取恶意镜像，或者篡改已有镜像
• 攻击面2：Docker API——如果API未加密且暴露在外，等于敞开了大门
• 攻击面3：容器运行时——利用漏洞逃逸，或者横向移动
• 攻击面4：编排层——Kubernetes配置不当，比如RBAC权限过大

避坑指南：我踩过的那些坑

我曾经在给一家金融科技公司做审计时，发现他们的生产环境里，所有容器都以root运行。问原因，开发说「方便调试」。嗯，方便是方便了，但安全呢？

还有一次，一个团队把docker.sock挂载到了Web容器里。我问他们为什么这么做，答曰「方便在容器里执行docker命令」。结果呢？攻击者通过一个SQL注入漏洞，直接拿到了宿主机的控制权。

所以，记住这几条铁律：

• 不要以root运行容器——用USER指令指定非root用户
• 不要挂载docker.sock——除非你真的知道自己在做什么
• 不要使用--privileged模式——用--cap-drop=ALL加--cap-add按需添加
• 不要忽略镜像扫描——每次构建都跑一遍

好了，这一章的内容就到这里。下一章我们会深入聊聊Docker镜像的安全构建，包括如何选择基础镜像、如何减少攻击面。到时候我会分享一些我自己的Dockerfile模板，保证实用。