阿里云容器服务镜像签名：让每一次部署都更安全、更可信

你有没有遇到过这种情况——辛辛苦苦写完代码，打包成镜像推到容器平台，结果上线后突然发现服务异常？查来查去，最后发现问题竟然是因为某个中间件的镜像被替换了，不是你原本信任的那个版本。这种“被劫持”的感觉，真的太糟心了。

其实，在现代云原生开发中，镜像安全是个特别容易被忽略但又极其关键的一环。尤其是在使用 Kubernetes 或阿里云容器服务（ACK）这类平台时，每天可能要拉取几十甚至上百个镜像。如果这些镜像没有经过验证，谁敢保证它们没被篡改过？这时候，镜像签名就派上大用场了。

今天咱们就来聊聊阿里云容器服务里的一个超实用功能——镜像签名。它不只是个技术名词，而是实实在在帮你守住应用安全大门的“守门员”。

什么是镜像签名？简单说就是给你的镜像贴上“防伪标签”

你可以把镜像想象成一瓶药。药厂生产出来以后，如果包装上没有封条、没有批号，你在药店买回来也不敢随便吃，对吧？因为你不知道这瓶药是不是正品，有没有被掉包。

镜像也是一样。你从镜像仓库拉下来的 Docker 镜像，本质上就是一个“软件包”。如果没有签名机制，你就没法确认这个镜像到底是谁构建的、有没有被中间人篡改过。

而镜像签名，就是给这个“药瓶”加上一个数字封条。只有持有对应私钥的人才能“封瓶”，而系统在运行前会自动“验封”——这就是所谓的“签名校验”。

阿里云是怎么实现镜像签名的？

阿里云容器镜像服务（ACR）支持基于 Notary 的镜像签名机制，这套体系源自 Docker 的开源项目，现在已经被广泛应用于企业级安全场景。

具体流程是这样的：

• 开发者在本地构建完镜像后，使用自己的私钥对镜像进行签名；
• 签名后的镜像推送到阿里云 ACR 时，系统会自动记录这个签名信息；
• 当你在 ACK 集群中部署这个镜像时，可以配置策略要求“只允许运行已签名的镜像”；
• 如果镜像没签名，或者签名无效，Kubernetes 就会直接拒绝拉取和启动。

这样一来，哪怕有人黑进了你的镜像仓库，往里面塞了个恶意镜像，只要他没有你的私钥，就无法伪造签名，系统照样不会让它跑起来。

为什么你需要开启镜像签名？

别觉得这是大公司才需要的功能。哪怕你现在只是个人开发者，或者小团队在跑项目，安全这根弦也不能松。尤其是当你开始接入 CI/CD 流水线、自动化发布的时候，风险只会越来越大。

举个例子：你有个 Jenkins 自动构建任务，每次提交代码就自动打包推镜像。但如果某天黑客通过漏洞往你的 Git 仓库提交了一个恶意 Dockerfile，构建出来的镜像看起来版本号一样，但里面偷偷加了挖矿程序……你怎么办？

有了镜像签名，这个问题就好办多了。你可以在流水线最后一步加上签名操作，而在生产集群里设置“强制校验签名”。这样，即使恶意镜像被推上去了，它没有合法签名，根本就不会被调度运行。

手把手教你：如何在阿里云上开启镜像签名

别被听起来高大上的名字吓到，其实配置过程并不复杂。下面我带你一步步走一遍。

第一步：开通镜像签名功能

登录阿里云控制台，进入【容器镜像服务 ACR】→【实例列表】→选择你的企业版实例（注意：个人版不支持签名功能）→ 在左侧菜单找到“镜像签名”并开启。

系统会提示你创建一个密钥对，或者导入已有的 GPG 密钥。建议你本地生成一对新的密钥，妥善保管私钥，公钥上传到阿里云。

第二步：本地安装 notary 客户端

你需要在构建机器上安装 notary 工具。可以通过官方 GitHub 下载二进制包，也可以用 Homebrew（Mac）或 apt（Linux）安装。

安装完成后，执行：

notary -s https://notary.acr.aliyuncs.com init my-repo

这会初始化本地签名环境，并关联到你的 ACR 仓库。

第三步：构建并签名镜像

假设你已经 build 好了一个镜像：

docker build -t registry.cn-hangzhou.aliyuncs.com/your-namespace/app:v1.0 .

接下来推送到 ACR：

docker push registry.cn-hangzhou.aliyuncs.com/your-namespace/app:v1.0

推送成功后，使用 notary 进行签名：

notary -s https://notary.acr.aliyuncs.com sign your-namespace/app:v1.0 --key your-key-name

搞定！这时你的镜像就已经被打上了数字签名，其他人可以通过公钥验证其来源。

第四步：在 ACK 集群中启用签名校验

这才是最关键的一步。光有签名没用，必须让运行时去检查它。

你可以在 ACK 集群的节点上配置 Image Admission Controller，或者使用 OPA Gatekeeper 这类策略引擎，定义一条规则：“所有待拉取的镜像必须在 ACR 中有有效签名”。

一旦违反规则，Pod 创建就会被拦截，事件日志里会清楚写着：“镜像未签名，拒绝启动”。

实际应用场景：谁最该用这个功能？

说实话，几乎所有的生产环境都应该考虑启用镜像签名。但以下几个场景尤其推荐：

• 金融、医疗等强合规行业：监管明确要求软件供应链可追溯，镜像签名是满足审计要求的重要一环；
• 多团队协作的大项目：不同小组各自发布镜像，必须确保彼此信任的基础；
• 使用第三方镜像的场景：比如你用了某个开源项目的镜像，但不确定是否被篡改，可以通过签名验证官方出品；
• CI/CD 全自动发布流程：越自动化，越需要安全兜底机制，防止“一键发布”变成“一键中毒”。

常见问题 & 注意事项

我知道你可能会担心几个问题，我提前给你解答一下：

Q：私钥丢了怎么办？

A：千万别丢！私钥一旦丢失，你就不能再为旧版本镜像生成新签名。建议将私钥加密后存入密码管理器，或使用硬件安全模块（HSM）保护。

Q：签名会影响部署速度吗？

A：基本不影响。签名校验是在调度阶段完成的，耗时很短。而且你可以缓存公钥，进一步提升效率。

Q：能不能只给部分关键服务签名？

A：当然可以。你可以按命名空间或标签设置策略，比如只对 production 环境的镜像强制校验，dev 环境则放宽限制。

结语：安全不是成本，而是投资

很多人觉得安全功能“麻烦”、“没必要”，直到出了事才后悔莫及。但现实是，一次严重的安全事件，可能让你几个月的努力付诸东流，甚至影响公司声誉。

而像镜像签名这样的功能，前期花一点时间配置，后期就能省下无数排查问题的时间。它不像监控那样能直接看到收益，但它就像保险，平时感觉不到存在，关键时刻能救命。

如果你正在用阿里云容器服务，或者打算上云，强烈建议你尽快把镜像签名用起来。不仅是为了合规，更是为了对自己负责。

顺便提一句，阿里云现在对新用户有很多优惠政策。如果你想试试 ACR 企业版或者其他云产品，不妨先领张阿里云优惠券，能省不少钱。毕竟，省钱和安全，从来都不是单选题。

最后想说，技术一直在进步，我们的安全意识也得跟上。别等到出事了才想起加固防线。从今天开始，给你的每一个镜像都加上那道“数字封条”，让每一次部署都更安心、更可信。