先认清：容器不是虚拟机#

虚拟机有自己的一套内核，宿主机和虚拟机之间隔着 hypervisor；容器不一样——所有容器共享宿主机的同一个内核，容器里的进程本质上就是宿主机上的进程，只是被 namespace 隔离了视野、被 cgroup 限制了资源。

更关键的是默认身份：容器里跑的进程默认是 root（uid 0）。由于容器与宿主机共用内核、默认也没有开启 user namespace 重映射，这个 root 虽然被关在隔离环境里，但它离宿主机 root 的距离，远比你想象的近：

• 一旦出现内核漏洞或容器运行时漏洞，容器内的 root 就是第一个摸到逃逸门的人；
• 挂载配置写错（比如把宿主机目录可读写地挂进容器），容器里的 root 就能直接改宿主机文件；
• 给了过大的 capability 或者干脆开了特权模式，隔离基本等于不存在。

把容器和虚拟机的差别摆在一起看，会更直观：

容器的两根支柱里，namespace 负责「看不见」——看不见其他容器的进程、网络、挂载点；cgroup 负责「用不多」——CPU、内存、进程数都有配额。但请注意，这两根支柱管的都是「正常情况下」的行为，它们不是为对抗「容器内已经拿到 root 的攻击者」设计的。攻击者手里有了容器内 root，他要做的事情就是在内核的系统调用接口上找缝、在你配错的挂载和权限里找门。宿主机内核暴露给每个容器的系统调用有数百个，这就是容器逃逸新闻隔一段时间就出现一次的根本原因。

所以容器安全的核心思路不是「相信隔离」，而是最小权限：能不给 root 就不给 root，能不给的能力就不给，能不写的目录就不让写，能不占的资源就限死。下面逐项来。这几项措施还有一个共同点：它们防的不只是外部攻击者，也防应用自己——一个有 bug 的程序以 root 身份在可写文件系统里跑出破坏，损失和被攻击没有区别。

一、非 root 运行：把默认 root 换掉#

这是收益最大、成本最低的一项加固。分两种情况：镜像本身支持用普通用户跑的，你只需要在 Compose 里指定；镜像默认必须 root 启动的，就要在 Dockerfile 里自己建用户。

1
services:
2
  app:
3
    image: myapp:latest
4
    user: "1000:1000"

1
id
2
# 输出示例：uid=1000(anex) gid=1000(anex) groups=1000(anex),...

1
FROM node:22-alpine
2

3
WORKDIR /app
4
COPY . .
5

6
# 建一个无登录权限的普通用户
7
RUN addgroup -S app && adduser -S app -G app \
8
    && chown -R app:app /app
9

10
USER app
11

12
CMD ["node", "server.js"]

1
RUN groupadd -r app && useradd -r -g app -s /usr/sbin/nologin app

1
docker exec myapp ps aux
2
# 或只看 1 号进程的身份
3
docker exec myapp id

1
# 数据卷是 bind 挂载的本地目录时
2
sudo chown -R 1000:1000 /opt/myapp/data
3

4
# 数据卷是命名卷时，先查它在宿主机上的实际路径
5
docker volume inspect myapp_data | grep Mountpoint
6
sudo chown -R 1000:1000 /var/lib/docker/volumes/myapp_data/_data

二、Capabilities：把 root 的超能力拆开卖#

Linux 早就把 root 的权限拆成了四十多个独立的 capability（能力），比如绑定低位端口、改系统时间、加载内核模块，各是一项。Docker 默认给每个容器发了其中 14 项，包括 CHOWN、DAC_OVERRIDE（绕过文件权限检查）、SETUID、SETGID、NET_RAW、NET_BIND_SERVICE 等——对绝大多数应用来说，这份默认清单还是给多了：一个只提供 HTTP 接口的服务，既不需要绕过文件权限，也不需要发原始网络包。这些多余的能力平时躺着不动，可一旦进程被攻破，它们就全是攻击者手里的工具：DAC_OVERRIDE 让他能读容器里本不该读的密钥文件，NET_RAW 让他能伪造网络包横向探测内网。正确做法是先全部收回，再按需逐个加：

1
services:
2
  app:
3
    image: myapp:latest
4
    cap_drop:
5
      - ALL
6
    cap_add:
7
      - NET_BIND_SERVICE

常用 capability 对照：

一个判断原则：cap_add 之后容器起不来、日志报权限错误，再对照着补；一上来就把清单拉满，等于没做。

1
services:
2
  app:
3
    image: myapp:latest
4
    privileged: true

