在MaxCompute中配置Policy策略遇到结果不一致的问题

背景信息:

本文以以下场景为基准进行编写,以下:json

  1. 用户经过DataWorks-简单模式使用MaxCompute;
  2. 用户具备DataWorks默认角色,如DataWorks开发者角色;
  3. 用户经过console提交policy配置精细化权限管控,

本案例以禁止某一些用户群体(role)能够删除以tb_开头的表为例来展开讨论。测试

解决方案:

经过policy进行deny某个role禁止删除以tb_开头的表,同时将属于这一部分的user都添加到该角色中。
具体以下:spa

  1. create role denydroprole;
  2. put policy t_policy.json on role ``denydroprole;
  3. grant ``denydroprole to user RAM$..;

t_policy.json配置文件以下:3d

{
    "Version": "1",
    "Statement": [{
        "Effect": "Deny",
        "Action": "odps:Drop",
        "Resource": "acs:odps:*:projects/sz_mc/tables/tb_*"
    }]
}

查看上述配置的子帐号权限:code

针对上图的说明:blog

  1. [roles]该子帐号同事隶属与两个角色,一个是新建的denydroprole,一个是DataWorks的开发者角色role_project_dev。
  2. [Authorization Type: Policy]其中A表明Allow,D表明Deny,当二者同事存在时,deny优先原则。

是否符合预期:

(1)在DataWorks上进行测试:项目管理

竟然删除成功了!!!纳尼,是咱们配置策略不对嘛???开发

(2)再在console上进行验证:get

在MaxCompute console上测试策略生效了,删除以tb_开头的表直接被拒绝而且返回错误。io

这是为何呢??为何呢??
其实在这一块须要注意的是,在DataWorks-工做空间配置-计算引擎信息-访问身份()配置状况。

访问身份大科普:

这个要看下咱们在项目管理里面的帐号设置是我的帐号仍是系统帐号。两个最大的区别以下:
dataworks这里的角色,会有两种权限,一种是dataworks界面操做权限,一种是MaxCompute数据相关权限(建表、查询等)。

而后有两种状况:

1)若是MaxCompute访问身份为 我的帐号,那么角色的“MaxCompute数据相关权限”就会生效,这个子帐号用其余客户端操做MaxCompute均可以有这个project的相关权限。

2)若是MaxCompute访问身份为 系统帐号,那么角色的“MaxCompute数据相关权限”就不会生效,这个子帐号在dataworks上提交的MaxCompute任务由于是经过系统帐号提交因此只要系统帐号有权限就能够。可是子帐号用非dataworks的客户端提交MaxCompute就会没权限。
详情能够参考:https://yq.aliyun.com/articles/686800

对应以下逻辑示意图:

那么,到这里亲们应该明白了,为何在DataWorks中测试发现policy策略没有生效么?是由于配置的访问身份为系统帐号,那么经过DataWorks提交的Query都会用系统帐号来执行(project owner拥有最大权限且并无受到该policy限制)。

你只须要在这里设置为【我的帐号】便可知足上述需求。

 



本文做者:祎休

原文连接

本文为云栖社区原创内容,未经容许不得转载。

相关文章
相关标签/搜索