云主机元数据服务访问风险，防止Agent
云主机元数据服务是云厂商提供给每台云服务器的内置接口，通常通过 http://169.254.169.254/latest/meta-data/ 访问。
它返回实例ID、公网IP、临时密钥等信息。
如果服务器上运行的Agent存在SSRF（服务端请求伪造）漏洞，攻击者就能让Agent访问这个内网地址，从而窃取云密钥并进一步控制你的云资源。
本文针对云主机元数据服务访问风险，给出防止Agent SSRF窃取云密钥的具体加固步骤，全程按零基础可操作的标准来写。
先确认风险点：为什么元数据服务会被SSRF盯上
SSRF的意思是服务端接收了用户提供的URL后，主动去请求这个地址。
很多Web应用会抓取远程图片、生成预览、校验URL，一旦没有严格过滤，就能让服务器去访问 169.254.169.254。
元数据服务为了性能，默认只校验来源IP是本机，并没有校验访问意图。
于是攻击者只要让服务器发起一个到这里任意路径的请求，就能拿到临时密钥，进而调用云API、读取对象存储、创建后门等。
加固前准备：收集账号权限与登录方式
操作前确认三件事：
- 你有该云主机的登录权限，能执行命令行或使用云厂商控制台。
- 你拥有修改云主机的IAM角色、安全组或元数据选项的权限。
- 确认云厂商名称。不同云厂商的入口不同，本文以主流云厂商控制台为例，具体按钮名称以实际控制台显示为准。
核心操作：启用强制令牌模式并限制元数据访问
第一步：检查当前元数据服务是否可被直接访问
登录云主机，执行：
curl -s http://169.254.169.254/latest/meta-data/iam/security-credentials/如果返回角色名称或密钥信息，说明当前处于明文访问模式，风险较高。
如果返回 404 或空白，说明该路径可能被虚机系统屏蔽，但也要继续做加固。
第二步：启用IMDSv2（强制使用会话令牌）
主流云厂商都支持IMDSv2，它的核心是：请求先获取一个带有效期的 X-aws-ec2-metadata-token，再携带这个Token访问元数据。
SSRF通常无法完成两次独立请求，所以这道防线能有效拦住。
在阿里云中，找到实例的“元数据中心”或“实例元数据选项”，将访问模式改为“强制使用令牌模式”。
在AWS控制台中，选中实例后点击“操作 → 实例设置 → 修改元数据选项”，将“元数据版本”改为“V2 only（仅限令牌）”，并设置“允许的HTTP PUT响应跳数”为1。
腾讯云控制台也提供类似开关，建议在实例的“安全设置”里开启“元数据服务安全加固”。
第三步：用安全组限制元数据服务的上游来源
如果服务器所在的VPC支持对 169.254.169.254 单独下发安全组规则，也可以显式拒绝来自网络其他位置的访问。
但大多数VPC中，元数据服务不允许被安全组直接匹配。
更通用的做法是把Web应用和敏感Agent分离开，或者给Agent进程设置最小权限。
第四步：在应用层增加SSRF防护
建议在代码或Web防火墙中禁止请求内网IP段，至少包括 169.254.0.0/16、10.0.0.0/8、172.16.0.0/12、192.168.0.0/16。
同时不要信任URL解析后的IP，要重解析并对比IP地址，防止DNS重绑定绕过。
避坑与常见疑问
启用IMDSv2后旧应用会挂掉吗？ 会。
如果你的老代码是直接 curl http://169.254.169.254/... 获取角色名的，改强令牌模式后必须改造为先获取Token，否则应用会报错。
建议先在测试实例上验证，再批量下线明文模式。
临时密钥泄露了怎么处理？ 立即轮换角色密钥，撤销失陷实例的IAM角色，并排查云审计日志中是否有异常API调用。
为什么Agent本身也会造成威胁？ 因为很多Agent会在请求中拼接外部传入的URL，比如监控组件、URL采集器。
即使不是Web漏洞，这类Agent同样可被利用。
给Agent运行时配置最小权限、禁止以root运行，也是必须的。
验证结果与后续检查
完成上述操作后，重新执行步骤1的命令。
此时应提示需要提供Token，或者请求被拒绝，不会再直接返回密钥。
如果有测试环境，可以模拟一次SSRF请求：在应用代码中尝试请求 http://169.254.169.254/latest/meta-data/iam/security-credentials/，预期结果应是没有Token的情况下返回错误。
开启云审计日志，持续观察是否有来自实例内部的异常访问元数据服务行为。
最后再强调：云主机元数据服务访问风险不是一次性问题，每次部署新应用、引入新Agent时都要重新评估SSRF入口。
如果你正在处理类似安全加固需求，建议按本文顺序执行，并根据自己业务微调；
遇到异常时优先回看避坑和常见疑问部分。
