传统的DataWorks节点开发模式,在访问OSS等外部服务时,依赖于配置明文AccessKey。这种方式存在安全隐患和管理难题:一方面,永久密钥的硬编码带来泄露风险,一旦泄露将可能导致整个数据资产的暴露;另一方面,由于为每个任务单独管理密钥过于复杂,AccessKey在实践中通常被授予较粗粒度的权限,这使得遵循最小权限原则的精细化访问控制难以落地。为解决这些问题,推荐采用RAM角色授权的方案,它通过动态获取临时凭证(STS)的方式,在杜绝密钥泄露风险的同时,实现按需、按任务的精细化权限管理。
方案说明
整个配置过程分为三个主要部分:创建RAM角色→创建权限策略→授权给RAM用户。
详细原理说明,请参见附录:STS调用流程说明。
权限准备
拥有一个阿里云主账号,或一个被授予 AliyunRAMFullAccess 权限的RAM管理员账号。
步骤一:创建并配置 RAM 角色
此角色是DataWorks服务访问其他云资源的“身份凭证”。
创建RAM角色:登录RAM控制台-角色页面,点击创建角色。 保持默认选项,并单击确认,填写一个有辨识度的角色名称,例如
DataWorksRAMROLEforDataStudio。
修改信任策略:创建成功后,在角色详情页的信任策略页签下编辑,仅允许
dataworks.aliyuncs.com服务可以扮演此角色。策略内容如下:更多信息请参考文档:修改RAM角色的信任策略。

{ "Version": "1", "Statement": [ { "Action": "sts:AssumeRole", "Effect": "Allow", "Principal": { "Service": [ "dataworks.aliyuncs.com" ] } } ] }为RAM角色授权:在角色详情页的权限管理页签下,单击新增授权,按需为
DataWorksRAMROLEforDataStudio角色授予相应的权限。例如,如果需要访问OSS,则可以授予
AliyunOSSReadOnlyAccess(只读)或AliyunOSSFullAccess(完全)权限。更多信息请参考文档:为RAM角色授权。

步骤二:创建权限策略
此策略用于授权RAM用户可以将第一步创建的RAM角色传递给DataWorks服务。
登录RAM控制台-权限策略,单击创建权限策略,切换至脚本编辑,编辑权限策略内容。

{ "Version": "1", "Statement": [ { "Effect": "Allow", "Action": [ "ram:ListRoles" ], "Resource": "*" }, { "Effect": "Allow", "Action": "ram:PassRole", "Resource": "acs:ram::<account-id>:role/<role-name>" } ] }
策略 | 说明 |
| 允许用户查看账户下的角色列表(以便在界面中选择)。 |
| 允许用户将指定的角色传递给云服务。 请务必将策略中的
|
更多信息请参考文档:创建自定义权限策略。
单击确定,将权限策略保存为
DataWorksRAMPolicyforDataStudio。
步骤三:为 RAM 用户授权
这是最后一步,将“允许传递角色”的权力赋予最终用户。
登录RAM控制台-用户页面,找到需要授权的RAM用户(例如
new_ram_user@...),点击操作列的添加权限。在新增授权面板中,搜索并选中步骤二创建的权限策略(
DataWorksRAMPolicyforDataStudio),确认新增授权即可。
若要授权多个RAM用户,需为每一个需要此权限的RAM用户重复执行此步骤。
后续步骤
完成授权后,使用new_ram_user@...账号前往新版数据开发,即可在相关节点使用关联角色运行任务。
支持节点请以实际界面为准。

附录:STS调用流程说明
阿里云RAM提供两种核心的、与角色相关的授权模型:直接扮演(AssumeRole)和委托授权(PassRole)。
模型一:直接扮演 (sts:AssumeRole)
核心动作:一个受信实体(如RAM用户、应用程序)主动调用STS的
AssumeRole接口,以获取一个RAM角色的临时凭证,从而“变身”为该角色。授权链路:
实体A→调用sts:AssumeRole→扮演角色R→获得角色R的权限。权限需求: 实体A本身必须被授予
sts:AssumeRole权限。典型场景: 一个应用程序(运行在ECS或本地服务器上)需要临时访问OSS。该程序使用自身的AK调用
AssumeRole,获取临时凭证后,再用该凭证访问OSS。在此场景中,实体A是主动的执行者。
模型二:委托授权 (ram:PassRole)
核心动作:一个实体(如RAM用户)将一个RAM角色“传递”给一个云服务(如DataWorks、ECS),授权该服务去扮演这个角色。用户本身并不扮演角色。
授权链路:
用户A→传递角色R→给云服务S→云服务S调用sts:AssumeRole扮演角色R→云服务S获得角色R的权限。权限需求:用户A必须被授予
ram:PassRole权限。典型场景:本文档所述的场景。开发者(用户C)在DataWorks控制台配置一个任务,并指定一个角色A。为让DataWorks服务能够代表用户去访问OSS,用户必须有权将角色A“传递”给DataWorks服务。在此场景中,用户是授权者,云服务是代为执行者。
委托授权(PassRole)模型的交互流程分为配置和运行时两个阶段:
配置阶段: 管理员完成基础设置,包括创建角色、配置其权限和信任关系,并为最终用户授予
PassRole权限。运行时阶段:
用户操作与权限传递:用户在DataWorks中指定角色,此操作触发权限传递。DataWorks平台会验证用户是否有权“交出”这个角色。
服务扮演角色:验证通过后,DataWorks后端服务(
dataworks.aliyuncs.com)作为真正的扮演者,向STS发起AssumeRole请求。STS授权与服务执行:STS在确认DataWorks是角色A所信任的服务后,向其颁发临时凭证。DataWorks服务使用此凭证访问OSS,完成用户委托的任务。
