企业官网建设流程全解析

Docker 安全加固这个话题，每年都有人提，但绝大多数人还是停留在“跑起来就行、端口别乱开、密码别写死”的层面。2026 年再去谈生产级加固，如果还只盯着这几个点，基本是拿生产环境当实验田。这年头镜像供应链被投毒、运行时逃逸漏洞、凭据泄露导致的横向渗透，哪一件不是从容器这条线打进去的。这篇不是什么理论科普，是一份可以直接对着核对的 Checklist，每个加固项都带理由、带命令、带踩坑说明。

我下面这套方案参考了 2025 到 2026 年主流云厂商和容器安全团队的实际做法，覆盖宿主机、daemon、镜像、运行时、审计监控五个层面。不管你是 DevOps、SRE、后端开发还是安全工程师，只要你的业务跑在 Docker 上，这篇文章都能直接拿去用。

1. 先捋清安全思路：2026 年容器面临的主要威胁

1.1 容器不是“轻量虚拟机”，共享内核才是安全的核心矛盾

很多人有个根深蒂固的误解：容器内部和宿主机是隔离的，所以容器内出事跟宿主机没关系。这个认知在 2026 年依然很危险。Docker 容器的隔离依赖的是 Linux 内核的命名空间（namespace）、控制组（cgroups）、Capabilities 和各类 LSM 机制，它和宿主机共用同一个内核。用个生活化的类比：虚拟机是每户单独一套房子，墙是混凝土现浇的；容器是同一栋楼里的一间间房，每间房有独立门锁，但楼道、承重墙、总电闸全是共用的。一旦某个门锁被撬开（也就是容器逃逸漏洞被利用），攻击者直接就站在楼道里了，想进哪间进哪间。

2026 年这个矛盾不但没缓解，反而因为容器里跑的微服务越来越多、镜像下载来源越来越杂，攻击面变得更大了。所以加固的第一个原则就是：永远假设容器可能被攻破，然后去看它被攻破之后还能干多少坏事。这个思路贯穿全套 Checklist。

1.2 两个最常见的加固误区

我在实际接触过的团队里发现，安全加固做不好通常不是不重视，而是走进两个误区。

第一个误区是“只调运行时参数”。有人喜欢在 docker run 后面堆一堆参数，security-opt、cap-drop 全都上了，但用的镜像是从公开仓库随手拉来的、没有扫描过、没有锁 digest、里面还留着构建工具和密钥。这种等于把门锁换成了指纹锁，但钥匙就插在门外脚垫下面。

第二个误区是“只信基础镜像”。反过来，有人只盯着镜像层做文章，用 distroless、扫描零漏洞，但运行时完全不管，privileged 模式照开、宿主机目录随便挂、root 用户直接跑。这两种做法都是单点防御，攻破一层就全线崩溃。真正的加固必须分层做，没得商量。

1.3 2026 年 Docker 加固基线有哪些变化

老一套的加固文档，很多还是基于 Docker 19.03 到 20.10 时代的默认行为写的。2026 年再看这些文档，有两点必须更新认知。

第一，Rootless Docker 已经相当成熟，cgroups v2 全面铺开，用户命名空间不再是需要折腾半天的实验特性，生产环境里用非 root 用户跑 Docker daemon 已经是腾讯、阿里、字节这些大厂内部推荐的基线，而不是加分项。

第二，镜像签名和软件物料清单（SBOM）已经从“可选项”变成了“默认要求”。2024 年之后几次知名的供应链攻击，基本都发生在无签名、无来源验证的镜像上。2026 年如果你们公司的生产镜像还没有签名机制，那坦白说，安全评审这一关是过不去的。

2. 宿主层加固：Docker daemon 和内核的第一道防线

2.1 先把 daemon 自身的口子堵住

很多人忽略了一个最基本的事实：Docker daemon 拥有宿主机上的 root 权限，谁控制了 Docker API，谁就控制了宿主机。所以 daemon 的暴露面是第一优先级。

第一步，检查 Docker daemon 到底监听在哪里。如果你发现 /etc/docker/daemon.json 里配置了"hosts": ["tcp://0.0.0.0:2375"]，那基本等于把 root shell 交出去了。未加密的 2375 端口一旦暴露在公网，扫到就是秒沦陷，这已经是 2026 年还反复出现的事故类型。生产环境优先使用 Unix socket，如果需要远程管理，必须启用 TLS 客户端证书认证，并且限制来源 IP。