三、只读文件系统：容器只能写该写的地方#

容器被攻破后，攻击者通常第一件事是往磁盘里塞东西：改二进制、放后门、写挖矿程序。如果把容器根文件系统设成只读，这条路直接堵死：

1
services:
2
  app:
3
    image: myapp:latest
4
    read_only: true
5
    tmpfs:
6
      - /tmp
7
      - /var/run
8
    volumes:
9
      - app_data:/app/data

要点：

• read_only: true 让镜像层只读，程序改不了自己的代码和配置；
• 应用总要写临时文件，用 tmpfs 给 /tmp 这类目录开一块内存盘，容器删了就没了，正好符合临时文件的定位；
• 真正需要持久化的数据，走命名卷或 bind 挂载单独放行，如上面的 /app/data；
• 有的应用还要写缓存目录、日志目录，启动报错时看日志里缺哪个目录，逐个用 tmpfs 或卷补上，不要因为麻烦就把 read_only 撤掉。

只读文件系统还有个附带好处：倒逼你把「数据」和「程序」分清楚，备份、迁移时该带走哪些目录一目了然。

四、no-new-privileges：堵住提权后门#

Linux 允许进程通过执行 setuid 程序获得更高权限（比如普通用户执行 sudo）。容器里如果留着这条路，前面把进程降成普通用户的努力就可能被一个 setuid 二进制绕过去。加上这个开关后，进程无论如何都不能通过 exec 获得比父进程更高的权限：

1
services:
2
  app:
3
    image: myapp:latest
4
    security_opt:
5
      - no-new-privileges:true

成本几乎为零，没有特殊需求就默认加上。举个具体的画面：不少镜像里带着 passwd、su 这类 setuid 程序，普通用户执行它们时能临时获得 root 身份去改密码文件——这正是 setuid 机制的用途，也是它的风险：历史上多次出现过靠 setuid 程序的漏洞把普通用户提成 root 的案例。no-new-privileges 之后，这类程序在你的容器里会被「去势」：执行时不再赋予额外权限，漏洞的利用链当场断掉，而你的应用几乎不可能真的需要在运行时改密码，功能上毫无损失。注意：如果容器入口脚本本身依赖「先 root 准备、再用 gosu/su-exec 降权」这类流程，no-new-privileges 一般不影响它们（降权是往下走，不是提权）；但如果应用在运行时需要调用 setuid 程序提权（很少见），就要斟酌。

五、资源限制：别让一个容器拖垮整台机器#

隔离不只是防攻击，还要防失控：一个容器内存泄漏吃光 RAM、或者 fork 炸弹刷满进程表，整台宿主机上所有服务一起陪葬。资源限额就是给每个容器划好自己的饭碗。

1
services:
2
  app:
3
    image: myapp:latest
4
    deploy:
5
      resources:
6
        limits:
7
          cpus: "1.0"
8
          memory: 512M
9
        reservations:
10
          memory: 128M

1
services:
2
  app:
3
    image: myapp:latest
4
    mem_limit: 512m
5
    cpus: 1.0

1
services:
2
  app:
3
    image: myapp:latest
4
    pids_limit: 200

1
services:
2
  app:
3
    image: myapp:latest
4
    ulimits:
5
      nofile:
6
        soft: 65535
7
        hard: 65535
8
      nproc: 4096

1
docker stats

1
docker inspect app --format '{{.HostConfig.Memory}} {{.HostConfig.NanoCpus}}'

六、专项风险一：docker.sock 挂载#

/var/run/docker.sock 是 Docker 守护进程的控制入口。谁能访问这个 socket，谁就能创建任意容器、把宿主机根目录挂进特权容器读出来——挂 docker.sock 进容器，等于把宿主机 root 交给那个容器。容器一旦被攻破，攻击者一条命令就能在宿主机上开一个带完整权限的新容器，前面所有加固全部归零。

但偏偏有些工具离不开它：上一篇 《如何在Linux自动更新Docker容器》 里的 Watchtower 要靠它重建其他容器，日志工具 Dozzle 要靠它读容器列表。这类工具要用，但要按「不得不挂」来对待：

• 只给真正需要的工具挂，业务容器永远不挂；
• 别被「只读挂载」骗了：写成 /var/run/docker.sock:/var/run/docker.sock:ro 并不能让它变只读——ro 限制的是文件系统层面的改名删除，而通过 socket 发给守护进程的 API 请求（建容器、删容器）照样畅通无阻。指望靠 :ro 防写，是自欺欺人；
• 加一层 socket 代理：用 tecnativa/docker-socket-proxy 这类工具夹在中间，只放行白名单内的 API（比如只允许 GET 查列表、禁止 POST 建容器），业务工具连代理、不直连真 socket；
• 只绑本机、加认证：如果用的是 TCP 方式的 DOCKER_HOST，必须绑 127.0.0.1 并启用 TLS 双向认证，裸奔的 2375 端口在公网上等于公开送出一台宿主机。

