把 Docker 当成隔离层，而不是魔法结界：个人服务器容器安全指南
容器不是虚拟机；真正的安全来自权限、挂载、网络和供应链边界。
容器更像船舱之间的隔板，不是钢筋混凝土保险库。隔板能限制进水，但前提是你没有把所有舱门都拆掉。
Docker 让部署变得很轻：一份 Compose、一个镜像、几分钟就能得到服务。轻量也容易制造错觉，好像应用进了容器就天然安全。实际上容器共享宿主机内核，隔离强度取决于运行参数。特权模式、Docker socket、host 网络和过宽挂载，可以把本来清晰的边界重新打穿。
个人服务器资源有限，不需要复制大型企业的整套平台，但可以抓住几条收益最高的原则：减少权限、缩小可见范围、固定供应链、限制资源，并确保所有变更都能从 Compose 文件重建。
Docker daemon 是一把接近 root 的钥匙
Docker daemon 通常以 root 权限管理容器。能控制 /var/run/docker.sock 的进程，可以创建挂载宿主机根目录的新容器、读取其他容器环境变量，最终获得接近宿主机管理员的能力。因此不要为了让监控或面板更方便，就把 socket 原样挂进来源不明的容器。确实需要时，应使用受限代理、只读 API 或单独管理节点。
Rootless mode 可以让 daemon 和容器在普通用户命名空间中运行，减少 daemon 漏洞直接变成宿主机 root 的风险。它不是所有场景的无痛替换，低端口、存储和网络行为可能不同，但值得在新部署中评估，而不是等出事故才考虑。
从 Compose 里读出爆炸半径
审计容器时先看五项：privileged、cap_add、network_mode、volumes 和运行用户。默认删除不需要的 Linux capabilities，比先给特权再靠应用自律更可靠。能使用只读根文件系统的服务设置 read_only: true，把确实需要写入的路径单独挂载。
host 网络会让容器直接共享宿主机网络命名空间，适合少数需要监听多协议或 IPv6 的工具，但也会失去端口映射带来的可见边界。普通 Web 服务更适合独立 bridge 网络，只把反向代理需要的端口暴露在回环地址或内部网络。
秘密不要躺在镜像层里
把 Token 写进 Dockerfile 或构建参数，很可能让它留在镜像历史和缓存中。Compose secrets 会以文件形式挂载给服务，至少能避免秘密长期出现在普通环境变量和镜像层。对于小型部署，权限为 600 的独立 env 文件仍然常见，但要知道同机 root、Docker 管理员和容器 inspect 都可能看到它。
更关键的是不要把秘密输出到日志。很多泄露不是攻击者突破了加密，而是应用在调试时把完整请求头、连接串或环境变量打印了出来。日志采集和 AI 日志分析前都应先做字段级脱敏。
镜像标签不是版本承诺
latest 是一个会移动的名字。今天重建和下个月重建可能得到不同内容，回滚也会失去基准。稳定服务应固定明确版本，关键场景进一步固定 digest。更新时先读取发布说明、在副本验证，再让 Compose 指向新版本。固定版本不是拒绝更新，而是让更新成为可审计事件。
镜像来源同样重要。优先官方或维护者明确发布的仓库，检查更新时间、签名或 provenance、Dockerfile 和已知漏洞。GitHub 的 artifact attestations、SBOM 和不可变发布不能保证代码没有漏洞，却能帮助回答“这个产物从哪里构建、有没有被替换”。
资源限制也是安全控制
在 2C2G 服务器上，一个失控进程就能把整机拖进 Swap。为浏览器、索引器、AI 工具和扫描任务设置内存、CPU、PID 与共享内存边界；配置日志轮转，避免单个 JSON 日志吃满根分区。资源限制不只是性能优化，它能降低拒绝服务和异常任务扩散的影响。
健康检查也要谨慎。频繁执行重型命令会制造额外负载；只检查真正代表可用性的轻量端点，并区分“进程存在”和“业务可服务”。重启策略可以处理偶发退出，却不应掩盖持续崩溃。
可以直接照着做的检查清单
- 查找所有 Docker socket、特权模式、host 网络和根目录挂载。
- 删除不需要的 capabilities，并为可行服务启用非 root 与只读文件系统。
- 把持久数据、配置和秘密分开管理，不写入镜像层。
- 从 latest 迁移到明确版本，关键镜像记录 digest 与来源。
- 设置内存、CPU、PID 和日志轮转，防止单容器拖垮整机。
- 定期用 Compose 文件在空目录演练重建，证明配置足够完整。
延伸阅读
容器安全的目标不是证明隔离绝对可靠，而是让每个服务只拥有完成工作所需的那一小块宿主机。