我在生产环境里给客户落地时，daemon.json 里长期维持这套配置：

{ "hosts": ["unix:///var/run/docker.sock"], "iptables": true, "icc": false, "userland-proxy": false, "live-restore": true, "no-new-privileges": true, "log-driver": "json-file", "log-opts": { "max-size": "50m", "max-file": "5" }, "storage-driver": "overlay2" }

逐个说下关键项。"icc": false是在默认 bridge 网络上禁止容器间直接通信，要通信必须显式指定 --link 或者放到同一个自定义网络里，这能挡住不少横向扩散。"userland-proxy": false是关掉用户态代理，减少一个攻击面，代价是 DNAT 规则的并发性能略有变化，但生产环境实测影响不大。"live-restore": true的意思是 daemon 升级或重启时容器不停，这个对生产很重要，但要注意它和某些网络插件有兼容性问题，需要提前验证。"no-new-privileges": true是全局禁止进程通过 setuid 等方式提权，是成本极低、收益极高的一项。

提示：改 daemon.json 后不要直接 restart，先执行dockerd --validate校验配置，或者用kill -SIGHUP $(pidof dockerd)热加载，减少不必要的容器中断。

第二步，限制谁有权限操作 Docker socket。/var/run/docker.sock 的权限建议保持 root:docker 并且 660，只有加入 docker 组的用户才能执行 docker 命令。docker 组里的用户实际上等价于宿主机 root，所以这个组的成员名单一定要严格审核，不能什么人都往里丢。如果开发环境确实需要让非 root 用户用 Docker，我更推荐直接上 Rootless Docker，而不是把用户加进 docker 组。

第三步，不要图省事把宿主机的 /var/run、/etc、/root 目录挂载进容器。尤其是 docker.sock，一旦挂进容器，容器内的进程可以直接操作 daemon，典型的一键提权路径。有人为了图省事用它来实现“容器内管理其他容器”，这种设计在 2026 年有成熟替代方案（比如 Docker API 的代理鉴权组件），生产环境坚决不碰。

2.2 开启用户命名空间：把容器里的 root 变成“假 root”

容器里默认的 root 用户，和宿主机上的 root 用户共享同一个 UID 0，只是被命名空间隔开了。如果发生逃逸，UID 0 就直接对应宿主机的 root，非常危险。开启用户命名空间（userns-remap）之后，容器内的 root 会被映射成宿主机上的一个普通非特权用户，逃逸出来也只是普通用户权限，伤害瞬间降了一个等级。

具体做法是在 daemon.json 里加一行：

{ "userns-remap": "default" }

这里用 default，Docker 会自动创建名为 dockremap 的用户和用户组，并配置对应的 subuid/subgid 映射。修改后需要重启 daemon 并清掉旧的容器和镜像（因为存储驱动的权限结构变了），所以建议在加固窗口期一次性做掉，而不是在业务高峰期改。

userns-remap 有个非常典型的坑：挂载卷权限会错乱。原来容器内 root 写的文件，开启 remap 后，dockremap 用户写出来的 UID 在宿主机上是一个很大的值（比如 165536）。如果你把宿主机的一个目录挂进容器，而目录属主是 uid 1000 的普通用户，容器内以 root 身份可能反而没权限写。处理方式有两个：一是调整挂载目录的属主，让它匹配映射后的 UID；二是用 podman 那种 per-container 映射方案（Docker 原生不支持）。所以我的建议是：新项目从一开始就启用 userns-remap，存量项目评估后再渐进切换。

还要注意，--privileged模式在 userns-remap 下不会被允许，这其实是好事，强制开发者放弃最危险的运行模式。

2.3 Rootless Docker：2026 年生产环境的新基线

如果说 userns-remap 是“把容器内 root 降权”，那 Rootless Docker 就是“把整个 Docker daemon 降权”。Rootless 模式下，daemon、containerd、runc 全部以普通用户身份运行，不再需要宿主机的 root 权限，安全收益是质的飞跃。

