孙绿搞Docker这么久，有个现象我一直觉得挺有意思：很多人第一天装好Docker就急着换镜像源、拉MySQL、部署Redis主从，但对docker run跑起来之后那个容器到底敞开了多少扇门，却很少认真想过。尤其是看到热搜里那么多人在问"Docker服务启动失败"、"virtualization support wasn't detected"这类安装问题，我意识到大部分用户其实还停留在"能跑起来就行"的阶段。可一旦你把容器从开发机挪到服务器上，或者跑青龙面板、搭DVWA靶场这类要长期挂机的服务，容器安全就从一个"加分项"直接变成"必答题"。
这篇文章我不打算堆理论，我想从一个实际运维过Docker服务的人的角度，把主机层加固、守护进程配置、镜像供应链、运行时隔离、网络与数据安全这几个层面挨个捋一遍，附上直接能抄的配置和排查命令。写之前先说明一件事：Docker本身不等于不安全，但它的默认配置照顾的是"开箱即用"，不是"开箱即锁"。你要做的，是把它从默认状态拧到一个适合生产运行的状态。
1. 刀没架在脖子上：先认清Docker到底在防护什么
在动手加固之前，我觉得有个观念得先立住——Docker的安全边界和传统虚拟机有本质区别。
很多人习惯把容器当成"轻量级虚拟机"来理解，这个概念在资源共享上没问题，但在安全模型上会害死人。虚拟机靠Hypervisor把Guest Kernel和Host Kernel完全隔开，Guest里即使拿到root权限，也只是虚拟化层之上的root，想逃逸到宿主机还得再打穿一层Hypervisor。容器不一样，容器和宿主机共享同一个Linux内核，所谓的隔离是靠着namespace（命名空间）和cgroups（控制组）这套内核机制做出来的逻辑隔离，不是硬件级隔离。做一个不太严谨但很形象的类比：虚拟机是把你关在独立的房间里，门锁是物理的；容器是把你放在一个大厅里用屏风隔出的小隔间，屏风够高够结实，但你跟其他人呼吸的是同一片空气。
这就引出了Docker安全优化的第一条主干逻辑：内核逃逸是容器安全里severity最高的一条链路，你要做的所有配置，大方向上都指向同一个目标——即使容器被攻破，也要让攻击者寸步难行。
基于这个认知，我通常把Docker安全拆成四个层面来看，后面每一章对应一个层面：
| 层面 | 安全问题 | 典型手段 |
|---|---|---|
| 主机层 | 容器逃逸后直接摸到宿主机文件/网络 | 非root运行、独立数据盘、内核加固 |
| 守护进程层 | Docker daemon本身被滥用 | TLS认证、Socket权限收敛、配置审计 |
| 镜像供应链 | 拉进恶意的或带漏洞的镜像 | 镜像签名、漏洞扫描、极小化基础镜像 |
| 运行时层 | 容器内进程权限过大或配置不当 | 默认capabilities裁剪、只读根文件系统、rootless模式 |
这四个层面不是独立存在的。后面你会看到，很多安全措施其实是环环相扣的——比如镜像层做到位了，运行时层的很多风险自然就消失了；运行时层把capabilities一裁剪，即使某个恶意镜像里带了提权工具也发挥不出来。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 防逃逸的第一道防线：宿主机与守护进程的一次硬核体检
很多Docker加固教程上来就让你改daemon.json、加--cap-drop，但我个人的习惯是先从宿主机和Docker daemon本身下手。原因很简单：这两块是承担所有其他安全措施的地基，地基不稳，上面做再多加固都是空中楼阁。
2.1 用独立分区挂载Docker数据目录
生产环境里，我强烈建议把Docker的root目录放到独立的数据盘分区上。不是说你一定要加一块物理磁盘，用云服务器的数据盘单独分区也行。这么做的安全意图在于：Docker的数据目录里默认存放着所有镜像层、容器可写层、volume数据，如果某个容器因为异常写入把根分区塞满了（日志爆掉、落盘文件疯狂增长这类事我见过太多次），宿主机操作系统可能直接变成只读状态，所有服务跟着瘫痪。而如果Docker目录独立挂载，最坏情况只是Docker daemon不可用，宿主机SSH还能进得去，你还有机会去清理排查。
操作上，我一般在/etc/docker/daemon.json里显式指定：
json复制{
"data-root": "/data/docker"
}
然后把原有数据迁过去：
bash复制sudo systemctl stop docker
sudo rsync -avP /var/lib/docker/ /data/docker/
sudo mv /var/lib/docker /var/lib/docker.bak
sudo systemctl start docker
迁移完成后别急着删备份目录，跑几天确认服务正常再清理。这是数据安全的底线操作，宁可多占点磁盘。
2.2 Docker daemon的暴露面收敛
Docker daemon默认监听在/var/run/docker.sock这个Unix Socket上，这个路径对当前用户组的权限非常宽松。热点里有人问"Docker Desktop启动失败"、有人研究PHP容器打包镜像，但我敢说很多人没意识到一个问题：谁拿到了docker.sock的访问权限，谁就等效于拿到了宿主机的root权限。 原因很简单，你调用Docker API创建一个新容器时，可以把宿主机的根目录直接挂载进容器：
bash复制docker run -it -v /:/host ubuntu chroot /host
这条命令一旦执行成功，容器里的shell就是宿主机根文件系统里的root。这就是为什么我在任何场合都强调：docker.sock的归属组一定要收窄，不要让一堆无关用户都加在docker组里。安全检查的命令也很直接：
bash复制ls -l /var/run/docker.sock
sudo getent group docker
另外，如果你的Docker daemon开启了TCP监听（用-H tcp://0.0.0.0:2375这种参数启动的），那问题更严重，相当于在公网上裸奔了一个root权限API。Docker daemon的TCP端口如果必须开，一定要配合TLS客户端证书认证。用证书双向认证做一个最小配置：
bash复制# 生成CA和客户端证书的简易流程
openssl genrsa -aes256 -out ca-key.pem 4096
openssl req -new -x509 -days 365 -key ca-key.pem -sha256 -out ca.pem
然后在daemon.json里指定：
json复制{
"tlsverify": true,
"tlscacert": "/etc/docker/ca.pem",
"tlscert": "/etc/docker/server-cert.pem",
"tlskey": "/etc/docker/server-key.pem",
"hosts": ["tcp://0.0.0.0:2376", "unix:///var/run/docker.sock"]
}
端口也从2375换成2376。如果只是单机使用，最省心的方案是干脆不开启TCP监听，老老实实用Unix Socket。
2.3 守护进程的版本保持与自动重启策略
有次我排查一个诡异的容器网络问题，查到最后发现是Docker版本太老，和宿主机内核的iptables模块配合出了bug。版本滞后不光影响功能，还意味着你错过了一堆已经修复的安全CVE。我现在的习惯是专门给Docker的升级留出维护窗口，不跟着最新版跑，但也绝不落后大版本太多。
在systemd层面，建议确认docker服务和containerd服务都设置了Restart=always，这样即使daemon因为异常崩溃，也能被拉起，不至于因为守护进程挂掉导致所有容器集体失联。检查方式：
bash复制systemctl cat docker | grep Restart
systemctl cat containerd | grep Restart
如果这几个基础项都没问题，我会建议你重点审视一个经常被忽略的环节——内核和Docker版本的兼容性。"Docker Desktop没检测到虚拟化支持"这类报错本质上是内核级虚拟化能力的问题，老内核跑新Docker容易出现cgroup v2、iptables nftables后端的兼容性隐患，而内核层面的漏洞又是容器逃逸的重灾区。保持内核更新到发行版支持的最新稳定版，是一项性价比极高的安全投入。
3. 镜像供应链：你拉下来的每一层都可能藏着后门
镜像相关的热搜词占了很大比例：mysql8.0、redis主从、DVWA靶场、青龙面板依赖管理……这些都说明大家日常用Docker最多的场景就是拉取现成镜像。正因如此，镜像供应链的安全审查是整个Docker安全体系里信息差最大的一块。
3.1 别让“下载快”成为唯一选镜像标准
镜像加速器是很多人关心的点，毕竟Docker镜像下载慢确实烦人。但我要提醒一句：镜像加速换来的是速度，镜像来源审查换回来的是底线。 如果你只是为了下载快点就随便从网上复制一个不知名加速源，或从非官方仓库拉镜像，那你实际上是把整个主机的安全交给了一个陌生人。
我自己的选镜像原则是四步：
- 优先使用Docker Hub上带
official标识的镜像，或者知名组织发布的镜像（比如mongo官方镜像、redis官方镜像）。 - 查看镜像的pull次数和stars，但注意这个指标只能排除掉明显不靠谱的，不能作为充分信任依据。
- 观察镜像的tag，不要用
latest，因为latest指向的内容是可变的，上个月安全的下个月不一定安全。尽量用具体的版本号，如mysql:8.0.39。 - 关键的线上镜像，用
docker history看一下构建过程，看看是不是有奇怪的ADD远程文件步骤、是不是有在构建过程中写入密钥的嫌疑。
第四步很多人没做过，我给你一个执行过的实例。之前有人问我青龙面板的依赖管理老是报错该不该信某个第三方镜像，我把那个镜像的历史层拉出来：
bash复制docker history --no-trunc --format "{{.ID}} {{.CreatedBy}}" your-image:tag
结果发现其中一层在构建时执行了一段下载脚本，URL指向一个个人服务器。这种镜像不一定是恶意的，但你把信任交给了一个未知的脚本执行源，这本身就是风险。对长期跑的服务来说，我宁可自己写Dockerfile从头构建，也不用来源不明的二进制。
3.2 构建阶段的卫生习惯：拒绝在镜像里留密钥
有个高频事故我一直想拎出来单独说：把数据库密码、API密钥写进Dockerfile的环境变量或代码里，然后构建出镜像推到仓库。这个做法的危险点在于，镜像的每一个layer都是可以被拆开查看的，所谓"删掉"并不是真正删除，它只是在新层上覆盖了一层标记。别人拉取镜像后执行docker history就能看到历史层的环境变量，甚至用工具直接把旧层解开，密钥全部现形。
正确的做法是使用Docker的secret管理特性，或者至少在运行时通过环境变量注入，而不是烧进镜像层。在Compose环境中，用env_file比硬编码到docker-compose.yml更稳妥；而像MySQL这类数据库容器的密码初始化，官方镜像支持通过环境变量传入，这些变量的值应该来自部署时生成或外部密钥管理服务，而不是提交到Git仓库。
3.3 镜像漏洞扫描与极小化
镜像扫描工具，我常用的有Trivy和Grype。虽然它们不能扫描出所有漏洞，但至少能拦下一批已知CVE。以Trivy为例，一条比较标准的扫描命令：
bash复制trivy image --severity HIGH,CRITICAL --ignore-unfixed your-image:tag
--ignore-unfixed参数的意思是只关心有修复方案的漏洞，因为我个人不关心哪些漏洞当前无解——无解的事你花再多时间也改变不了结果，不如把精力放到能修的上。扫描结果里如果出现大量HIGH/CRITICAL且基础镜像版本太老，正确的做法不是一个个补丁去修，而是换更新的基础镜像版本重新构建。很多项目依赖的基础镜像本身就多年不更新，这种情况下镜像扫描的意义不只是追究责任，更是提醒构建者：你欠的技术债该还了。
另外建议遵循镜像极小化原则：运行镜像里只需要二进制和必要运行库，不要装包管理器、不要带编译器、不要留shell脚本。攻击者进入容器后，没有bash、没有curl、没有apt，他能干的事直接少一大半。常见的做法是采用两阶段构建，比如用golang:1.22作为builder阶段，最终运行阶段使用scratch或alpine。
4. 运行时关卡：capabilities裁剪与只读文件系统的组合拳
运行时安全是整个安全体系里最"Docker"的部分，也是性能损耗最小但收益最大的一环。你有没有想过一个问题：一个运行Nginx的容器，它真的需要CAP_SYS_ADMIN这种能力吗？当然不需要。但如果你用的是默认配置，你的容器进程在Linux内核能力模型里默认就拥有很大一组capabilities——这不是说容器就一定会被利用，而是说它的攻击面远比它实际需要的大。
4.1 capabilities裁剪是优先级最高的运行时措施
Linux capabilities机制把root权限拆成一个个独立的小权限，比如CAP_NET_BIND_SERVICE表示可以绑定1024以下端口，CAP_SYS_PTRACE表示可以对进程做调试。Docker的默认白名单已经做过一轮裁剪，但仍然保留了相当多容器根本用不到的能力。我常用的安全运行参数长这样：
bash复制docker run -d \
--name safe-nginx \
--cap-drop=ALL \
--cap-add=NET_BIND_SERVICE \
--cap-add=CHOWN \
--cap-add=SETGID \
--cap-add=SETUID \
--cap-add=DAC_OVERRIDE \
nginx:1.27-alpine
--cap-drop=ALL是先把所有能力丢掉，然后按需添加。很多人不太适应这种方式，总觉得万一漏了哪个capability会导致服务起不来。我的建议是：宁可多试错几次，也要守住最小权限原则。比如Nginx默认要监听80/443端口就需要NET_BIND_SERVICE，要改文件属主就需要CHOWN，要切换worker进程身份就需要SETGID和SETUID。如果启动后日志里报operation not permitted，你再去对照日志逐个加回来就行，这个过程本身就是一次安全审计，会让你重新思考容器真正需要什么。
4.2 只读根文件系统与临时目录的取舍
另一个经常被忽视的参数是--read-only。它把容器的根文件系统挂载为只读，攻击者即使进了容器，想往/bin或/etc里写东西也办不到。这在Web类容器里特别有用——你见过多少WebShell是攻击者利用文件上传漏洞写进容器里的？配合只读根文件系统，这一步直接失效。
但是，光加--read-only大概率会让一堆应用崩溃，因为它们默认会往/var/log、/tmp等路径写运行数据。解决方案不是放弃只读，而是显式把需要写的路径改成tmpfs挂载：
bash复制docker run -d \
--name safe-app \
--read-only \
--tmpfs /tmp:rw,noexec,nosuid,size=128m \
--tmpfs /var/log/nginx:rw,noexec,nosuid,size=16m \
nginx:1.27-alpine
noexec的意思是挂载在这个路径上的文件不能被执行，攻击者就算往/tmp里传了一个提权脚本，也没办法直接运行它。nosuid则是禁止setuid位生效，进一步压缩提权空间。这是成本极低、收益极高的小技巧。
4.3 不跑root：用户态的最后一道闸门
容器里默认以root身份运行应用，这个问题的严重程度比大多数人想象的更高。我刚才说过，容器内的root虽然受namespace限制，但一旦攻击者结合某个内核漏洞突破隔离层，他获得的就是宿主机的root——因为你容器内跑的进程UID就是0，对应宿主机上就是root权限，内核在做权限校验时根本不区分"container root"和"host root"。
所以标准的做法是让容器内进程以非root用户运行。在Dockerfile里显式创建用户：
dockerfile复制FROM node:20-alpine
RUN addgroup -S appgroup && adduser -S appuser -G appgroup
USER appuser
COPY --chown=appuser:appgroup . /app
WORKDIR /app
CMD ["node", "server.js"]
如果你用的是别人构建的镜像，没法改Dockerfile，可以在运行时用--user参数指定UID和GID：
bash复制docker run --user 10001:10001 some-image:tag
这里10001可以是宿主机上一个未使用的普通用户UID，具体数值看你怎么规划。注意一个问题：如果镜像内有文件是root属主且权限是600，那么你用--user启动后应用可能没有权限读取这些文件，需要额外挂载卷或修改属主。
4.4 seccomp与rootless：纵深防御的进阶选项
如果前面这些还不够，还有两个进阶手段。第一个是seccomp（安全计算模式），它可以限制容器内进程可以使用的系统调用。Docker默认自带一个seccomp profile，这里面已经屏蔽了大约44个危险系统调用，包括clone配合某些flag、keyctl这类容易出问题的地方。需要自定义时，可以写一个profile JSON文件，在运行时指定：
bash复制docker run --security-opt seccomp=/path/to/profile.json my-image
第二个进阶手段是rootless模式。Rootless Docker的思路是完全不使用root身份去运行daemon和容器，它通过用户命名空间把容器内的root映射到宿主机的普通用户，这样一来即使内核漏洞被利用，攻击者的权限也被限制在普通用户级别。配置rootless模式的官方脚本在Docker文档里可以找到，我实际用下来的感受是：大部分常规容器都没问题，但有些需要绑定低端口（80/443）、或者需要操作复杂网络（macvlan、bridge的特定功能）的场景会受限制，需要再借助rootlesskit的端口映射能力做适配。
5. 网络和数据加密：容器之间的通信不能是明晃晃的裸聊
网络层面的安全问题，往往要等到多容器协作时才显形。比如你用docker-compose同时部署了MySQL、Redis和一个业务后端，如果所有服务都暴露在宿主机网络上，或者容器之间直接通过默认的bridge网络互连，那基本上就是内部服务在裸奔。
5.1 用户自定义bridge网络带来的安全收益
Docker的默认bridge网络（通常叫docker0），我在生产环境是明确建议不要用的。原因在于，默认bridge上的所有容器默认可以通过IP互相访问，而你很难搞清楚谁在跟谁通信。自定义bridge网络的价值不仅在于内嵌的DNS解析（可以用服务名直接互相访问），更在于它天然实现了网络隔离边界：
bash复制docker network create --driver bridge --internal backend-net
--internal参数能让这个网络彻底不连外网。如果你有一个只应该被内部服务访问的数据库容器，把它放在这种网络里，它连主动外联的能力都没有——即使某个容器内的恶意进程想向外传数据，这一步也能拦下来。
一个典型的网络拓扑设计是分成三层：
frontend-net：接收外部流量的Web容器backend-net：内部业务逻辑容器data-net：数据库容器，只允许同网络的backend访问
通过--network参数把不同服务挂到对应网络，容器间的通信关系就变得清晰可控了。
5.2 端口映射的原则：少暴露、不贪方便
"把所有端口都映射到宿主机"是我见过最多的操作习惯。Redis 6379、MySQL 3306，唰唰唰全-P暴露出来，表面上是为了方便管理，实际上等于把内部服务直接捅到了网络上。
安全的端口映射原则很简单：只要宿主机本地或内网其他机器需要访问的，才映射；只被其他容器访问的，不要映射。 如果确实需要对外提供MySQL或Redis访问，至少做到：
- 监听地址不要用
0.0.0.0，只绑定内网IP，即-p 192.168.x.x:3306:3306 - 对公网环境，在云安全组中另外限制来源IP
- 服务端开启认证并设置强密码，Redis这类默认无认证的服务尤其要小心
5.3 数据落盘加密与敏感配置管理
容器本身是"飞"的，数据是"落"的。如果你存储的卷没有加密，一旦宿主机磁盘被脱走，数据就直接暴露了。Docker原生支持加密卷驱动，但大多数自建环境不具备这个条件。退而求其次，我建议：
- 宿主机层面，对包含Docker数据目录的分区做LUKS全盘加密或云盘加密。
- 容器内部不需要落盘保存的敏感数据，尽量用环境变量或Docker Secret注入。
- 使用Docker Compose时，敏感信息放到
.env文件并加入.gitignore，不要提交进Git仓库，也可以借助docker compose config命令在部署前检查最终解析出来的配置里有没有意外泄露。
网络传输方面，现在很多企业内部链路都是TLS，但容器与容器之间的HTTP通信往往是明文。理想状态当然是所有服务间通信都启用TLS/mTLS，如果暂时做不到，至少保证任何跨界（跨主机、跨公网）的数据都是加密的。Docker内置的Swarm模式虽然当前热度不高，但它的secret管理机制仍然值得借鉴：secret在存储和传输时都会被加密，只在容器启动时以内存文件系统的方式挂载给指定的服务容器。
6. 结合真实应用场景的安全基线清单
最后，我把前面所有内容浓缩成一套可以直接照着执行的行动清单。这套清单不只适用于通用Docker环境，我还专门结合热点词里大家真正在用的场景（Docker安装MySQL 8.0、Redis主从、青龙面板、DVWA靶场、Compose部署）给出具体建议。
6.1 MySQL与Redis容器的安全底线
MySQL容器部署时，除了设置强密码环境变量MYSQL_ROOT_PASSWORD之外，我强烈建议你显式指定数据卷路径、不要用容器默认的匿名卷。同时，在配置中加上：
yaml复制mysql:
image: mysql:8.0.39
command:
- --default-authentication-plugin=caching_sha2_password
environment:
MYSQL_ROOT_PASSWORD_FILE: /run/secrets/db_root_password
secrets:
- db_root_password
volumes:
- mysql-data:/var/lib/mysql
networks:
- backend-net
Redis主从场景的热度很高，但Redis的安全配置经常被忽略。基本的几点：不要使用默认端口不设密码就跑，在redis.conf里开启requirepass、bind 127.0.0.1或指定内网IP、关闭CONFIG命令的远程调用（rename-command CONFIG ""），强烈建议不要用root跑redis容器，--user参数指定一个低权限用户。
6.2 青龙面板这类长期挂机服务的容器权限收口
青龙面板跑脚本要频繁操作依赖、执行命令，很多相关教程为了让脚本跑得顺，直接给出--privileged这种极宽权限的启动方式。坦白讲我看了直摇头。--privileged等于告诉内核"这个容器里的进程拥有所有能力"，它直接绕过了我之前讲的capabilities裁剪、只读文件系统、seccomp等所有运行时防护，相当于给自己开了一扇大门。
对这种"跑长期脚本服务"的需求，正确的姿势是：
- 不要使用
--privileged，改用--device只映射脚本真正需要的硬件设备 - 如果某些Python/Node依赖编译时需要特定文件系统特性，先试用
--cap-add=SYS_PTRACE这类最小化的能力补充，而不是直接ALL in - 把任务脚本和日志输出目录挂载到宿主机单独的数据目录，利用
--read-only配合--tmpfs给需要临时写入的路径留空间 - 定期更新镜像并保留更新前的镜像tag，方便出问题回滚
6.3 日常巡检的检查清单
就像车需要年检，Docker环境也需要一个可重复执行的巡检流程。我每两周会跑一轮下面这些检查：
bash复制# 1. 查看所有容器的运行状态与重启次数
docker ps -a --format "table {{.Names}}\t{{.Status}}"
# 2. 找出以root身份运行的容器
docker ps --quiet | xargs docker inspect --format '{{.Name}} {{.Config.User}}' | grep -v '1000\|appuser\|nobody'
# 3. 找出映射了0.0.0.0端口的容器
docker ps --format "table {{.Names}}\t{{.Ports}}" | grep 0.0.0.0
# 4. 检查是否有容器以privileged模式运行
docker ps --quiet | xargs docker inspect --format '{{.Name}} privileged={{.HostConfig.Privileged}}' | grep privileged=true
# 5. 检查docker.sock是否被挂载进容器
docker ps --quiet | xargs docker inspect --format '{{.Name}} {{.HostConfig.Binds}}' | grep docker.sock
# 6. 查看最近24小时内的容器日志异常行数（结合宿主机journalctl）
journalctl --since "24 hours ago" | grep -i docker | grep -i "error\|fail" | wc -l
这些命令都不需要额外安装任何工具，本质上是在回答几个核心问题：有没有容器脱离了我的安全基线？有没有权限异常放大？有没有不该暴露的网络入口？把巡检脚本化之后，你花10分钟就能完成一轮安全状态审计。
6.4 日志和审计：出了事你得能说清楚"发生了什么"
最后一环是审计能力。很多人的Docker环境出了问题，第一反应是重启容器，然后发现"无法复现"，其实是因为没有留证据。我建议至少在Docker daemon层面开启审计，在systemd层面执行：
bash复制sudo auditctl -w /var/lib/docker -k docker-data
sudo auditctl -w /etc/docker -k docker-config
同时，确保Docker容器的日志驱动设置为json-file或journald并配置轮转。在daemon.json里加上：
json复制{
"log-driver": "json-file",
"log-opts": {
"max-size": "10m",
"max-file": "5"
}
}
这行配置的目的有两个：一是防止某个容器疯狂打日志撑爆磁盘（前面主机数据盘独立挂载那里也提到过），二是保留足够多的历史日志方便事后追查。容器的标准输出日志默认情况下一旦容器被删除就没了，如果你对某个容器有更强的审计需求，可以把它的日志目录单独挂载持久化出来。
按这套清单走一遍之后，再回头看开头那些安装Docker、启动MySQL、部署青龙面板的场景，你会发现这些操作和安全的交集其实没那么复杂——不是要你成为安全专家，只要在每次执行docker run之前多问自己一句：这个容器现在拥有的权限，真的是它完成工作所必需的最小集合吗？如果答案不是，那就花几分钟做一次收口。我在实际维护中越来越觉得，Docker安全优化的核心不是什么奇技淫巧，而是把"最小权限、按需开放、持续审计"这几个朴素原则落实到每一条命令和每一份配置文件里。
最后再分享一个我踩过的坑，算是给你提个醒：有次我给一个容器加只读根文件系统时，数据库服务启动失败，排查了很久发现是镜像默认把数据目录建在了根文件系统下，而我只给/tmp和日志路径挂了tmpfs，忘了处理数据目录。不是所有镜像都遵循把数据放/var/lib的惯例，你在做安全加固的时候，一定要先摸清镜像内应用实际的读写路径，否则"加固"本身就会变成一次生产事故。先盘清楚应用的运行习惯，再动手裁剪权限，顺序不能反。