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 }这里用 defaultDocker 会自动创建名为 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 Docker2026 年生产环境的新基线如果说 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_start0或者用 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 \ --cpus2 \ --memory1g \ --memory-swap1g \ --pids-limit512 \ --ulimit nofile1024:2048 \ --read-only \ --tmpfs /tmp:rw,noexec,nosuid,size256m \ your-image解释一下每个参数的目的。--cpus2和--memory1g限制 CPU 和内存上限--memory-swap设为和内存一样等于禁掉 swap防止容器把内存挤到 swap 里导致性能雪崩--pids-limit512限制进程数专门防 fork 炸弹--read-only让容器根文件系统只读就算被攻破也没法往容器里写木马--tmpfs挂一个带 noexec 的临时目录给需要临时写文件的程序用但禁止在里面执行代码。在 docker-compose.yml 里对应的写法是services: app: image: your-image:1.2.3 read_only: true tmpfs: - /tmp:rw,noexec,nosuid,size256m 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 和调试工具。这里直接给一份选型对照表需求场景推荐基础镜像主要理由编译型语言Go、Rustdistrolessgcr.io/distroless/base无 shell、无包管理器攻击面极小Python/Node 等解释型服务node:22-slim / python:3.12-slim保留运行时去掉编译器和文档工具类 CLIalpine:3.20体积小包管理方便注意 musl 兼容性需要兼容 glibc 的老服务debian:12-slimglibc 兼容性最好漏洞源相对可控数据库中间件等官方镜像官方仓库锁 digest官方维护配合扫描和签名验证还有一个关键习惯镜像 tag 必须锁 digest不能用 latest。latest 是流动的你昨天验证过的镜像今天拉下来可能就变了。正确的做法是锁定完整 digestimage: your-registry.com/team/appsha256: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_ENVproduction WORKDIR /app COPY --frombuilder /app/package.json ./ COPY --frombuilder /app/package-lock.json ./ COPY --frombuilder /app/node_modules ./node_modules COPY --frombuilder /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 扫一遍发现几百个漏洞不知道哪些要处理哪些可以放干脆全部忽略。这不对。扫描不是目的漏洞风险管理才是。我的做法是把扫描结果按严重程度分级设定明确的阻断门禁漏洞级别处理策略时间要求Critical可用于远程代码执行必须阻断阻塞合并和部署立即修复或替换镜像High可被本地利用或可被攻击者间接利用阻塞部署到生产3 个工作日内修复Medium/Low记录并跟踪配合月度例行更新处理扫描工具我长期用的是 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.3SBOM 的作用是当某个基础组件爆出 0day 时你能在几分钟内知道自己哪个镜像受影响而不是翻半天文档。3.4 镜像签名与来源验证镜像签名在 2024 年之后被越来越多的生产环境接受2026 年基本可以认为是一线团队的标准配置。思路其实很简单构建镜像后用私钥给镜像打个签名部署前用公钥验证签名确保“这个镜像确实是你 CI 构建出来的中间没人动过手脚”。工具方面Cosign 是事实标准支持 OCI registry 直接存储签名不需要额外搭建服务。签名命令cosign sign --key cosign.key your-registry.com/team/appsha256:7a4b6d...验证命令cosign verify --key cosign.pub your-registry.com/team/appsha256: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-optno-new-privileges your-imageno-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-dropALL \ --cap-addNET_BIND_SERVICE \ --cap-addNET_RAW \ your-image这里--cap-dropALL先放空所有 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-dropALL启动后看日志里是不是有 “Operation not permitted” 字样再按需加回最少的 capability别图省事一把梭全放开。4.3 seccomp 和 AppArmor/SELinux让内核自己拦一道capability 管的是“能不能做某件事”而 seccomp安全计算模式管的是“能不能调用某个系统调用”。很多内核漏洞利用都是通过一组罕见的 syscall 组合实现的seccomp 可以直接在 syscall 层把它拦掉。Docker 自带的默认 seccomp profile 已经禁用了几十个高风险的系统调用比如 unshare、keyctl 等这些恰恰是绝大多数容器逃逸漏洞会用到的。生产环境不用做太多事情只需要确保启动容器时没有加--security-opt seccompunconfined就行。如果业务确实需要自定义 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 } ] }另一个常被忽略的防护是 AppArmorUbuntu 系或者 SELinuxCentOS/RHEL 系。Docker 在 Ubuntu 上默认给容器加载一个 apparmor profiledocker-default。SELinux 在 RHEL 系发行版上如果你开了 enforcingDocker 的容器域也会被限制。平时通常不用专门调整但别把主机的 SELinux/AppArmor 关掉。我见过不少团队为了省事直接在 /etc/selinux/config 里把 SELinux 改成 disabled理由是有兼容性问题。这相当于把整套纵深防御里的最后一堵墙拆了非常不划算。2026 年还这么干真说不过去。4.4 文件系统隔离能只读就只读能不让写就别让写容器被攻破之后攻击者第一件事就是往容器里写工具、写脚本或者找宿主机的敏感目录。文件系统层面的限制越严格攻击者受到的束缚越大。Docker 提供的最简单有效的手段是--read-only把容器根文件系统设为只读。应用需要写文件的路径单独用 tmpfs 或者数据卷挂载这样就算代码被注入也没法在容器里留下持久化的恶意文件。临时写目录用 tmpfsdocker run --read-only --tmpfs /tmp:rw,noexec,nosuid,size512m 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 SecretsSwarm 模式下可用单机 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 安全加固清单下面这份清单是我实际用来做生产环境安全巡检的缩减版本可以直接对照执行。每一项都按“宿主层、镜像层、运行时层、审计与工程化”分类凡是打勾的项都是要落到实际操作里的。层级检查项推荐配置/命令宿主层Docker socket 权限/var/run/docker.sock 属主 root:docker权限 660宿主层daemon 监听地址仅 Unix socket禁用未加密 TCP 端口宿主层daemon 全局禁止提权daemon.json 设置 no-new-privilegestrue宿主层容器间默认隔离daemon.json 设置 iccfalse宿主层用户命名空间/rootless二选一userns-remapdefault或直接 rootless 安装宿主层日志轮转json-file 日志max-size50mmax-file5镜像层基础镜像锁 digest不用 latest锁定 sha256 digest镜像层多阶段构建生产镜像无编译器、无源码、无调试工具镜像层镜像漏洞扫描Trivy 扫描Critical/High 阻断部署镜像层镜像签名cosign 签名并验证签名通过才部署镜像层SBOM 归档每次构建生成 CycloneDX 格式 SBOM 并保存运行时层容器运行用户Dockerfile 设置 USER 10001:10001 或 --user 参数运行时层禁止提权--security-optno-new-privileges运行时层Capabilities 裁剪--cap-dropALL按需 --cap-add运行时层seccomp 策略使用 Docker 默认 profile禁止 unconfined运行时层文件系统只读--read-only配合 tmpfs 写临时文件运行时层敏感挂载检查不挂载 docker.sock、宿主 /etc、/root运行时层网络隔离自定义 bridge 网络端口绑定内网 IP禁用 host 网络运行时层资源限制--cpus、--memory、--pids-limit、--ulimit 全设置运行时层密钥管理不用环境变量传密钥用 Docker Secrets/Vault/KMS审计与工程化审计日志配置 auditd 规则监控 docker 目录和 socket审计与工程化运行时检测部署 Falco容器内 shell、提权行为实时告警审计与工程化CI 安全门禁扫描失败拒合并、签名验证过才部署、策略校验防危险配置这份清单看起来项数不多但每一项背后都对应一类真实发生过的事故。建议可以按月巡检一次扫描一下当前运行的容器看看有没有哪几项已经退化掉了。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-addALL或者干脆--privileged然后把失败的服务归因到其他方面。巡检的时候一行命令就能发现docker inspect --format{{.HostConfig.Privileged}} {{.HostConfig.CapAdd}} $(docker ps -q)所有返回 true 或者包含 ALL 的容器都应该是需要重点审视的对象。6.3 加固完成之后建议怎么验证配置都改完了别忘了做一次验证。我自己的习惯是每次加固完跑一轮“假设已经被攻破”的推演模拟一个攻击者已经进入了容器然后看它还能干什么。试试在容器里能不能装软件只读文件系统会挡掉、能不能提权到 rootno-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_CONTEXTdefault \ -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 的时候你会发现大部分安全设计是可以直接平移过去的。