Rootless Docker 的原理是借助 RootlessKit 在用户命名空间里把普通用户“模拟”成 root，网络部分通过 slirp4netns 或 pasta 做用户态网络转发，存储则可以用 fuse-overlayfs 或者原生 overlayfs（取决于内核版本和配置）。代价是有轻微的性能损耗，以及某些端口映射行为跟传统模式不太一样，比如监听 80 端口需要额外的能力配置。

2026 年如果你们是新建的 Docker 环境，我强烈建议直接把 Rootless 作为默认运行模式。安装时只需要：

dockerd-rootless-setuptool.sh install export PATH=/usr/bin:$PATH systemctl --user start docker

跑起来后验证一下：

docker context use rootless docker run --rm hello-world

这里有个实际经验要分享：Rootless 模式下，容器如果要绑宿主机 1024 以下端口，需要额外设置net.ipv4.ip_unprivileged_port_start=0或者用 rootlesskit 的端口转发参数。另外，涉及 overlayfs 的存储驱动在某些发行版上有坑，Ubuntu 22.04+ 实测比较稳，CentOS 7 那类老系统就别折腾 Rootless 了，升级系统反而更实际。

注意：Rootless Docker 和 userns-remap 二选一即可，不需要同时开。Rootless 的隔离层级更高，但也更依赖新内核特性，团队需要有一定的 Docker 排障能力；如果团队经验一般，userns-remap 是更稳妥的过渡方案。

2.4 资源限制：防止一个容器拖垮整台机器

资源限制在安全里经常被忽略，但它是防“容器内进程失控导致宿主机不可用”的关键手段。2026 年容器常见的事故里，内存泄漏导致宿主机 OOM、容器内 fork 炸弹打满 PID 空间、磁盘写满把宿主撑爆，这几个都属于“不是被攻击，但效果等于被攻击”的经典问题。

docker run 阶段建议显式指定这几个参数：

docker run \ --cpus=2 \ --memory=1g \ --memory-swap=1g \ --pids-limit=512 \ --ulimit nofile=1024:2048 \ --read-only \ --tmpfs /tmp:rw,noexec,nosuid,size=256m \ your-image

解释一下每个参数的目的。--cpus=2和--memory=1g限制 CPU 和内存上限；--memory-swap设为和内存一样，等于禁掉 swap，防止容器把内存挤到 swap 里导致性能雪崩；--pids-limit=512限制进程数，专门防 fork 炸弹；--read-only让容器根文件系统只读，就算被攻破也没法往容器里写木马；--tmpfs挂一个带 noexec 的临时目录，给需要临时写文件的程序用，但禁止在里面执行代码。

在 docker-compose.yml 里对应的写法是：

services: app: image: your-image:1.2.3 read_only: true tmpfs: - /tmp:rw,noexec,nosuid,size=256m pids_limit: 512 mem_limit: 1g memswap_limit: 1g cpus: 2

这套配置我实测在应对日志暴涨、内存泄漏这些场景时非常管用，至少不会因为一个容器把宿主机拖垮。

3. 镜像供应链加固：从源头掐断风险

3.1 基础镜像选型：可控性优先于体积

镜像安全里最基础但最容易被忽略的就是基础镜像选型。很多团队喜欢追求“越小越好”，于是无脑 Alpine，但 Alpine 的 musl libc 跟某些编译型语言的运行时并不兼容，为了修兼容性又去装一堆编译工具，最后镜像反而又大又不安全。

我自己的选型原则是看业务需求，不是看镜像大小。需要 glibc 兼容性的服务（比如大部分 Java、编译过的 Go 静态链接、依赖 libc 的 Python C 扩展），优先选 distroless 或者 debian:*-slim 锁版本；纯脚本型工具、CLI 类应用，Alpine 没问题；需要调试能力的开发环境镜像和生产镜像分开，生产镜像里绝不带 shell 和调试工具。

这里直接给一份选型对照表：

还有一个关键习惯：镜像 tag 必须锁 digest，不能用 latest。latest 是流动的，你昨天验证过的镜像，今天拉下来可能就变了。正确的做法是锁定完整 digest：

image: your-registry.com/team/app@sha256:7a4b6d2e8f0a1c3b5d9e...

CI 脚本里用docker pull之后，通过docker inspect --format='{{index .RepoDigests 0}}'拿到 digest 再写入部署清单。这个流程花的时间很少，但能彻底杜绝“同样的 tag 拉出不同镜像”的供应链风险。

