直接上结论如果你的服务跑在阿里云 ECS 上又需要访问日志服务 SLS别再往服务器里塞 AccessKey 了。把这个需求换成 ECS 实例 RAM 角色角色上只挂一个 SLS 日志只读权限既能解决密钥管理问题权限也好收敛。下面把整个绑定过程、权限设计、验证方式和踩过的坑完整讲一遍。1. 为什么我最后选择 RAM 角色而不是把 AccessKey 塞进 ECS1.1 两个方案摆在一起看过去我在服务器上访问阿里云 API最省事的办法就是创建一对 RAM 用户的 AccessKey配置到环境变量或者配置文件里。这种方案确实能用但如果项目里有多个 ECS、多套环境问题马上会暴露出来。对比一下常见做法每个 ECS 都用同一个 AK只要一个实例被攻破所有实例的权限全部暴露想单独回收某一台服务器的权限基本只能把所有实例重新配置一遍。每个 ECS 配不同的 AK密钥数量爆炸管理成本很高而且这些 AK 会以明文形式散落在磁盘、部署脚本、备份文件里时间一长很难追踪。ECS 实例 RAM 角色解决的是“服务器进程以什么身份调用云 API”这个问题。我不需要在实例里保存任何长期密钥也不需要运维同学在部署脚本里管理 secrets。只需要在 RAM 控制台创建一个角色把权限挂到角色上再把角色绑定到目标 ECS 实例实例里的进程就会自动通过本机元数据服务获取临时凭证。这样的好处很明显密钥是动态轮换的服务器上不落盘长期 AK。权限跟着角色走换一台服务器重新绑一下就行。回收权限时把角色从实例上解绑即可不需要等密钥过期。每一笔 API 调用都能够归属到具体实例、具体角色。表格如下供参考维度RAM 用户 AKECS RAM 角色凭证存储明文保存在服务器或配置文件通过元数据服务动态获取密钥生命周期需要手动轮换系统自动轮换权限隔离力度按 AK 区分粒度粗按角色区分可独立授权泄露影响长期有效危害大临时凭证快速过期运维成本高低有人可能会说RAM 用户 AK 也可以做权限收敛RAM 角色说白了也就是换了一种拿凭证的方式。这话没错但实战中最大的区别在于AK 一旦生成就会被人拿去复制、备份、写进 CI 配置RAM 角色则根本没有这个载体。对安全审计来说角色绑定实例之后所有行为都能追溯到特定 ECS这对排查问题有非常大的帮助。1.2 RAM 角色并不是把 AK 换成另一个 AKRAM 角色的核心机制是 STSSecurity Token Service。简单理解角色本身没有登录密码也没有 AccessKey角色代表的是一种“可以被谁扮演”的身份。ECS 作为被信任的实体扮演这个角色后会拿到一组临时凭证包括 AccessKeyId、AccessKeySecret、SecurityToken 和过期时间。ECS 实例拿到临时凭证的过程不需要登录 RAM 控制台也不需要人工介入。阿里云在每个 VPC 内部都提供了一个实例元数据服务地址http://100.100.100.100/latest/meta-data/当角色绑定到实例后访问下面这个路径就能拿到角色对应的临时凭证http://100.100.100.100/latest/meta-data/ram/security-credentials/角色名实例内部的应用通过官方 SDK 调用云产品 API 时SDK 会自动去元数据服务获取临时凭证整个过程对应用是透明的。换句话说从开发者的视角看代码里不需要写任何 AK直接调用相关产品的接口即可。这里有一个关键概念要理解清楚ECS RAM 角色绑定不是把某个 RAM 用户的密钥“映射”到服务器上而是让 ECS 服务具备扮演某个 RAM 角色的能力。扮演成功后拿到的是一组新的 STS 凭证这个凭证的权限完全来自角色上挂载的权限策略和原账号没有任何关系。因此权限的最小化设计应该围绕“角色要给哪些权限”来思考而不是复制原来 AK 的权限。2. 动手前需要先理解的角色与权限边界2.1 SLS 的资源模型与读取日志需要的最小权限SLS 日志服务的基础资源模型是“项目 Project”和“日志库 Logstore”。一个 Project 属于一个地域Project 下面可以创建多个 LogstoreLogstore 是日志数据的载体日志数据进入 Logstore 后先被写入 Shard再依赖索引能力被查询。如果我要实现“ECS 上的应用只读 SLS 指定项目的日志”需要明确两件事允许读取哪些 Project、哪些 Logstore。允许执行哪些具体操作比如列出日志库、读取日志、查询日志。最直接的做法是给角色挂载系统内置的AliyunLogReadOnlyAccess策略。这个策略的作用范围是整个账号下所有 Project动作覆盖日志服务的大部分只读操作。如果只是开发测试环境临时用一下挂这个策略足够。但在生产环境我一般建议把权限收窄到具体 Project。以只读为例下面是一个实际业务中比较常用的自定义策略模板{ Version: 1, Statement: [ { Effect: Allow, Action: [ log:ListProject, log:GetProject, log:ListLogStores, log:GetLogStore, log:GetLogStoreLogs, log:GetLogs, log:GetShard ], Resource: acs:log:*:*:project/ecs-prod/* } ] }有几点需要说明Resource字段里的ecs-prod需要替换成实际 Project 名称星号表示该 Project 下的所有 Logstore。具体 Action 名称以 RAM 控制台策略编辑器的自动联想为准不同时期历史版本可能存在简化和规范。如果还需要读取仪表盘或告警配置应该补充对应只读 Action。这套策略约束的核心是这个角色只能在指定 Project 里活动无法跨到其他 Project。如果后续日志需求扩展到某个新项目只需要修改策略不需要改动服务器配置。2.2 三种授权策略怎么选实际工作里我遇到过三种“只读授权”的诉求很容易搞混。第一种是“我只想用控制台看看日志”。控制台查看日志通常需要列出 Project、列出 Logstore、查询日志等权限并且控制台页面本身会调用很多 API建议直接使用系统策略AliyunLogReadOnlyAccess否则页面功能可能出现一半可用。第二种是“应用要通过 API 读取日志比如做实时分析或告警回捞”。这种需求比较固定用自定义策略做项目级收窄最合适。不需要给控制台页面相关的全套权限只需要让代码能够调用对应的接口。第三种是“应用要读取日志而且还要读取对象的某些其他资源”。这意味着角色需要涉及多个云产品的权限那么一个自定义策略就不够需要拆分多个策略挂到同一个角色上。例如只读 SLS 只读 OSS我建议分别建两个策略而不是混在一个 JSON 里这样将来排查权限归属时能直接定位到具体策略。上面这个区分很重要。因为很多同学遇到“日志查询权限不足”的报错第一反应是 OpenAPI 里的某个 Action 没被授权但实际可能是权限策略范围过窄导致控制台诊断工具调用失败。分清场景后再去设计策略能省很多时间。3. 完整实操创建 RAM 角色、授权并绑定到 ECS3.1 创建角色时信任的实体为什么必须选“云服务器”登录 RAM 控制台进入“身份管理 角色”点击“创建角色”。第一步选择可信实体类型这里必须选择“阿里云服务”第二步在“选择服务”列表里找到“云服务器”然后输入角色名称。我把测试角色命名为ecs-slss-readonly-role。这里有一个初学者容易误解的点这个步骤其实是在建立“信任关系”——告诉 STSECS 服务可以代表实例扮演这个角色。如果这里选错成“阿里云账号”或者“身份提供商”后面即使把角色绑定到 ECS实例也无法获取临时凭证。创建完成后角色详情页里能看到信任策略信息核心结构如下{ Version: 1, Statement: [ { Action: sts:AssumeRole, Effect: Allow, Principal: { Service: [ ecs.aliyuncs.com ] } } ] }这句话翻译过来就是允许 ECS 服务调用AssumeRole来获取这个角色的临时凭证。没有这一步后面所有绑定操作都没有意义。在控制台操作时也可以不手动查看 JSON默认生成的信任规则就是针对 ECS 的。但如果你以后要通过 Terraform 或 ROS 编排资源理解这段信任策略是必须的。3.2 给角色委派权限系统策略与自定义策略角色创建成功后在角色详情页进入“权限管理”点击“新增授权”。如果只是快速验证可以直接搜索系统策略AliyunLogReadOnlyAccess点击确定即可。我的习惯是加上自定义策略。操作路径是先创建自定义策略再回到角色授权时选择已有策略。新建自定义策略时策略名称我用sls-readonly-ecs-prod配置模式选择“脚本编辑”把前面那一段 JSON 粘贴进去。如果你没有明确的 Project 限制需求那为了避免不必要的报错可以先用系统策略跑通链路再逐步收窄范围到项目级。这个先放开再收窄的思路比较适合首次接手的系统适用于权限模型还不太清晰的场景。3.3 在 ECS 控制台完成绑定并验证 metadata权限策略挂到角色之后接下来是最后一步把角色绑定到具体一台 ECS 实例。操作方式很简单进入 ECS 控制台找到目标实例。在实例列表勾选该实例点击更多操作进入“安全/访问控制”菜单。找到“RAM 角色”相关入口选择ecs-slss-readonly-role点击确认。不同地域的控制台菜单名称可能有差异有的显示“绑定 RAM 角色”有的在“安全”菜单里叫“实例 RAM 角色”还有的版本里放到“访问控制”。核心搜索关键词就是“RAM 角色”。绑定完成后登录实例执行curl http://100.100.100.100/latest/meta-data/ram/security-credentials/正常情况下会返回当前实例绑定的角色名称。如果返回空或者 404说明绑定没生效或者角色类型不对。再执行curl http://100.100.100.100/latest/meta-data/ram/security-credentials/ecs-slss-readonly-role能拿到一串 JSON里面包含{ AccessKeyId: STS.xxx, AccessKeySecret: xxx, SecurityToken: xxx, Expiration: 2025-01-01T00:00:00Z }到这里角色绑定链路已经通了一半。剩下的工作是让 SDK 或 CLI 真正使用这组临时凭证去读取 SLS 日志。3.4 用 CLI/API 做自动化绑定可选控制台操作适合单机验证如果环境要批量交付最好用 API 或命令行工具。阿里云 CLI 支持查询和绑定 RAM 角色执行方式如下# 查看实例当前绑定的角色 aliyun ecs DescribeInstanceRamRole \ --RegionId cn-hangzhou \ --InstanceIds [i-xxxxx] # 为实例绑定 RAM 角色 aliyun ecs AttachInstanceRamRole \ --RegionId cn-hangzhou \ --InstanceIds [i-xxxxx] \ --RamRoleName ecs-slss-readonly-role # 解绑 aliyun ecs DetachInstanceRamRole \ --RegionId cn-hangzhou \ --InstanceIds [i-xxxxx] \ --RamRoleName ecs-slss-readonly-role绑定和解绑都是即时生效的不需要重启实例。不过这里要提醒如果你是在初始化脚本里通过元数据服务获取凭证脚本里需要加一步简单的轮询重试因为实例绑定角色后的瞬间部分前置动作可能仍然走着旧的凭证链偶尔会有很短时间的缓存延迟。实际我在自动化工具里遇到过一次绑定后马上获取凭证失败的情况间隔两三秒重试就正常了。4. 从 ECS 内部验证 SLS 只读权限4.1 如何确认本机已经拿到 STS 临时凭证实例内执行 curl 验证时我建议把凭证内容和过期时间分开看不要直接把完整凭证打印到日志里。这里有一个更安全的方式只用 jq 解析过期时间和 AccessKeyId 前缀确认元数据链路没问题即可。identity$(curl -s http://100.100.100.100/latest/meta-data/ram/security-credentials/ecs-slss-readonly-role) echo $identity | jq .Expiration echo $identity | jq .AccessKeyId如果看到 Expiration 是当前时间之后的一段时间说明临时凭证已经可以正常下发了。顺便提一句实例元数据服务是 VPC 内网地址不需要外网访问能力也不占用公网带宽。因此在安全组里把这个地址保护好是重要的后续工作但通常不需要额外放行端口。4.2 使用 Python SDK 读取 SLS 日志验证在验证阶段我建议直接用 Python SDK 读取日志库的若干条记录而不是先写完整业务代码。这样能最快暴露权限问题。先安装 SDKpip install aliyun-log-python-sdk示例代码如下import json import urllib.request from aliyun.log import LogClient, GetLogsRequest role_name ecs-slss-readonly-role metadata_url ( http://100.100.100.100/latest/meta-data/ram/security-credentials/ role_name ) with urllib.request.urlopen(metadata_url, timeout3) as resp: cred json.loads(resp.read().decode()) client LogClient( cn-hangzhou.log.aliyuncs.com, cred[AccessKeyId], cred[AccessKeySecret], cred[SecurityToken], ) request GetLogsRequest( projectecs-prod, logstorenginx-access, from_time1700000000, to_time1700003600, query, line20, offset0, reverseFalse, ) result client.get_logs(request) for log in result.get_logs(): print(log)需要注意替换三处信息role_name必须和绑定的角色名称一致。cn-hangzhou.log.aliyuncs.com这是杭州地域 SLS 的接入地址如果 Project 在其他地域要去查看对应地域的 Endpoint。Project和Logstore名称换成你要读取的真实资源。SDK 会自动把临时凭证的 AccessKeyId、AccessKeySecret、SecurityToken 一起参与签名过程中不需要渲染任何持久化配置。如果你用的是阿里云官方提供的其他编程语言 SDK思路是一样的通过 STS 临时凭证构造客户端。这里有个常见疑问为什么我不直接让 SDK 自动去元数据服务拉取凭证因为不同 SDK 的自动凭证链配置方式并不完全一样有的需要额外依赖有的需要在初始化时显式指定 Credentials Provider。为了演示底层原理手动获取再传给客户端最透明也最容易排查问题。4.3 日志查询能返回结果不代表只读权限已经完全够用我遇到过一种情况把角色绑定好、策略也挂好了Python SDK 查询也没报错但查询结果一直为空而我在 SLS 控制台手工搜索却能看到日志数据。排查到最后发现是 Logstore 的索引没有开启。SLS 的日志查询本质上是搜索索引不是直接扫描原始文件。如果 Logstore 没有为相关字段配置索引即使权限完全 OK查询接口也只能返回命中索引的数据或直接告诉你索引不存在。这个坑和 RAM 角色本身没有关系但在第一次做“只读权限验证”时很容易被误判为权限不足。所以验证日志读取建议先确认以下条件Logstore 已经开启索引并且至少有一个字段有索引。查询时间区间里有日志写入。如果查询语句为空字符串也要设置正确的 from_time 和 to_time。把这些条件理清后再去判断是不是 RAM 权限问题排查效率会高很多。5. 排查记录那些看起来像权限问题却另有原因的问题5.1 常见故障对照表我整理一下在 ECS RAM 角色与 SLS 只读场景下比较常见的故障现象和处理思路现象可能原因处理方式curl 元数据地址返回 404角色未绑定或绑定未生效在控制台确认角色已挂到实例上用 AttachInstanceRamRole API 重新绑定curl 返回角色关联错误创建角色时信任实体选错检查角色信任策略是否允许ecs.aliyuncs.com扮演SDK 报 InvalidAccessKeyId 或 InvalidSecurityToken顺手写死 AccessKey 而没有用 SecurityToken客户端初始化时必须同时传入 SecurityToken读取日志报 Permission Denied角色没挂只读策略或策略范围不含该项目检查角色权限策略确认 Resource 匹配 Project 完整名查询 SLS 不报错但结果为空Logstore 索引没开启控制台为该 Logstore 增加索引配置同一套客户端代码在本地正常、在 ECS 上报错本地走 AKECS 上的凭证链没有自动切换在 ECS 里主动读取元数据凭证检查代码初始化的数据源绑定角色后立即访问偶尔超时角色下发存在短暂传播延迟代码里设置重试间隔数秒重新获取临时凭证这里最值得展开的是第五个“查询结果为空”的情况很多人会优先怀疑 RAM 授权问题。实际上 RAM 权限不足时API 通常会在返回 HTTP 状态码时直接报错不会给你一个“查询成功但没数据”的结果。所以我建议排查时先分清楚到底是“请求被拒绝”还是“请求成功但结果空”这两种情况完全指向不同的原因链条。5.2 复盘一次被误判为权限不足的绑定事件有一次我把一个角色从测试环境复制到生产环境策略同样只加了 SLS 只读权限绑定到新 ECS 后用 SDK 拉日志时报了一个鉴权错误。第一反应是策略没生效因为两个环境几乎一样不可能有差异。但仔细对比后发现生产环境里的 Project 名称是ecs-prod-log而我从测试环境复制的自定义策略里 Resource 写的还是测试 Project 名称。角色挂载策略本身没有问题问题出在策略 JSON 里的资源范围限制得太死导致对生产 Project 的访问全部被拒绝。排查思路很简单先用只读系统策略临时挂到角色上发现问题消失。确认是自定义策略限制问题。对比 Resource 里的 Project 名称与目标 Project 的差异并修正。这个 case 给到日常最大的启发是权限策略要尽量模板化管理而且模板里要把环境标识作为变量处理不能直接从测试环境复制到生产环境后就觉得没有问题。5.3 网络与安全层面的隐患排查角色绑定成功后还有一个容易被忽视的安全隐患如果 ECS 上的应用程序存在 SSRF 漏洞攻击者可能会尝试访问100.100.100.100/latest/meta-data/路径来窃取 RAM 角色临时凭证。这是云上环境里常见的攻击路径。即使拿到的是临时凭证攻击者也可能在它过期前利用它读取 SLS 日志甚至调用其他已授权 API。因此我们应该把元数据访问当成一个敏感出口来看待尽量从网络侧收敛应用对外请求的目标地址同时在代码层禁止把元数据地址放进任意回调逻辑中。还有一点是即使角色只授了 SLS 只读权限也不建议让所有人都能登录这台 ECS。拿到实例 shell 的人就相当于拿到了当前角色能获取的临时凭证本质上也拥有了角色权限。所以对 ECS 本身的登录管控、密钥对管理、运维通道管理不因 RAM 角色做得细而放松。6. 安全与运维层面值得注意的细节6.1 最小权限的再收窄按项目限制还不够如果已经做到了按 Project 限制那已经比全量只读权限好很多。但再往下走一步还能把权限细化到 Logstore 维度以及特定条件。比如我有一个 Project 里同时放着 nginx 日志和订单业务日志某个分析任务只需要读取 nginx 日志那在策略的Resource里可以把日志库名称明确写出来{ Effect: Allow, Action: [ log:GetLogStoreLogs, log:GetLogs ], Resource: acs:log:*:*:project/ecs-prod-log/logstore/nginx-access }这个比project/ecs-prod-log/*的范围又小了一圈而且更接近真实业务边界。如果担心日志库会动态扩容再逐步扩大范围但追求的是“刚好够用多一个不给”。在处理跨地域的情况时还可以在策略中加acs:RequestRegion条件这样即使个别账号下的 Project 名称重名也不会出现跨地域访问的问题。6.2 让临时凭证回到应该待的地方很多开发同学把角色绑定成功后会在代码里把临时凭证保存为常量复制到多个业务模块里复用。这不是个好习惯因为临时凭证的过期时间短则几十分钟长则几小时过期后代码又没有自动刷新机制业务就会开始报错。正确做法是让 SDK 的默认凭证链自己工作。阿里云官方 SDK 通常支持从实例元数据服务自动获取凭证只需要在客户端初始化时配置相应的凭证 Provider 或依赖。以 Python 生态为例新版 SDK 可以配置 Credentials Provider把默认凭证供应商设置为实例角色名这样即使临时凭证轮换SDK 也会自动获取最新的凭证不用业务代码每次去解析临时 token。如果项目里确实需要手动获取凭证也应该写一个独立的凭证获取与缓存模块负责统一请求元数据服务、解析临时凭证、在过期前抢占式刷新并加上重试逻辑。切忌在每个 API 调用点都去手动 curl 一次元数据服务。6.3 角色后续管理轮换、审计与告警RAM 角色绑定不是一次性配置。随着业务扩缩容ECS 实例会不断增加或释放如果实例创建流程里没有自动绑定角色的步骤很容易在后来的机器上丢失角色权限导致应用运行一段时间后才暴露出问题。我目前比较推荐的做法是把 RAM 角色名作为 ECS 实例创建模板的一个必填参数。使用 Terraform 或 ROS 编排资源时在资源定义里显式声明ram_role_name。每次变更角色策略前先在预发环境的小流量实例上验证观察日志读取是否稳定后再全量发布。通过操作审计服务关注角色扮演和 SLS 读取相关的事件日志出现异常调用时能快速定位到具体实例和时间窗口。有一件小事很值得坚持做为角色命名时把职责写进名称比如ecs-slss-readonly-role表示“ECS 读 SLS 专用角色”而不是test-role这种含义模糊的名称。因为在审计日志里如果所有机器都用同一个泛化角色追踪责任方会变得特别困难。最后说一个实际建议如果你第一次做这个实验别追求一次到位先把系统内置的AliyunLogReadOnlyAccess挂上跑通链路确认元数据和 SDK 都正常了再改成自定义策略收窄权限。我见过太多同学一上来就写精密的权限 JSON结果某个 Action 名称写错或缺少必要读权限卡在权限排查上大半天。权限本来就是可以动态调整的先放开、再收窄这个节奏更适合线上练手。等整个流程稳定了设计原则会慢慢刻在习惯里以后再遇到其他云产品接入RAM 角色这套思路是可以直接复用的。
ECS实例RAM角色访问SLS日志服务只读权限配置指南
直接上结论如果你的服务跑在阿里云 ECS 上又需要访问日志服务 SLS别再往服务器里塞 AccessKey 了。把这个需求换成 ECS 实例 RAM 角色角色上只挂一个 SLS 日志只读权限既能解决密钥管理问题权限也好收敛。下面把整个绑定过程、权限设计、验证方式和踩过的坑完整讲一遍。1. 为什么我最后选择 RAM 角色而不是把 AccessKey 塞进 ECS1.1 两个方案摆在一起看过去我在服务器上访问阿里云 API最省事的办法就是创建一对 RAM 用户的 AccessKey配置到环境变量或者配置文件里。这种方案确实能用但如果项目里有多个 ECS、多套环境问题马上会暴露出来。对比一下常见做法每个 ECS 都用同一个 AK只要一个实例被攻破所有实例的权限全部暴露想单独回收某一台服务器的权限基本只能把所有实例重新配置一遍。每个 ECS 配不同的 AK密钥数量爆炸管理成本很高而且这些 AK 会以明文形式散落在磁盘、部署脚本、备份文件里时间一长很难追踪。ECS 实例 RAM 角色解决的是“服务器进程以什么身份调用云 API”这个问题。我不需要在实例里保存任何长期密钥也不需要运维同学在部署脚本里管理 secrets。只需要在 RAM 控制台创建一个角色把权限挂到角色上再把角色绑定到目标 ECS 实例实例里的进程就会自动通过本机元数据服务获取临时凭证。这样的好处很明显密钥是动态轮换的服务器上不落盘长期 AK。权限跟着角色走换一台服务器重新绑一下就行。回收权限时把角色从实例上解绑即可不需要等密钥过期。每一笔 API 调用都能够归属到具体实例、具体角色。表格如下供参考维度RAM 用户 AKECS RAM 角色凭证存储明文保存在服务器或配置文件通过元数据服务动态获取密钥生命周期需要手动轮换系统自动轮换权限隔离力度按 AK 区分粒度粗按角色区分可独立授权泄露影响长期有效危害大临时凭证快速过期运维成本高低有人可能会说RAM 用户 AK 也可以做权限收敛RAM 角色说白了也就是换了一种拿凭证的方式。这话没错但实战中最大的区别在于AK 一旦生成就会被人拿去复制、备份、写进 CI 配置RAM 角色则根本没有这个载体。对安全审计来说角色绑定实例之后所有行为都能追溯到特定 ECS这对排查问题有非常大的帮助。1.2 RAM 角色并不是把 AK 换成另一个 AKRAM 角色的核心机制是 STSSecurity Token Service。简单理解角色本身没有登录密码也没有 AccessKey角色代表的是一种“可以被谁扮演”的身份。ECS 作为被信任的实体扮演这个角色后会拿到一组临时凭证包括 AccessKeyId、AccessKeySecret、SecurityToken 和过期时间。ECS 实例拿到临时凭证的过程不需要登录 RAM 控制台也不需要人工介入。阿里云在每个 VPC 内部都提供了一个实例元数据服务地址http://100.100.100.100/latest/meta-data/当角色绑定到实例后访问下面这个路径就能拿到角色对应的临时凭证http://100.100.100.100/latest/meta-data/ram/security-credentials/角色名实例内部的应用通过官方 SDK 调用云产品 API 时SDK 会自动去元数据服务获取临时凭证整个过程对应用是透明的。换句话说从开发者的视角看代码里不需要写任何 AK直接调用相关产品的接口即可。这里有一个关键概念要理解清楚ECS RAM 角色绑定不是把某个 RAM 用户的密钥“映射”到服务器上而是让 ECS 服务具备扮演某个 RAM 角色的能力。扮演成功后拿到的是一组新的 STS 凭证这个凭证的权限完全来自角色上挂载的权限策略和原账号没有任何关系。因此权限的最小化设计应该围绕“角色要给哪些权限”来思考而不是复制原来 AK 的权限。2. 动手前需要先理解的角色与权限边界2.1 SLS 的资源模型与读取日志需要的最小权限SLS 日志服务的基础资源模型是“项目 Project”和“日志库 Logstore”。一个 Project 属于一个地域Project 下面可以创建多个 LogstoreLogstore 是日志数据的载体日志数据进入 Logstore 后先被写入 Shard再依赖索引能力被查询。如果我要实现“ECS 上的应用只读 SLS 指定项目的日志”需要明确两件事允许读取哪些 Project、哪些 Logstore。允许执行哪些具体操作比如列出日志库、读取日志、查询日志。最直接的做法是给角色挂载系统内置的AliyunLogReadOnlyAccess策略。这个策略的作用范围是整个账号下所有 Project动作覆盖日志服务的大部分只读操作。如果只是开发测试环境临时用一下挂这个策略足够。但在生产环境我一般建议把权限收窄到具体 Project。以只读为例下面是一个实际业务中比较常用的自定义策略模板{ Version: 1, Statement: [ { Effect: Allow, Action: [ log:ListProject, log:GetProject, log:ListLogStores, log:GetLogStore, log:GetLogStoreLogs, log:GetLogs, log:GetShard ], Resource: acs:log:*:*:project/ecs-prod/* } ] }有几点需要说明Resource字段里的ecs-prod需要替换成实际 Project 名称星号表示该 Project 下的所有 Logstore。具体 Action 名称以 RAM 控制台策略编辑器的自动联想为准不同时期历史版本可能存在简化和规范。如果还需要读取仪表盘或告警配置应该补充对应只读 Action。这套策略约束的核心是这个角色只能在指定 Project 里活动无法跨到其他 Project。如果后续日志需求扩展到某个新项目只需要修改策略不需要改动服务器配置。2.2 三种授权策略怎么选实际工作里我遇到过三种“只读授权”的诉求很容易搞混。第一种是“我只想用控制台看看日志”。控制台查看日志通常需要列出 Project、列出 Logstore、查询日志等权限并且控制台页面本身会调用很多 API建议直接使用系统策略AliyunLogReadOnlyAccess否则页面功能可能出现一半可用。第二种是“应用要通过 API 读取日志比如做实时分析或告警回捞”。这种需求比较固定用自定义策略做项目级收窄最合适。不需要给控制台页面相关的全套权限只需要让代码能够调用对应的接口。第三种是“应用要读取日志而且还要读取对象的某些其他资源”。这意味着角色需要涉及多个云产品的权限那么一个自定义策略就不够需要拆分多个策略挂到同一个角色上。例如只读 SLS 只读 OSS我建议分别建两个策略而不是混在一个 JSON 里这样将来排查权限归属时能直接定位到具体策略。上面这个区分很重要。因为很多同学遇到“日志查询权限不足”的报错第一反应是 OpenAPI 里的某个 Action 没被授权但实际可能是权限策略范围过窄导致控制台诊断工具调用失败。分清场景后再去设计策略能省很多时间。3. 完整实操创建 RAM 角色、授权并绑定到 ECS3.1 创建角色时信任的实体为什么必须选“云服务器”登录 RAM 控制台进入“身份管理 角色”点击“创建角色”。第一步选择可信实体类型这里必须选择“阿里云服务”第二步在“选择服务”列表里找到“云服务器”然后输入角色名称。我把测试角色命名为ecs-slss-readonly-role。这里有一个初学者容易误解的点这个步骤其实是在建立“信任关系”——告诉 STSECS 服务可以代表实例扮演这个角色。如果这里选错成“阿里云账号”或者“身份提供商”后面即使把角色绑定到 ECS实例也无法获取临时凭证。创建完成后角色详情页里能看到信任策略信息核心结构如下{ Version: 1, Statement: [ { Action: sts:AssumeRole, Effect: Allow, Principal: { Service: [ ecs.aliyuncs.com ] } } ] }这句话翻译过来就是允许 ECS 服务调用AssumeRole来获取这个角色的临时凭证。没有这一步后面所有绑定操作都没有意义。在控制台操作时也可以不手动查看 JSON默认生成的信任规则就是针对 ECS 的。但如果你以后要通过 Terraform 或 ROS 编排资源理解这段信任策略是必须的。3.2 给角色委派权限系统策略与自定义策略角色创建成功后在角色详情页进入“权限管理”点击“新增授权”。如果只是快速验证可以直接搜索系统策略AliyunLogReadOnlyAccess点击确定即可。我的习惯是加上自定义策略。操作路径是先创建自定义策略再回到角色授权时选择已有策略。新建自定义策略时策略名称我用sls-readonly-ecs-prod配置模式选择“脚本编辑”把前面那一段 JSON 粘贴进去。如果你没有明确的 Project 限制需求那为了避免不必要的报错可以先用系统策略跑通链路再逐步收窄范围到项目级。这个先放开再收窄的思路比较适合首次接手的系统适用于权限模型还不太清晰的场景。3.3 在 ECS 控制台完成绑定并验证 metadata权限策略挂到角色之后接下来是最后一步把角色绑定到具体一台 ECS 实例。操作方式很简单进入 ECS 控制台找到目标实例。在实例列表勾选该实例点击更多操作进入“安全/访问控制”菜单。找到“RAM 角色”相关入口选择ecs-slss-readonly-role点击确认。不同地域的控制台菜单名称可能有差异有的显示“绑定 RAM 角色”有的在“安全”菜单里叫“实例 RAM 角色”还有的版本里放到“访问控制”。核心搜索关键词就是“RAM 角色”。绑定完成后登录实例执行curl http://100.100.100.100/latest/meta-data/ram/security-credentials/正常情况下会返回当前实例绑定的角色名称。如果返回空或者 404说明绑定没生效或者角色类型不对。再执行curl http://100.100.100.100/latest/meta-data/ram/security-credentials/ecs-slss-readonly-role能拿到一串 JSON里面包含{ AccessKeyId: STS.xxx, AccessKeySecret: xxx, SecurityToken: xxx, Expiration: 2025-01-01T00:00:00Z }到这里角色绑定链路已经通了一半。剩下的工作是让 SDK 或 CLI 真正使用这组临时凭证去读取 SLS 日志。3.4 用 CLI/API 做自动化绑定可选控制台操作适合单机验证如果环境要批量交付最好用 API 或命令行工具。阿里云 CLI 支持查询和绑定 RAM 角色执行方式如下# 查看实例当前绑定的角色 aliyun ecs DescribeInstanceRamRole \ --RegionId cn-hangzhou \ --InstanceIds [i-xxxxx] # 为实例绑定 RAM 角色 aliyun ecs AttachInstanceRamRole \ --RegionId cn-hangzhou \ --InstanceIds [i-xxxxx] \ --RamRoleName ecs-slss-readonly-role # 解绑 aliyun ecs DetachInstanceRamRole \ --RegionId cn-hangzhou \ --InstanceIds [i-xxxxx] \ --RamRoleName ecs-slss-readonly-role绑定和解绑都是即时生效的不需要重启实例。不过这里要提醒如果你是在初始化脚本里通过元数据服务获取凭证脚本里需要加一步简单的轮询重试因为实例绑定角色后的瞬间部分前置动作可能仍然走着旧的凭证链偶尔会有很短时间的缓存延迟。实际我在自动化工具里遇到过一次绑定后马上获取凭证失败的情况间隔两三秒重试就正常了。4. 从 ECS 内部验证 SLS 只读权限4.1 如何确认本机已经拿到 STS 临时凭证实例内执行 curl 验证时我建议把凭证内容和过期时间分开看不要直接把完整凭证打印到日志里。这里有一个更安全的方式只用 jq 解析过期时间和 AccessKeyId 前缀确认元数据链路没问题即可。identity$(curl -s http://100.100.100.100/latest/meta-data/ram/security-credentials/ecs-slss-readonly-role) echo $identity | jq .Expiration echo $identity | jq .AccessKeyId如果看到 Expiration 是当前时间之后的一段时间说明临时凭证已经可以正常下发了。顺便提一句实例元数据服务是 VPC 内网地址不需要外网访问能力也不占用公网带宽。因此在安全组里把这个地址保护好是重要的后续工作但通常不需要额外放行端口。4.2 使用 Python SDK 读取 SLS 日志验证在验证阶段我建议直接用 Python SDK 读取日志库的若干条记录而不是先写完整业务代码。这样能最快暴露权限问题。先安装 SDKpip install aliyun-log-python-sdk示例代码如下import json import urllib.request from aliyun.log import LogClient, GetLogsRequest role_name ecs-slss-readonly-role metadata_url ( http://100.100.100.100/latest/meta-data/ram/security-credentials/ role_name ) with urllib.request.urlopen(metadata_url, timeout3) as resp: cred json.loads(resp.read().decode()) client LogClient( cn-hangzhou.log.aliyuncs.com, cred[AccessKeyId], cred[AccessKeySecret], cred[SecurityToken], ) request GetLogsRequest( projectecs-prod, logstorenginx-access, from_time1700000000, to_time1700003600, query, line20, offset0, reverseFalse, ) result client.get_logs(request) for log in result.get_logs(): print(log)需要注意替换三处信息role_name必须和绑定的角色名称一致。cn-hangzhou.log.aliyuncs.com这是杭州地域 SLS 的接入地址如果 Project 在其他地域要去查看对应地域的 Endpoint。Project和Logstore名称换成你要读取的真实资源。SDK 会自动把临时凭证的 AccessKeyId、AccessKeySecret、SecurityToken 一起参与签名过程中不需要渲染任何持久化配置。如果你用的是阿里云官方提供的其他编程语言 SDK思路是一样的通过 STS 临时凭证构造客户端。这里有个常见疑问为什么我不直接让 SDK 自动去元数据服务拉取凭证因为不同 SDK 的自动凭证链配置方式并不完全一样有的需要额外依赖有的需要在初始化时显式指定 Credentials Provider。为了演示底层原理手动获取再传给客户端最透明也最容易排查问题。4.3 日志查询能返回结果不代表只读权限已经完全够用我遇到过一种情况把角色绑定好、策略也挂好了Python SDK 查询也没报错但查询结果一直为空而我在 SLS 控制台手工搜索却能看到日志数据。排查到最后发现是 Logstore 的索引没有开启。SLS 的日志查询本质上是搜索索引不是直接扫描原始文件。如果 Logstore 没有为相关字段配置索引即使权限完全 OK查询接口也只能返回命中索引的数据或直接告诉你索引不存在。这个坑和 RAM 角色本身没有关系但在第一次做“只读权限验证”时很容易被误判为权限不足。所以验证日志读取建议先确认以下条件Logstore 已经开启索引并且至少有一个字段有索引。查询时间区间里有日志写入。如果查询语句为空字符串也要设置正确的 from_time 和 to_time。把这些条件理清后再去判断是不是 RAM 权限问题排查效率会高很多。5. 排查记录那些看起来像权限问题却另有原因的问题5.1 常见故障对照表我整理一下在 ECS RAM 角色与 SLS 只读场景下比较常见的故障现象和处理思路现象可能原因处理方式curl 元数据地址返回 404角色未绑定或绑定未生效在控制台确认角色已挂到实例上用 AttachInstanceRamRole API 重新绑定curl 返回角色关联错误创建角色时信任实体选错检查角色信任策略是否允许ecs.aliyuncs.com扮演SDK 报 InvalidAccessKeyId 或 InvalidSecurityToken顺手写死 AccessKey 而没有用 SecurityToken客户端初始化时必须同时传入 SecurityToken读取日志报 Permission Denied角色没挂只读策略或策略范围不含该项目检查角色权限策略确认 Resource 匹配 Project 完整名查询 SLS 不报错但结果为空Logstore 索引没开启控制台为该 Logstore 增加索引配置同一套客户端代码在本地正常、在 ECS 上报错本地走 AKECS 上的凭证链没有自动切换在 ECS 里主动读取元数据凭证检查代码初始化的数据源绑定角色后立即访问偶尔超时角色下发存在短暂传播延迟代码里设置重试间隔数秒重新获取临时凭证这里最值得展开的是第五个“查询结果为空”的情况很多人会优先怀疑 RAM 授权问题。实际上 RAM 权限不足时API 通常会在返回 HTTP 状态码时直接报错不会给你一个“查询成功但没数据”的结果。所以我建议排查时先分清楚到底是“请求被拒绝”还是“请求成功但结果空”这两种情况完全指向不同的原因链条。5.2 复盘一次被误判为权限不足的绑定事件有一次我把一个角色从测试环境复制到生产环境策略同样只加了 SLS 只读权限绑定到新 ECS 后用 SDK 拉日志时报了一个鉴权错误。第一反应是策略没生效因为两个环境几乎一样不可能有差异。但仔细对比后发现生产环境里的 Project 名称是ecs-prod-log而我从测试环境复制的自定义策略里 Resource 写的还是测试 Project 名称。角色挂载策略本身没有问题问题出在策略 JSON 里的资源范围限制得太死导致对生产 Project 的访问全部被拒绝。排查思路很简单先用只读系统策略临时挂到角色上发现问题消失。确认是自定义策略限制问题。对比 Resource 里的 Project 名称与目标 Project 的差异并修正。这个 case 给到日常最大的启发是权限策略要尽量模板化管理而且模板里要把环境标识作为变量处理不能直接从测试环境复制到生产环境后就觉得没有问题。5.3 网络与安全层面的隐患排查角色绑定成功后还有一个容易被忽视的安全隐患如果 ECS 上的应用程序存在 SSRF 漏洞攻击者可能会尝试访问100.100.100.100/latest/meta-data/路径来窃取 RAM 角色临时凭证。这是云上环境里常见的攻击路径。即使拿到的是临时凭证攻击者也可能在它过期前利用它读取 SLS 日志甚至调用其他已授权 API。因此我们应该把元数据访问当成一个敏感出口来看待尽量从网络侧收敛应用对外请求的目标地址同时在代码层禁止把元数据地址放进任意回调逻辑中。还有一点是即使角色只授了 SLS 只读权限也不建议让所有人都能登录这台 ECS。拿到实例 shell 的人就相当于拿到了当前角色能获取的临时凭证本质上也拥有了角色权限。所以对 ECS 本身的登录管控、密钥对管理、运维通道管理不因 RAM 角色做得细而放松。6. 安全与运维层面值得注意的细节6.1 最小权限的再收窄按项目限制还不够如果已经做到了按 Project 限制那已经比全量只读权限好很多。但再往下走一步还能把权限细化到 Logstore 维度以及特定条件。比如我有一个 Project 里同时放着 nginx 日志和订单业务日志某个分析任务只需要读取 nginx 日志那在策略的Resource里可以把日志库名称明确写出来{ Effect: Allow, Action: [ log:GetLogStoreLogs, log:GetLogs ], Resource: acs:log:*:*:project/ecs-prod-log/logstore/nginx-access }这个比project/ecs-prod-log/*的范围又小了一圈而且更接近真实业务边界。如果担心日志库会动态扩容再逐步扩大范围但追求的是“刚好够用多一个不给”。在处理跨地域的情况时还可以在策略中加acs:RequestRegion条件这样即使个别账号下的 Project 名称重名也不会出现跨地域访问的问题。6.2 让临时凭证回到应该待的地方很多开发同学把角色绑定成功后会在代码里把临时凭证保存为常量复制到多个业务模块里复用。这不是个好习惯因为临时凭证的过期时间短则几十分钟长则几小时过期后代码又没有自动刷新机制业务就会开始报错。正确做法是让 SDK 的默认凭证链自己工作。阿里云官方 SDK 通常支持从实例元数据服务自动获取凭证只需要在客户端初始化时配置相应的凭证 Provider 或依赖。以 Python 生态为例新版 SDK 可以配置 Credentials Provider把默认凭证供应商设置为实例角色名这样即使临时凭证轮换SDK 也会自动获取最新的凭证不用业务代码每次去解析临时 token。如果项目里确实需要手动获取凭证也应该写一个独立的凭证获取与缓存模块负责统一请求元数据服务、解析临时凭证、在过期前抢占式刷新并加上重试逻辑。切忌在每个 API 调用点都去手动 curl 一次元数据服务。6.3 角色后续管理轮换、审计与告警RAM 角色绑定不是一次性配置。随着业务扩缩容ECS 实例会不断增加或释放如果实例创建流程里没有自动绑定角色的步骤很容易在后来的机器上丢失角色权限导致应用运行一段时间后才暴露出问题。我目前比较推荐的做法是把 RAM 角色名作为 ECS 实例创建模板的一个必填参数。使用 Terraform 或 ROS 编排资源时在资源定义里显式声明ram_role_name。每次变更角色策略前先在预发环境的小流量实例上验证观察日志读取是否稳定后再全量发布。通过操作审计服务关注角色扮演和 SLS 读取相关的事件日志出现异常调用时能快速定位到具体实例和时间窗口。有一件小事很值得坚持做为角色命名时把职责写进名称比如ecs-slss-readonly-role表示“ECS 读 SLS 专用角色”而不是test-role这种含义模糊的名称。因为在审计日志里如果所有机器都用同一个泛化角色追踪责任方会变得特别困难。最后说一个实际建议如果你第一次做这个实验别追求一次到位先把系统内置的AliyunLogReadOnlyAccess挂上跑通链路确认元数据和 SDK 都正常了再改成自定义策略收窄权限。我见过太多同学一上来就写精密的权限 JSON结果某个 Action 名称写错或缺少必要读权限卡在权限排查上大半天。权限本来就是可以动态调整的先放开、再收窄这个节奏更适合线上练手。等整个流程稳定了设计原则会慢慢刻在习惯里以后再遇到其他云产品接入RAM 角色这套思路是可以直接复用的。