公司新上的微服务系统跑得挺顺，结果某天突然整个应用瘫痪。排查半天才发现，罪魁祸首是一个内部使用的容器镜像——被偷偷塞进了恶意脚本。问题根源？权限没管住，谁都能往镜像仓库推东西。
镜像不是大锅饭，不能谁想用就用
很多人觉得，开发团队共用一个私有镜像仓库挺方便，拉取、推送一路绿灯。可现实是，权限一旦放开，风险就藏在下一个提交里。比如实习生误操作覆盖了生产镜像，或者离职员工顺手带走镜像权限继续访问，这些都不是危言耸听。
更常见的情况是，某个开发为了省事，在基础镜像里硬编码了数据库密码，然后把镜像推到了公共可读的仓库。扫描工具一跑，密钥明晃晃躺在那里，等于把家门钥匙贴在楼道公告栏。
最小权限原则得落到实处
和操作系统用户权限一样，镜像管理也得讲究“够用就行”。研发人员不需要推送权限时，就只给拉取；CI/CD 流水线只需要拉指定标签，那就别给 *:* 的通配权限。
以 Harbor 为例，可以按项目划分角色：
{
"project": "app-core",
"roles": [
{
"user": "dev-alice",
"role": "developer",
"permissions": ["pull", "comment"]
},
{
"user": "ci-runner",
"role": "admin",
"permissions": ["push", "pull", "delete"]
}
]
}这种配置方式能避免人为失误导致的镜像污染，也能限制自动化流程的破坏范围。
签名验证：确认镜像是“本人发布”
光控制谁能推还不够，还得确认推上去的内容可信。就像快递收货要核对身份，Kubernetes 集群在拉镜像前，也可以要求镜像必须经过数字签名。
Docker Content Trust（DCT）就是干这事儿的。开启后，只有用授权密钥签名的镜像才能被 pull 或 run。配置环境变量就行：
export DOCKER_CONTENT_TRUST=1这时候如果尝试运行一个未签名的镜像，Docker 会直接拒绝：
Error: remote trust data does not exist for docker.io/library/untrusted-image虽然增加了流程复杂度，但在金融、政务这类场景里，这点麻烦换来的安全值得。
定期审计，别等出事才翻记录
权限设置不是一劳永逸。人员变动、项目交接、临时授权忘记回收，都是隐患。建议每月跑一次权限清单，看看哪些账号还挂着不必要的角色。
同时结合日志分析，比如谁在非工作时间推送了镜像，哪个IP地址频繁拉取敏感项目的镜像。这些异常行为可能就是入侵前兆。
容器时代，镜像就是软件的“出厂包装”。包装过程没人盯着，内容指不定变成啥样。管好权限，不是增加负担，而是给交付链上一把锁。