3.2 多阶段构建：把构建工具和运行产物彻底分离

镜像里多一个编译器、多一套依赖管理工具，就多出一块可以被攻击者利用的立足点。多阶段构建的价值不只是减小体积，更重要的是让生产镜像里只有运行所需的最小文件集合。

举个例子，一个 Node.js 服务最常见的做法是这样的：

# 构建阶段 FROM node:22-slim AS builder WORKDIR /app COPY package.json package-lock.json ./ RUN npm ci COPY . . RUN npm run build # 运行阶段 FROM node:22-slim ENV NODE_ENV=production WORKDIR /app COPY --from=builder /app/package.json ./ COPY --from=builder /app/package-lock.json ./ COPY --from=builder /app/node_modules ./node_modules COPY --from=builder /app/dist ./dist USER node EXPOSE 3000 CMD ["node", "dist/server.js"]

这里有几个安全细节点。第一，运行阶段没有复制源码目录，只复制了构建产物和依赖，源码里的测试文件、配置文件不会跟着进镜像。第二，用npm ci而不是npm install，保证依赖版本完全按 lock 文件装。第三，最后用USER node切到非 root 用户运行，绝不以 root 启动服务。第四，构建阶段的工具链，到运行阶段全部被丢弃，攻击者拿到 shell 之后发现镜像里连 curl 都没有，横向利用的难度大大增加。

3.3 镜像扫描与漏洞管理基线

镜像扫描这件事，2026 年已经是安全评审的硬指标，但很多团队“扫了等于没扫”。他们用 Trivy 扫一遍，发现几百个漏洞，不知道哪些要处理哪些可以放，干脆全部忽略。这不对。

扫描不是目的，漏洞风险管理才是。我的做法是把扫描结果按严重程度分级，设定明确的阻断门禁：

扫描工具我长期用的是 Trivy，免费、更新快、支持容器镜像和文件系统扫描。接入 CI 的伪代码很简单：

scan-job: script: - trivy image --severity CRITICAL,HIGH --ignore-unfixed --exit-code 1 your-registry.com/team/app:ci-$CI_COMMIT_SHA

--exit-code 1的意思是扫到高危以上漏洞就让流水线失败，把漏洞风险卡在合并之前。--ignore-unfixed用于忽略还没出修复版本的漏洞，这些通常要转人工评估，不能直接放过去。

除了漏洞扫描，2026 年我建议顺手生成 SBOM 并归档。Trivy 支持一条命令生成：

trivy image --format cyclonedx --output app-cyclonedx.json your-image:1.2.3

SBOM 的作用是当某个基础组件爆出 0day 时，你能在几分钟内知道自己哪个镜像受影响，而不是翻半天文档。

3.4 镜像签名与来源验证

镜像签名在 2024 年之后被越来越多的生产环境接受，2026 年基本可以认为是一线团队的标准配置。思路其实很简单：构建镜像后，用私钥给镜像打个签名，部署前用公钥验证签名，确保“这个镜像确实是你 CI 构建出来的，中间没人动过手脚”。

工具方面，Cosign 是事实标准，支持 OCI registry 直接存储签名，不需要额外搭建服务。签名命令：

cosign sign --key cosign.key your-registry.com/team/app@sha256:7a4b6d...

验证命令：

cosign verify --key cosign.pub your-registry.com/team/app@sha256:7a4b6d...

密钥管理需要注意：私钥应该放在 CI 系统的 secrets 里，或者更好的方式是接入 KMS 签名服务，比如 AWS KMS、阿里云 KMS，用云厂商的签名 API，杜绝私钥被程序员下载到本地这事。我见过不止一次，私钥被某位同学存到了公司 GitLab 代码库里，签名机制变成了笑话。

经验补充：镜像签名是一项“一次配好，长期受益”的投入。配合部署前的 verify 检查，即使内部 registry 被攻破，攻击者注入的恶意镜像也无法通过验证，这是供应链攻击里非常关键的一道防线。

4. 运行时加固：给每个容器配一副“量身定做的镣铐”

4.1 不以 root 运行，并禁止提权