最后提一个根子上的备选方案：Rootless Docker。它让 Docker 守护进程本身就以普通用户身份运行，并借助 user namespace 把容器里的 root 映射成宿主机上的一个无权用户——这样即使容器被攻破、即使攻击者摸到了 docker.sock，他在宿主机上也只是一个普通用户的权限，杀伤力小一个数量级。代价是部分功能受限（比如绑低位端口、某些网络模式需要额外配置）。新装机器、又特别在意这条线的，可以从一开始就按 rootless 模式部署；已有环境不必为此推倒重来，先把前面几节的常规加固做扎实，收益已经占了大头。

七、专项风险二：端口暴露面收敛#

docker ps 里 0.0.0.0:8080->80/tcp 这一行，意思是这个端口对所有网卡开放，包括公网网卡。很多数据库、面板就是这么被全网扫描扫到、然后被爆破的。收敛方法很简单：不需要公网直连的服务，只绑回环地址，再由反向代理统一对外：

1
services:
2
  app:
3
    image: myapp:latest
4
    ports:
5
      - "127.0.0.1:8080:8080"

这样端口只在本机可达，外面访问走 Nginx/Caddy 反向代理，加 HTTPS、加认证都在代理层统一做。养成定期巡检的习惯：

1
docker ps --format 'table {{.Names}}\t{{.Ports}}'

逐行看 PORTS 列，凡是 0.0.0.0 开头又不该对外的，当场改掉。再配合宿主机上 ss -tlnp 核对实际监听，两边对得上才算干净。

WARNING

一个常见误解：以为在云厂商防火墙或 ufw 里挡住就行。Docker 会自己写 iptables 规则转发端口，绕过 ufw 的默认策略，不少人就是这样「防火墙明明没放行、端口却全网可达」。最可靠的收敛点是绑定地址本身：写死 127.0.0.1，谁都绕不过去。

八、专项风险三：镜像供应链#

容器跑的代码，绝大部分不是你写的，是你从镜像仓库拉的。镜像来源不可信，前面所有加固都是在保护别人的后门。三条纪律：

1. 只用可信来源：官方镜像、知名组织、或者自己构建的。来路不明的镜像——论坛里随手发的、教程里没头没尾的 latest——不要跑，尤其不要给它任何挂载和特权。
2. 固定版本，别裸用 latest：nginx:latest 今天和下个月可能是两个东西，出问题都没法复现。写到明确版本号 nginx:1.27.3，更新时人工改版本号，过程可控、可回滚。
3. 重要服务固定 digest：版本标签也可能被覆盖推送，摘要（digest）是内容哈希，锁死了就绝无二义：

1
services:
2
  app:
3
    image: nginx:1.27.3@sha256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

digest 可以在 docker pull 后用 docker inspect --format '{{index .RepoDigests 0}}' nginx:1.27.3 查到。配合 自动更新那篇 的做法：定期更新镜像、修补已知漏洞，但更新动作要经过你的确认，而不是无声地换成某个「最新版」。另外定期用 docker scout 或 Trivy 扫一遍在用镜像的已知漏洞，做到心里有数。

还有一条选镜像的经验：基础镜像越小，攻击面越小。一个完整发行版镜像里塞着几百个你永远用不上的软件包，每一个都是潜在的漏洞载体。同样的应用，能选 Alpine 这类精简版就别选完整版；更进一步，Google 的 distroless 镜像连 shell 和包管理器都不带，攻击者就算进了容器，也没有趁手的工具可用。自己构建镜像时同理：多阶段构建把编译工具留在构建阶段，最终镜像只带运行必需的文件，这既是体积优化，更是实打实的安全优化。

九、加固版 Compose 模板（汇总）#

把上面各项拼到一起，就是一份可以直接抄走改名的模板：

1
services:
2
  app:
3
    image: myapp:1.4.2            # 固定版本，不用 latest
4
    container_name: app
5
    restart: unless-stopped
6
    user: "1000:1000"             # 非 root 运行
7
    read_only: true               # 根文件系统只读
8
    tmpfs:
9
      - /tmp
10
    volumes:
