多架构镜像的权限边界:三个最危险的默认值
ARM 基础镜像的 tag 与 amd64 不一定同步,有的版本只发了单架构
最小权限不是一句口号,是三个具体动作:降权运行、限定目录、收敛网络。
先说结论
把「它能碰到什么」缩到最小,剩下的漏洞才谈得上「影响有限」。
- 用独立低权限账号运行,别用 root
- 数据目录 750,含密钥的配置 600
- 只监听需要的地址,管理端口不对外
- 凭据不写进镜像与仓库
- 定期核对权限,别让临时改动留下来
三个默认值
这三个是审计里出现频率最高的:
- 以 root 运行:一个 RCE 就是整机失守
- 监听 0.0.0.0:管理接口直接暴露在公网
- 目录 777:任何进程都能改配置和数据库
怎么改
多平台镜像是一个 manifest list,docker pull 时按本机架构自动选。
| 项目 | 默认 | 建议 |
|---|---|---|
| 运行身份 | root | 专用账号,无登录 shell |
| 数据目录 | 755/777 | 750,属主为服务账号 |
| 配置文件 | 644 | 600(含密钥时) |
| 监听地址 | 0.0.0.0 | 127.0.0.1 或内网 |
| 容器权限 | 默认 | 只读根文件系统 + 去 capabilities |
这个服务的几个安全事实
和它自身机制相关的权限细节:
- QEMU 模拟下编译型项目慢 5-20 倍,Go 交叉编译反而是最快的路
- --load 只能导入当前架构,多平台构建必须 --push 到仓库
- ARM 基础镜像的 tag 与 amd64 不一定同步,有的版本只发了单架构

凭据怎么放
--load 只能导入当前架构,多平台构建必须 --push 到仓库。
能不用密码就不用:密钥、短期令牌、专用账号,三层叠加最省心。
自查清单
每月花十分钟做一遍:确认运行身份、检查监听端口、复核目录权限、清理临时账号、确认备份可恢复。
还有几处容易忽略的
都是小地方,但出问题时往往就卡在这里。
- buildx 的默认 builder 不支持多平台,要先 buildx create --use 建一个
- docker manifest inspect 可以直接看某个 tag 有没有 arm64,不必先拉取
- 在 x86 机器上直接 build,推到 ARM 服务器上 exec format error
- 用 --load 构建多平台,报 exporter 不支持多平台输出
- 指望 QEMU 跑 CI,一次构建从 6 分钟变成 40 分钟
权限给多了不会立刻出事,但出事的时候一定是因为它。
评论 (3)
「先看日志再猜」这句话值一篇文。
备份没验证过等于没有,这条我认。
最小可用配置这个说法很好,先跑起来再优化。
发表评论