运行时加固里最基础也最有效的一条：容器内应用不要以 root 用户运行。很多官方镜像的默认行为是 root，比如某些版本的 MySQL、Redis，启动脚本里如果没配 USER 指令，容器内进程就是 root。容器被攻破后，进程的权限决定了攻击者的起点，root 起点和普通用户起点的差距巨大。而且如果没开启 userns-remap，容器内 root 逃逸之后直接就是宿主 root。

Dockerfile 里加一行就够了：

USER 10001:10001

注意这里我写的是 UID:GID 而不是用户名，因为镜像里不一定有 /etc/passwd 条目，用纯数字可以避免依赖用户创建逻辑。运行时也可以用参数强制指定：

docker run --user 10001:10001 your-image

光降权还不够，还要防止进程通过 setuid 等方式重新提权。加一个参数：

docker run --security-opt=no-new-privileges your-image

no-new-privileges会在内核层面禁止进程执行 execve 时获得新权限，像 sudo、setuid 二进制、文件 capabilities 这些全部失效。这招对大多数提权类攻击路径有直接阻断效果，成本几乎为零，我会要求所有容器默认开启。要注意的是，某些需要 ping 的镜像会受影响，因为 ping 依赖 file capabilities，但生产环境容器本来就不应该依赖 ping，禁用问题不大。

4.2 裁剪 Linux Capabilities：关掉一切用不到的特权

Linux 的 root 权限不是铁板一块，而是被拆成了几十个独立的 capability，比如 CAP_NET_ADMIN 管网络配置，CAP_SYS_ADMIN 管系统管理，CAP_DAC_OVERRIDE 管绕过文件权限检查。Docker 默认会给容器一批常用的 capability，但绝大多数业务容器根本用不到其中大半。

我推荐的做法是一刀切：默认全部丢弃，只按需加回。

docker run \ --cap-drop=ALL \ --cap-add=NET_BIND_SERVICE \ --cap-add=NET_RAW \ your-image

这里--cap-drop=ALL先放空所有 capability，再按需加。NET_BIND_SERVICE 是绑定 1024 以下端口需要的；NET_RAW 是发 ICMP 包（ping）需要的。实际情况里，大部分应用只加 NET_BIND_SERVICE 就够了。像 CAP_SYS_ADMIN 这种高危能力，生产环境几乎不应该出现在任何容器里，如果哪个应用说必须 CAP_SYS_ADMIN 才能跑，你要思考的不是怎么给它加权限，而是这个应用的设计是不是有问题。

docker-compose 里的对应写法：

services: app: cap_drop: - ALL cap_add: - NET_BIND_SERVICE

有个实际的坑要提醒：某些 Java 应用在低版本 JDK 下会用到 CAP_SYS_ADMIN 获取 container CPU 信息，或者某些监控 Agent 需要读 /proc 的深层信息，导致启动直接崩。排查方式是用docker run --cap-drop=ALL启动后，看日志里是不是有 “Operation not permitted” 字样，再按需加回最少的 capability，别图省事一把梭全放开。

4.3 seccomp 和 AppArmor/SELinux：让内核自己拦一道

capability 管的是“能不能做某件事”，而 seccomp（安全计算模式）管的是“能不能调用某个系统调用”。很多内核漏洞利用都是通过一组罕见的 syscall 组合实现的，seccomp 可以直接在 syscall 层把它拦掉。Docker 自带的默认 seccomp profile 已经禁用了几十个高风险的系统调用，比如 unshare、keyctl 等，这些恰恰是绝大多数容器逃逸漏洞会用到的。

生产环境不用做太多事情，只需要确保启动容器时没有加--security-opt seccomp=unconfined就行。如果业务确实需要自定义 profile（比如某些需要 clone 特定 flag 的应用），也可以自己写 json，但这是少数情况。一个典型的自定义 seccomp profile 长这样，保留必要 syscall 并拒绝其他所有：

{ "defaultAction": "SCMP_ACT_ERRNO", "architectures": ["SCMP_ARCH_X86_64"], "syscalls": [ { "names": ["read", "write", "openat", "close", "fstat", "mmap", "munmap", "brk", "execve", "exit_group", "rt_sigaction", "set_thread_area", "set_tid_address"], "action": "SCMP_ACT_ALLOW" } ] }

