1、容器安全概述：为什么容器安全重要、Docker安全威胁模型、安全基线原则
为什么容器安全这么重要？
说实话，我刚接触Docker那会儿，也觉得容器就是个轻量级虚拟机。跑起来快、部署方便，安全方面应该差不多吧？
后来在一次生产事故中，我才彻底明白——容器和虚拟机，安全模型完全是两码事。
虚拟机有独立的内核，有硬件虚拟化隔离。容器呢？共享宿主机内核。你想想看，一旦容器里的进程突破了命名空间的限制，宿主机就裸奔了。
我见过不少团队，把容器当虚拟机用，跑sshd、开22端口、密码设成123456。嗯，这种操作，我看着都替他们捏把汗。
容器安全的重要性，说白了就三点：
- 攻击面更大——镜像层数多、依赖链长，任何一个基础镜像出问题，上层全遭殃
- 隔离性弱——共享内核，不像VM那样有硬件级隔离
- 运维复杂度高——容器数量动辄成百上千，手动管理安全策略根本不现实
核心观点：容器安全不是可选项，而是生产环境的必选项。你不可能等到被入侵了才想起来加固。
Docker安全威胁模型
做安全，首先得知道敌人是谁。我习惯把Docker的安全威胁分成四个层面：
1. 镜像层威胁
镜像里可能藏着什么？恶意代码、已知漏洞、硬编码密钥、后门程序。
我记得有一次，团队从Docker Hub拉了个看起来很靠谱的Node.js镜像，结果里面藏了个挖矿脚本。跑了两天，CPU飙到100%，才发现不对劲。
- 基础镜像来源不可信
- 镜像层数过多，漏洞难以排查
- 构建过程中引入恶意依赖
2. 容器运行时威胁
容器跑起来之后，威胁就更多了：
- 权限逃逸——容器以root运行，或者挂载了宿主机敏感目录
- 资源耗尽——没有限制CPU/内存，一个容器把宿主机搞崩
- 网络攻击——容器间互相访问，没有网络隔离
注意：千万不要在生产容器里开--privileged模式。我曾经见过有人为了方便调试，直接给了容器所有权限，结果被攻破后，攻击者直接拿到了宿主机root权限。
3. 宿主机层威胁
宿主机本身的安全也很关键。Docker daemon的API如果暴露在外网，那基本等于把家门钥匙送给小偷。
- Docker daemon未授权访问
- 宿主机内核漏洞被利用
- 容器日志泄露敏感信息
4. 编排层威胁
用Kubernetes的话，威胁模型更复杂。比如：
- RBAC配置不当，普通Pod能操作集群资源
- Secrets管理不善，密钥明文存储
- 网络策略缺失，Pod间可以随意通信
安全基线原则
搞清楚了威胁，接下来就是怎么防。我个人总结了一套安全基线原则，你可以直接拿来用：
| 原则 | 说明 | 我的建议 |
|---|---|---|
| 最小权限 | 容器只给必要的权限 | 别用root，用--user指定普通用户 |
| 镜像可信 | 只从可信源拉取镜像 | 用私有仓库，签名验证 |
| 只读文件系统 | 容器运行时文件系统设为只读 | 用--read-only，需要写的地方挂载tmpfs |
| 资源限制 | 限制CPU、内存、磁盘 | 用--memory和--cpus，别手软 |
| 网络隔离 | 容器间网络默认隔离 | 用--network none或自定义网络 |
| 日志审计 | 记录容器行为 | 用docker logs配合外部日志系统 |
小技巧：我每次写Dockerfile，都会在最后加一行USER nobody。别小看这一行，它能挡住90%的权限逃逸攻击。
避坑指南
最后分享几个我踩过的坑：
- 别用latest标签——你永远不知道latest指向的是哪个版本。我建议用具体的版本号，比如node:18-alpine
- 别在镜像里存密钥——用环境变量或者挂载Secrets文件。我曾经在镜像里硬编码了数据库密码，后来镜像被推到了公共仓库...你懂的
- 别忽略.dockerignore——这个文件能帮你避免把敏感文件打包进镜像。比如.git目录、.env文件
- 别用--add-host——这个参数会修改容器的/etc/hosts，容易被利用做DNS劫持
好了，这一章的内容就到这里。记住一句话：容器安全不是一锤子买卖，而是一个持续的过程。下一章我们会深入讲镜像安全扫描和漏洞管理，到时候见。