11
      - app_data:/app/data        # 只有数据目录可写
12
    ports:
13
      - "127.0.0.1:8080:8080"     # 只绑本机，对外走反向代理
14
    cap_drop:
15
      - ALL                       # 能力先全收
16
    cap_add:
17
      - NET_BIND_SERVICE          # 再按需加
18
    security_opt:
19
      - no-new-privileges:true    # 禁止提权
20
    pids_limit: 200               # 防 fork 炸弹
21
    deploy:
22
      resources:
23
        limits:
24
          cpus: "1.0"
25
          memory: 512M
26
    ulimits:
27
      nofile:
28
        soft: 65535
29
        hard: 65535
30
    logging:
31
      driver: json-file
32
      options:
33
        max-size: "20m"
34
        max-file: "3"
35

36
volumes:
37
  app_data:

不是每个应用都要全套照搬：起不来就看日志，缺目录补 tmpfs、缺权限补 capability，一项项对着报错放宽，但每放宽一项都要知道自己在放什么。

给存量服务上这份模板，建议一项一项来、每上一项重启验证一次，而不是十几行同时砸下去——真出了问题，git 记录里能清楚看到是哪一项引起的，回滚也只需要撤那一项。顺序上按三批推进：

十、排障：加了限制之后容器起不来#

一启动就退出、日志报 Permission denied。 大概率是 user 或 read_only 引起的：先对照日志里报的路径，目录问题用 chown 改属主或补 tmpfs/卷；不要第一反应就把限制撤了。

容器莫名其妙消失/重启，日志里没报错。 怀疑被 OOM Kill 了——内存超限时内核直接杀进程，应用自己来不及写日志。查容器的死因：

1
docker inspect app --format '{{.State.OOMKilled}} {{.State.ExitCode}}'

OOMKilled 为 true 就实锤了（退出码通常是 137）。宿主机层面也能在内核日志里找到记录：

1
dmesg | grep -i "out of memory"
2
# 或
3
journalctl -k | grep -i oom

确认是正常业务增长就适当调大 memory 上限；如果是内存泄漏，调上限只是续命，该修还得修。

CPU 限额设了但服务变卡。 docker stats 里看 %CPU 是否长期顶在限额附近（1.0 核的限额对应 100%）。顶格说明限额给小了或者应用有死循环，先分清再调。

cap 砍完后端口绑不上。 非 root 用户绑 1024 以下端口需要 NET_BIND_SERVICE，要么把这个 capability 加回来，要么让应用监听高位端口（如 8080）、由外层映射解决。

日志里刷 Operation not permitted。 这是 capability 被收走后的典型报错：进程想做一件它以前能做、现在没能力做的事。对照第二节的表逐项排查——改文件属主失败是缺 CHOWN，入口脚本降权失败是缺 SETUID/SETGID，ping 不通是缺 NET_RAW。一次只加一项验证，确认是哪一项再固定下来，别一口气把表全抄上。

退出码 137 是什么意思。 容器的退出码 137 等于 128+9，即进程是被 SIGKILL 强杀的。除了上面说的 OOM Kill，宿主机内存整体不足时内核也会挑容器下手，排查路径相同：先看 OOMKilled 标记，再翻内核日志确认凶手。与之相邻的 143（128+15）则是被 SIGTERM 正常终止，一般是 docker stop 的结果，不用慌。

小结#

• 认知先行：容器共享内核、默认 root，隔离强度远不如虚拟机，加固的目标是最小权限；
• 四件套默认全上：user 非 root、cap_drop: ALL 按需加、read_only + tmpfs、no-new-privileges；
• 资源三限：deploy.resources 限 CPU/内存、pids_limit 限进程数、ulimits 调句柄，写完用 docker stats 验证；
• 三个真实风险点：docker.sock 非必要不挂、端口只绑 127.0.0.1 再走反代、镜像固定版本或 digest 只用可信来源；
• privileged: true 永远不要出现在你的配置里。

最后给个推进路线，不用一次到位：今天先把所有服务的端口绑定检查一遍、把裸奔的 0.0.0.0 收回 127.0.0.1，这是十分钟的事；这周内给新部署的服务全部套上第九节的模板；存量服务按「先无副作用项、后权限项」的顺序逐台改造。安全加固最怕的不是技术难，而是总觉得「等有空再弄」——而攻击者和失控的进程，从不挑你有空的日子。

笼子扎紧的代价，无非是部署时多写几行配置、多排一两次权限报错；换来的，是某个容器真出事的那天，损失能停在笼子里面。这笔账，划算。