另一个常被忽略的防护是 AppArmor（Ubuntu 系）或者 SELinux（CentOS/RHEL 系）。Docker 在 Ubuntu 上默认给容器加载一个 apparmor profile（docker-default）。SELinux 在 RHEL 系发行版上如果你开了 enforcing，Docker 的容器域也会被限制。平时通常不用专门调整，但别把主机的 SELinux/AppArmor 关掉。我见过不少团队，为了省事直接在 /etc/selinux/config 里把 SELinux 改成 disabled，理由是有兼容性问题。这相当于把整套纵深防御里的最后一堵墙拆了，非常不划算。2026 年还这么干，真说不过去。

4.4 文件系统隔离：能只读就只读，能不让写就别让写

容器被攻破之后，攻击者第一件事就是往容器里写工具、写脚本，或者找宿主机的敏感目录。文件系统层面的限制越严格，攻击者受到的束缚越大。

Docker 提供的最简单有效的手段是--read-only，把容器根文件系统设为只读。应用需要写文件的路径，单独用 tmpfs 或者数据卷挂载，这样就算代码被注入，也没法在容器里留下持久化的恶意文件。临时写目录用 tmpfs：

docker run --read-only --tmpfs /tmp:rw,noexec,nosuid,size=512m your-image

给数据卷挂载也尽量带上只读后缀:ro，特别是配置文件和密钥文件，运行期间根本不需要被容器修改：

docker run -v /etc/app-config:/etc/app-config:ro your-image

还有一个老生常谈但年年有人踩的雷：不要把宿主机根目录或者 /etc 挂载进容器，不要把 docker.sock 挂进容器，不要让容器直接操作宿主机的设备文件。真需要跨容器共享数据，用命名卷（named volume）而不是 bind mount。命名卷由 Docker 管理，有更明确的权限边界。

4.5 网络隔离：端口暴露面最小化，禁止 host 网络

我把网络隔离单独拎出来说，是因为它最直观也最常被忽略。很多应用出问题，根本不是漏洞被利用，而是端口直接裸奔在公网上被人扫描爆破。

生产环境默认用自定义 bridge 网络，不要用默认的 bridge0，更不要用 host 网络。自定义网络的好处是容器之间可以用服务名互相访问，同时你可以精确控制哪些容器在同一网络里，实现分区域隔离。比如前端服务一个网络，后端服务一个网络，数据库只在后端网络里，连前端都访问不到数据库。

services: api: networks: - backend db: networks: - backend frontend: networks: - frontend networks: backend: driver: bridge internal: true frontend: driver: bridge

这里 database 的网络设为internal: true，意味着这个网络没有外部通信能力，数据库只能被同网络的服务访问，从根本上杜绝了数据库端口对宿主机和公网的暴露。

端口映射方面，规则很简单：只映射业务必须的端口，并且尽量绑定内网 IP，不要绑定 0.0.0.0。比如 Redis 如果只有内网服务在用：

docker run -p 127.0.0.1:6379:6379 redis:7-alpine

这样 Redis 只监听宿主机的回环地址，外部无法直接访问，只能通过内网其他服务代打。host 网络模式直接禁用，除非你能给出非常充分的理由并经过安全评审，因为它让容器直接共享宿主网络栈，网络的命名空间隔离完全失效。

4.6 敏感信息管理：环境变量里不能放密码

容器安全里最常见的泄露渠道，一个是环境变量，一个是镜像构建缓存。很多团队习惯把数据库密码、API Key 直接写进 docker run 的 -e 参数里，或者写到 docker-compose.yml 的 environment 里。问题是，任何能执行docker inspect的人，或者能在宿主机上看到进程环境变量的人，都能直接拿到这些明文密钥。

2026 年的基线做法是：环境变量里只放非敏感配置，密钥类信息一律走密钥管理服务。Docker 自带的最轻型方案是 Docker Secrets（Swarm 模式下可用），单机 Docker 也可以配合文件挂载把密钥以只读文件方式传入容器：

docker run -v /run/secrets/db_password:/run/secrets/db_password:ro your-image

应用从文件读取密码，而不是从环境变量读取。更大规模的生产环境，建议统一接入 Vault、KMS 或云厂商的 Secrets Manager，由应用 SDK 动态拉取，密钥还能定期轮换。这已经超出了 Docker 本身的范围，但如果不这么做，前面所有加固的意义都会打折扣——攻击者一旦从应用里拿到数据库密码，再好的容器隔离也拦不住他。

