一个链接就能换走云上临时凭据：元数据服务的两道锁

## 一、链路是怎么被打开的

云主机和容器里有一个约定俗成的地址：169.254.169.254。云厂商的元数据服务通过它返回实例 ID、可用区、网络配置，以及绑定在该实例上的角色临时凭据。应用要用对象存储、要读配置，通常就是从这里取的。便利的另一面是：任何能让服务器发起请求的入口，都可能成为读取这份凭据的入口。

常见入口是 SSRF。图片转码、网页抓取、Webhook 回调、PDF 预览这类功能，都会替用户去访问一个 URL。如果参数没有做目标地址校验，攻击者传入内网地址，服务器就会带着自己的身份去请求，再把结果原样返回。2019 年 Capital One 的数据泄露就是这条链路：一个配置存在缺陷的代理服务被诱导访问元数据接口，拿到临时凭据后读取了大量对象存储数据。

## 二、临时凭据为什么更麻烦

很多人以为临时凭据有效期只有几十分钟，风险天然可控。实际并非如此。凭据本身是短时的，但它对应的角色权限可能是长期的；攻击者拿到凭据的第一件事往往是调用角色接口，确认能访问哪些资源，再用它创建新的访问密钥、修改桶策略或部署后门。短有效期只是缩短了窗口，并不能阻止横向移动。

更麻烦的是这类访问在日志里看起来"合法"：请求确实由实例角色发起，来源 IP 也在内网，如果没有专门的检测规则，很难与正常的自动化任务区分开。

## 三、第一道锁：把 GET 换成 PUT

最直接的加固是强制启用元数据服务的增强版本（IMDSv2）。它要求客户端先用 PUT 请求换取一个会话令牌，再带着令牌发起查询，且令牌有有效期、绑定会话。SSRF 通常只能发简单的 GET 请求，无法完成这套握手，链路在第一步就断了。开启方式不必一步到位：可以先设为可选，观察一段时间确认没有旧版本依赖，再切换到强制模式，避免一次性打断存量镜像里的初始化脚本。

配套参数是令牌的跳数限制（hop limit）。默认值允许请求经过一层代理转发，容器网络里这层转发恰恰是风险来源。把跳数限制设为 1，可以阻止元数据请求穿过额外的代理层。

## 四、第二道锁：网络与容器边界

元数据地址属于链路本地网段，很多云环境允许实例内部自由访问。可以在主机防火墙上显式放行必要的元数据流量，其余来源一律拒绝；在容器集群里，则通过网络策略禁止业务 Pod 访问该地址，只允许真正需要的组件访问。需要凭据的工作负载，改用工作负载身份（例如基于 OIDC 的服务账号角色），让凭据按 Pod 绑定，而不是整个节点共享一份。

节点级角色的另一个隐患是权限泛化：一台节点上跑几十个 Pod，任何一个被攻破都能拿到同一份角色权限。按工作负载拆分角色，即使某个服务被拿下，能触碰的资源也有限。

## 五、把异常访问变成可见信号

最后需要可见性。值得配置告警的行为包括：非常规进程访问元数据接口、短时间内大量凭据换取、凭据被用于从未出现过的地域或新接口、角色策略在非变更窗口被修改。把元数据访问日志和 IAM 调用日志放在一起看，往往能还原出完整攻击路径。

元数据服务本身没有错，它把凭据从配置文件里拿了出来，其实是安全性的进步。风险在于它默认对实例内的一切请求敞开。加上强制令牌、收紧网络边界、按工作负载授权这三步，这条最容易被忽视的链路才算真正关上。

标签：云安全、SSRF、元数据服务、临时凭据、最小权限