1. 事件复盘一条 compose 文件引发的整库失守1.1 攻击者眼中的送分题从端口扫描到弱口令登录我先说一个让人很无语又很真实的场景。新人拿到一台云服务器装好 Dockerdocker-compose.yml 里写了类似这样的内容services: db: image: mysql:8.0 container_name: mysql environment: MYSQL_ROOT_PASSWORD: root123456 ports: - 3306:3306然后自认为部署成功页面能跑起来就收工了。可这台机器只要绑定了公网 IP或者云厂商安全组把 3306 直接开放给了 0.0.0.0/0恭喜你的数据库已经从内部存储变成了公网资源。攻击者根本不需要什么高级手段。现在自动扫描工具一抓一大把先扫全网 IP 的 3306、5432、27017 这类高价值端口拿到开放列表后再用常见弱密码字典批量尝试登录。root/root、root/123456、admin/admin这种组合命中率远比想象中高。一旦登录成功攻击者做的第一件事不是马上拖数据而是先执行几条命令把权限和路径摸清楚SELECT user, host, authentication_string FROM mysql.user; SHOW DATABASES; SELECT table_schema, table_name FROM information_schema.tables WHERE table_schema NOT IN (mysql,sys,information_schema,performance_schema);确认有真实业务数据后接下来就是全库导出、清空表、留下勒索信或者直接打包转卖。你第一次发现不对劲大概率是收到一条消息你的数据库已经被我备份支付 X 个比特币恢复数据。 这时候再去后悔为什么当初图省事已经晚了。1.2 被忽略的两个致命细节公网端口映射 版本库公开很多新手想不通一个问题我明明设置了密码为什么还被爆破因为密码本身就是最弱的一环。root123456看起来够复杂但在字典库里顶多算入门级。更关键的是你以为密码是秘密其实它早就在你的 Git 仓库里躺了好几个月。这类事件还有个通病compose 文件往往不是只存在服务器上。教程会告诉你把项目推到 GitHub 方便多台机器部署于是带着数据库密码的docker-compose.yml连同.env文件一起被推到了公开仓库。现在各路爬虫和扫描器都在盯着 GitHub 上新增的代码片段只要检测到MYSQL_ROOT_PASSWORD或者POSTGRES_PASSWORD这类关键字瞬间就会被收录进社工库。所以这根本不是黑客有多牛的问题而是你把数据库的钥匙挂在了大门口还顺手把门打开了。即使你不在公网端口暴露只要代码仓库泄露攻击者照样可以拿着密码连到你的数据库因为你的安全组规则可能允许某个跳板机的 IP 访问而跳板机本身防护孱弱。1.3 脱库之后才发现备份、审计日志全都没有更扎心的是被拖库的这批项目绝大多数连最基础的备份策略都没做。MySQL 容器里的数据目录是挂载在宿主机磁盘但没人做 mysqldump 定时任务也没人开启 binlog 日志。等到数据被删光想恢复只能从磁盘层面找数据碎片成本极高。审计日志也是空白。默认情况下 MySQL 不记录谁在什么时候执行了什么 SQL攻击者拖库时你根本无从追踪事后想查 IP 来源也只能看到容器宿主机的连接来源。平时省下的那几分钟配置时间到这时候要付出几百倍的代价去偿还。2. 明文密码为什么在 Compose 项目里格外危险技术层面的三重泄漏路径2.1 environment 字段会把密码直接写进容器元数据很多开发者以为 compose 文件里的environment是临时环境变量容器删了就不存在。这个认知大错特错。Compose 在创建容器时会把环境变量写入容器配置中。你随时可以用一条命令看到明文docker inspect mysql | grep -i password或者更直接docker inspect mysql --format {{.Config.Env}}输出结果里明晃晃地列着MYSQL_ROOT_PASSWORD: root123456。这意味着所有能执行docker inspect的人、所有能访问 Docker API 的程序都能拿到你的数据库密码。如果服务器上还跑着一些 Web 管理面板面板的漏洞就可能变成数据库密码的泄漏点。容器停止、删除也不会让密码自动消失。Docker 的 overlay2 文件系统层、containerd 的元数据、一些监控 agent 采集到的 container 信息都可能在磁盘上留下痕迹。你以为删了重来就干净了实际上密码文件早就散落在宿主机各个目录里。2.2 镜像 ENV 层docker history 能翻出历史密码比docker inspect更隐蔽的是镜像层。如果你在 Dockerfile 里写过ENV MYSQL_ROOT_PASSWORDroot123456 CMD [mysqld]或者用docker commit把运行中的容器提交成镜像这个密码会作为镜像层的一部分永久留存。后续任何人都可以拉取这个镜像然后执行docker history your-image:latest --no-truncDockerfile 里的 ENV 指令会原封不动地出现在每一层的历史记录里。就算你后来在 Dockerfile 里改掉了密码再重新 build只要旧镜像没有被彻底删除、没有从仓库中清理密码依然存在于远端的镜像 Registry 中。这个问题在团队协作里特别容易爆雷。有人图省事把编写中的镜像推到公司私有仓库后来项目不做了镜像却没删。若干个月后安全扫描发现仓库里有个带明文密码的镜像攻击者拿到这个镜像就能反向推导出线上数据库的登录凭据。因为人都有惰性一个密码用多个环境是常态。2.3 团队协作和 Git 历史密码一旦提交就再也删不干净先说一个结论只要密码进过 Git 历史它就已经算泄漏了。哪怕你立刻修改 docker-compose.yml把密码删掉再提交一次只要旧的 commit 还存在于.git目录或者远程仓库的 reflog 中任何拿到仓库权限的人都能通过git log --all -p -- docker-compose.yml翻出那行明文密码。Git 设计的初衷是记录历史它不会因为你的新提交而自动遗忘旧的敏感信息。更别提 GitHub 上有专门扫描密钥的机器人比如 trufflehog、gitleaks它们会把历史 commit 里的 password 字段自动识别并上报到公开数据集。我有一次帮朋友做代码审计在 GitHub 上搜一个项目的名称结果发现这个项目三年前的 commit 里就有一条数据库连接串里面写着jdbc:mysql://10.0.0.8:3306/appdb?userrootpasswordFoobar123而这个项目现在还在用同一套密码连接生产库。看到那一刻我头皮发麻——这不是技术能力的缺失是安全意识完全不在线。3. 用 Docker Secrets 替代环境变量一条 compose 就能落地的安全改造3.1 理解 Docker Secrets 的权限模型和挂载方式既然环境变量这么不靠谱Docker 官方也给过标准答案Secrets。先说清楚一个概念Docker Secrets 最初是 Swarm 模式下的功能但 Compose V2 规范也已经支持所以单机部署同样可以用。它的核心逻辑是把敏感信息从容器配置与镜像层中剥离出来通过临时文件系统挂载到容器内部的一个只读路径中通常是/run/secrets/。与environment相比Secrets 有几个明显的优势不会出现在docker inspect输出的 Config.Env 里不会被docker history捕捉到容器内程序以读文件的方式获取密钥降低环境变量泄漏的风险更新 secret 时可以重新部署服务让容器读取到新的值而不需要重建镜像要特别注意的是Compose 单机模式下使用 secrets 的语法和 Swarm 略有区别单机模式必须使用file:类型声明 secret 的内容来源Swarm 模式则可以使用外部 secretexternal: true由 Swarm 管理。下面我会给出一个可以直接套用的 Compose 配置。3.2 单机 Compose 使用 file 类型 secret 的完整配置先准备密码文件mkdir -p secrets # 生成随机密码不包含特殊符号避免歧义 openssl rand -base64 32 secrets/mysql_root_password.txt chmod 600 secrets/mysql_root_password.txt然后编写 docker-compose.ymlservices: db: image: mysql:8.0 container_name: mysql restart: always secrets: - mysql_root_password environment: MYSQL_ROOT_PASSWORD_FILE: /run/secrets/mysql_root_password ports: # 只绑定到本机回环地址不暴露公网 - 127.0.0.1:3306:3306 volumes: - mysql_data:/var/lib/mysql secrets: mysql_root_password: file: ./secrets/mysql_root_password.txt volumes: mysql_data:启动后MySQL 官方镜像会优先识别MYSQL_ROOT_PASSWORD_FILE变量从指定路径读取密码。如果你的镜像是任意自定义应用也可以在自己的启动脚本里读取/run/secrets/mysql_root_password文件的内容再传给应用。这里的关键点是chmod 600限制宿主机上的密码文件访问权限绑定127.0.0.1而不是0.0.0.0这样外部网络根本扫不到你的 3306 端口app 服务如果要连接数据库可以通过networks走容器网络完全不需要端口映射到宿主机如果你已经在跑一个现成的 Compose 项目改造时要额外注意数据库初始化目录。MySQL 镜像只有在数据目录为空时会执行环境变量初始化此时MYSQL_ROOT_PASSWORD_FILE会被读取并写入数据目录。如果数据目录已经有旧数据修改环境变量不会自动更新 root 密码。你需要手动登录数据库执行 ALTER USER 来同步新的密码或者干脆先处理数据迁移再重新初始化。3.3 Secret 文件本身的保护权限、加密与生命周期用上了 Secrets不代表万事大吉。secret 文件只解决了容器内部不暴露的问题宿主机上那个./secrets/mysql_root_password.txt仍然需要妥善保护。我见过不少这样的操作把 secrets 目录直接放到项目代码目录里然后整个项目推到 Git 仓库。这不等于没改吗正确做法是将secrets/目录写入.gitignore保证密码文件永远不会进入版本库宿主机上为 secrets 目录单独分配一个系统用户例如dockersecrets只有该用户和 root 可读定期轮换一个数据库密码用半年以上风险会直线上升。建议每 90 天换一次配合脚本自动更新 secret 文件并重启相关容器另外Compose 的 secret 文件内容也可能出现在/run/secrets挂载点中。容器一旦被攻击者拿到 shell他仍然可以读取这个文件。所以 Secrets 不是万能保险它防的是无意中泄漏防不了主动被读取。真正要做得更扎实还需要配合网络隔离、防火墙规则和数据库账号最小权限。4. 再进一步密码不上文件、不进容器也能管理4.1 外部密钥管理工具与动态注入如果项目跑在 Kubernetes 上或者你愿意多引入一点工具链可以考虑更彻底的方案让密码根本不以持久化文件的形式存在。外部密钥管理工具的思路是密钥存放在集中式服务里比如 HashiCorp Vault、云厂商 KMS/Secrets Manager应用启动时通过 API 获取密钥并缓存在内存中。容器内只有运行中的应用能拿到密钥连docker exec进入容器都看不到明文环境变量。举个例子使用 Vault Agent 可以给应用配置一个旁路进程应用启动前先访问 Vault 拉取数据库密码然后通过内存管道传给应用进程。这样即使有人拿到了容器镜像也只能看到一个空壳——密码根本不在镜像和文件系统里。对于国内云环境更常见的做法是直接把密码放在云厂商的 Secrets Manager 中应用通过 SDK 拉取。代价是需要改造应用的配置加载逻辑很多旧项目不愿意动这一层所以这个方案更适合新项目或者运维能力较强的团队。我个人建议如果你只是部署一个中小型项目用前面提到的 Compose file secrets 已经足够不必为了追求绝对安全把所有业务代码都绕一遍。安全是分层的每一层做到及格整体就能达到较高水平。4.2 数据库侧的高危配置整改从强密码到来源 IP 白名单即使你在 Compose 层做得再完美数据库本身如果不做限制等于白干。首先是强密码策略。像root这类超级账号应该用至少 24 位随机字符字母大小写、数字、特殊符号混排。可以这样生成openssl rand -base64 24其次是账号白名单。MySQL 用户表里的host字段决定了这个账号允许从哪些 IP 登录。在生产环境建议为业务单独创建账号而不是直接用 rootCREATE USER app172.20.0.% IDENTIFIED BY random-strong-password; GRANT SELECT, INSERT, UPDATE, DELETE ON appdb.* TO app172.20.0.%; FLUSH PRIVILEGES;这样即使密码被泄漏攻击者也只能在 Docker 内部网络网段内使用外部网络连接会被 MySQL 直接拒绝。网络层也要跟上。从宿主机层面用 iptables 或云安全组限制 3306 端口的来源 IP只允许自己办公网 IP 访问。如果你只是让应用容器连接数据库那这个端口根本不需要映射到宿主机直接在 Compose 内部网络里用服务名访问就够。还有一点新手经常忽略MySQL 的 bind-address。如果你只是在容器里运行 MySQL默认绑定的可能是0.0.0.0配合宿主机端口映射后公网就能访问。把映射改为127.0.0.1:3306:3306后公网访问被挡在宿主机外安全性提升非常明显。4.3 数据兜底能力建设自动备份、恢复演练与日志审计讲完防泄漏还得做好兜底防止防住了外部攻击者却没防住自己误删数据。数据库备份至少要分成两级固定时间全量备份每天凌晨用 mysqldump 或 Percona XtraBackup 备份保留近 7 天binlog 增量日志开启 MySQL binlog并确保 binlog 文件不会被容器重启清空定时备份的脚本可以放在宿主机 cron 里也可以塞到同一个 Compose 项目中作为 service 运行。比如0 2 * * * docker exec mysql sh -c exec mysqldump -uroot -p$MYSQL_ROOT_PASSWORD --all-databases /backup/all_date %F.sql注意$MYSQL_ROOT_PASSWORD是容器内的环境变量这在执行备份的瞬间会短暂存在于进程列表中严格来说不算绝对干净。更稳妥的是让 mysqldump 直接使用/run/secrets/中的密码文件0 2 * * * docker exec mysql sh -c mysqldump -uroot -p$(cat /run/secrets/mysql_root_password) --all-databases /backup/all_date %F.sql恢复演练也要定期做。很多团队备份了但从来没恢复过真出事时才发现备份文件损坏、恢复流程走不通。建议每季度在测试环境完整模拟一次从零搭建数据库 导入备份 校验数据条数的过程。日志审计方面MySQL 的慢查询日志和通用日志默认不开启但业务数据敏感时建议至少开启通用日志并让日志落到宿主机持久化目录防止容器销毁后日志跟着消失。通过分析通用日志可以看到哪个 IP 在什么时间执行过什么 SQL虽然无法完全拦截攻击但能为应急响应提供线索。5. 一份可以直接抄作业的 Compose 安全基线模板5.1 安全版 docker-compose.yml 示例下面这个模板是我现在所有新项目都会用的基础结构好坏不说至少能让新手少走很多弯路services: db: image: mysql:8.0 restart: always secrets: - db_root_password - db_app_password environment: MYSQL_ROOT_PASSWORD_FILE: /run/secrets/db_root_password MYSQL_DATABASE: appdb MYSQL_USER: app MYSQL_PASSWORD_FILE: /run/secrets/db_app_password volumes: - mysql_data:/var/lib/mysql - ./backup:/backup networks: - internal # 不把 3306 暴露到宿主机只有同网络的 app 服务能访问 app: build: . restart: always secrets: - db_app_password environment: DB_HOST: db DB_NAME: appdb DB_USER: app DB_PASSWORD_FILE: /run/secrets/db_app_password networks: - internal secrets: db_root_password: file: ./secrets/db_root_password.txt db_app_password: file: ./secrets/db_app_password.txt volumes: mysql_data: networks: internal: driver: bridge这个模板的特点数据库端口不映射到宿主机外部完全不可达app 服务通过 Docker 内部网络访问数据库连接信息中无明文密码root 和业务账号分离业务账号只有appdb的增删改查权限备份目录以只读卷挂载到宿主机方便定时备份如果你确实需要通过宿主机的 3306 维护数据库请务必映射到回环地址127.0.0.1:3306:3306并且配合 SSH 隧道或者其他运维通道访问不要直接暴露到公网。5.2 上线前逐项自查清单列一份我每次上线前都会过一遍的检查项每一条都对应真实的翻车案例检查项危险操作推荐做法端口映射3306:3306直接暴露公网只映射127.0.0.1:3306:3306或不映射数据库账号容器内使用 root 连接业务库单独创建最小权限业务账号密码存储使用MYSQL_ROOT_PASSWORD环境变量使用MYSQL_ROOT_PASSWORD_FILE secrets密码文件secrets 文件被 Git 跟踪加入.gitignore设置chmod 600镜像层在 Dockerfile 中写 ENV 密码使用 entrypoint 从/run/secrets读取备份策略没有定时备份每天全量 binlog 增量定期恢复演练网络隔离所有容器在默认桥接网络互相可见按服务拆分网络只暴露必要端口日志审计不开启 MySQL 通用日志开启通用日志日志持久化到宿主机这些条目看着简单但真到线上环境每一项都有人踩过坑。我之前接手过一个项目数据库端口映射到公网业务账号权限是ALL PRIVILEGES ON *.*密码是Admin123还完整地写在 GitHub 公开仓库里。四重雷区叠满一周之后就被脱库客户数据在暗网被售卖。你说技术难吗一点都不难全是基础安全意识问题。5.3 真出事的时候按这个顺序处理哪怕前面全部做了谁也不敢保证 100% 不出事。万一发现数据库被入侵别慌按下面的顺序处理能把损失降到最低先断网再排查。像 MySQL 这种数据库第一件事是切断可能的外网访问立刻在云控制台把安全组入方向规则清空或者在宿主机上执行iptables -I INPUT -p tcp --dport 3306 -j DROP先阻断攻击者的持续访问再登录容器取证。保留现场。不要急着删容器先把容器里与攻击相关的日志、连接记录、数据库 binlog 复制出来。用docker logs mysql和docker inspect收集信息这些是后续追查漏洞来源的重要依据。分析入侵路径。定位到攻击入口后修改所有相关密码包括数据库密码、服务器密码、云平台密钥。注意如果服务器被拿到 shell光改数据库密码不够服务进程可能已经被植入后门必要时需重装系统。恢复数据。从最近的备份中恢复业务数据如果备份时间点距离现在较远还需要结合 binlog 做增量回放。务必先在测试环境验证恢复流程不要直接在线上操作。通知相关方。如果是涉及用户数据的项目按照合规要求尽快通知用户和管理方。这一步拖得越久后续的法律和舆情风险越大。我见过最糟糕的应急响应是发现数据库被删后管理员自己默默重启了容器然后用一键脚本重新执行了建表 SQL。结果不仅数据没找回来连攻击者的 IP 都没留下任何记录最后只能吃哑巴亏。所以应急响应里第一时间保留证据永远比急着恢复业务更重要。6. 写在最后关于这条坑我的一点真实体会大多数踩了这条坑的人不是技术不行而是太相信默认配置。默认端口、默认账号、默认密码看起来能用就万事大吉。但安全不是能用就行它是在每一次配置之前多问一句如果这个密码现在被别人看到会发生什么Docker Compose 本身是个好工具它把部署流程标准化让应用可以在不同环境之间快速迁移。但标准化也意味着它容易让人产生惰性开发环境怎么写的测试环境怎么写的生产环境就原样照搬。于是明文密码跟着 compose 文件一起传播成了 Docker 新手最经典的翻车原因。我的建议很简单从今天开始把你项目里的所有environment密码字段改成_FILE结尾的环境变量配合 Compose secrets 读取文件内容。这个改造耗时不超过半小时但它能堵住 80% 以上的密码泄漏路径。剩下那 20%靠网络隔离、备份和审计日志去补。等你在生产环境吃过一次亏后再回头看我这篇文章你一定会觉得这些工作真的一条都不能省。