5. 审计监控与工程化落地

5.1 Docker daemon 与容器的审计日志

安全加固不等于配置完了就能一劳永逸，日志和审计是把“加固”变成“可控”的闭环。我遇到不少团队，容器跑得很好，但出了问题看日志才发现什么记录都没有，无从溯源。

Linux 审计系统是最底层的一层。配置 /etc/audit/rules.d/docker.rules，监视 Docker 关键目录和二进制：

-w /usr/bin/docker -p wa -k docker -w /var/lib/docker -p wa -k docker -w /etc/docker -p wa -k docker -w /var/run/docker.sock -p wa -k docker

然后service auditd restart。之后谁动了 docker 配置、谁改了镜像目录、谁往 socket 发了什么请求，都会有审计记录。这层日志平时没用，出了事就是还原现场的关键证据。

Docker 自身的日志建议按前文 daemon.json 里的配置，限制单个日志文件大小和保留份数，避免日志无限增长占满磁盘。日志轮转用 logrotate 配置 /var/lib/docker/containers 目录也可以，但更推荐直接用 Docker 的 log-opts 控制，简单有效。

5.2 运行时威胁检测：把“事后查日志”变成“事中报警”

日志再全也是事后的。2026 年生产级加固里，运行时异常检测已经是标配，不是可选项。最常用的开源方案是 Falco，它通过内核模块或者 eBPF 采集系统调用事件，根据规则检测容器里的异常行为，比如容器内启动了 shell、容器挂载了新的敏感目录、容器尝试读取宿主机的 /etc/shadow 等。

Falco 部署在宿主机上（或者作为特权 DaemonSet 跑在 K8s 节点上），规则配置示例：

- rule: Terminal shell in container desc: A shell was spawned inside a container condition: >- container.id != host and proc.name in (bash, sh, zsh, dash) and not proc.name in (runtime_shells) output: "Shell spawned in container (user=%user.name container=%container.name image=%container.image proc=%proc.cmdline)" priority: WARNING

当有攻击者打进容器并尝试执行 shell 时，Falco 会在几秒内发出告警，配合告警平台（钉钉、Slack、企业微信、PagerDuty）立刻通知到人。这个能力在勒索病毒和挖矿木马入侵场景里价值极大，很多攻击都是先进容器，然后在容器里拉挖矿程序、跑扫描器，这些行为 Falco 都能识别到。不用把规则搞太复杂，先落地基础规则，跑一段时间再根据误报调整优先级，比什么都不做强十倍。

5.3 CI/CD 流水线里强制加三道安全门禁

安全能力要真正落地，必须嵌到流水线里，靠人自觉基本是不现实的。2026 年我们的 CI 里至少要加三道门禁。

第一道，镜像构建完成后立即做漏洞扫描，扫到高危以上就失败。这一条前面已经讲了。

第二道，部署前必须完成签名验证。CI 流程里从 registry 拉镜像时执行cosign verify，验证不过直接中止。这样可以确保即使有人私下把镜像 push 进 registry，也绕不过签名校验这一关。

第三道，基础设施即代码的配置校验。如果你用 docker-compose 或者 Helm 部署，建议用 conftest 这类工具写一些策略，检查部署配置里有没有禁用前面说的危险参数，比如有没有用 privileged 模式、有没有挂载 docker.sock、有没有设置 no-new-privileges。我把一个最小策略 JSON 放在项目里：

package main deny[msg] { input.kind == "Deployment" input.spec.template.spec.containers[_].securityContext.privileged == true msg := "Privileged containers are not allowed" }

写策略的目的不是阻止所有特殊情况，而是让“危险配置”必须经过明确审批流程才能上线，而不是随手抄一份网上配置就进生产。

6. 完整 Checklist 一览与常见问题排查

6.1 2026 生产级 Docker 安全加固清单

下面这份清单是我实际用来做生产环境安全巡检的缩减版本，可以直接对照执行。每一项都按“宿主层、镜像层、运行时层、审计与工程化”分类，凡是打勾的项都是要落到实际操作里的。

