多架构镜像的权限边界:三个最危险的默认值

Docker · 3 分钟阅读· 319 次阅读

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)

南
南风

「先看日志再猜」这句话值一篇文。

老
老吴

备份没验证过等于没有,这条我认。

L
lin

最小可用配置这个说法很好,先跑起来再优化。

发表评论

验证码

提交后需站长审核,通过后才会显示。