这份清单看起来项数不多，但每一项背后都对应一类真实发生过的事故。建议可以按月巡检一次，扫描一下当前运行的容器，看看有没有哪几项已经退化掉了。

6.2 加固过程中最常踩的五个坑

加固做多了，翻车的环节其实很固定。我整理一下最常见的问题和排查思路，基本覆盖了 80% 的情况。

第一个坑，userns-remap 开启后挂载卷权限不对。症状是容器内报 Permission denied，原因是 UID 经过映射之后变了。排查时在宿主机上执行ls -n /path/to/mount看实际 UID，再对照/etc/subuid里映射的范围，手动 chown 到对应 UID 即可。新项目建议从搭建第一天就启用 userns-remap，后面几乎没有这种存量兼容问题。

第二个坑，seccomp 太严导致应用崩溃。典型症状是容器启动后立刻退出，日志里有 “Operation not permitted”。这时先用宽松方式启动确认是 seccomp 的问题，再写自定义 profile 给特定进程放行所需 syscall。注意不要图省事直接 unconfined，宁可多花半小时精确定位到具体 syscall。

第三个坑，no-new-privileges 导致某些镜像无法启动。这个问题常在老镜像里出现，尤其是一些包含 setuid 辅助程序的基础镜像。解决办法是给应用单独构建镜像，移除 setuid 依赖，或者调整启动方式，不要因为一个镜像的兼容性把全局安全参数去掉。

第四个坑，userns-remap 和 Docker 存储驱动不兼容。docker info 里能看到 Storage Driver，如果在某些文件系统上 overlay2 开启失败，Fuse-overlayfs 是备选方案。但这通常只影响老内核或老发行版，2026 年的主流系统基本都支持原生 overlay2 配合用户命名空间，遇到问题优先升级内核而不是换存储驱动。

第五个坑，cap-add 加多了没发现。有人在容器启动脚本里写了--cap-add=ALL或者干脆--privileged，然后把失败的服务归因到其他方面。巡检的时候一行命令就能发现：

docker inspect --format='{{.HostConfig.Privileged}} {{.HostConfig.CapAdd}}' $(docker ps -q)

所有返回 true 或者包含 ALL 的容器，都应该是需要重点审视的对象。

6.3 加固完成之后建议怎么验证

配置都改完了，别忘了做一次验证。我自己的习惯是每次加固完跑一轮“假设已经被攻破”的推演：模拟一个攻击者已经进入了容器，然后看它还能干什么。试试在容器里能不能装软件（只读文件系统会挡掉）、能不能提权到 root（no-new-privileges 会挡掉）、能不能访问宿主机目录（挂载权限会挡掉）、能不能横向连别的容器（网络策略会挡掉）、能不能写点东西留后门（read-only 会挡掉）。每一项都试一遍，心里就有底了。

另外可以跑一下 Docker 官方的安全基准检测工具，docker-bench-security，它把 Cis Docker Benchmark 里的检查项自动跑一遍，输出哪些合规哪些不合规。用法很简单：

docker run --rm --net host --pid host --userns host \ --cap-add audit_control \ -e DOCKER_CONTEXT=default \ -v /var/lib:/var/lib \ -v /var/run/docker.sock:/var/run/docker.sock \ -v /usr/lib/systemd/system:/usr/lib/systemd/system \ -v /etc:/etc \ --label docker_bench_security \ docker/docker-bench-security

跑完直接看输出的 WARN 项和 PASS 项，能很快发现自己遗漏的配置。需要说明的是，这个工具给出的很多建议是“保守基线”，有些项在特定业务场景下可以放宽（比如某些中间件确实需要额外 capability），但至少要知道自己放宽了哪一项、为什么放宽、风险是什么，而不是稀里糊涂就绕过了检查。

我在实际项目中最大的体会是：容器安全加固并不是某一个单独的动作，而是把“宿主系统、镜像构建、运行参数、监控审计”当成一整条链路来治理。很多加固项单独看都是小改动（加个参数、改个配置），但合在一起，攻击者在框架里横向移动的每一层都有一道闸门。这套思路延续到 Kubernetes 环境同样成立，只是把宿主机层的加固变成了节点池和容器运行时层面的事情。先把 Checklist 里的每一项认真过一遍，后续上 K8s 的时候，你会发现大部分安全设计是可以直接平移过去的。