背景信息：

本文以如下场景为基准进行编写，如下：

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

本案例以禁止某一些用户群体（role）可以删除以tb_开头的表为例来展开讨论。

解决方案：

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

具体如下：

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

t_policy.json配置文件如下：

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

查看上述配置的子账号权限：

针对上图的说明：

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

是否符合预期：

（1）在DataWorks上进行测试：

居然删除成功了！！！纳尼，是我们配置策略不对嘛？？？

（2）再在console上进行验证：

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

这是为什么呢？？为什么呢？？

其实在这一块需要注意的是，在DataWorks-工作空间配置-计算引擎信息-访问身份（）配置情况。

访问身份大科普：

这个要看下我们在项目管理里面的账号设置是个人账号还是系统账号。两个最大的区别如下：

dataworks这里的角色，会有两种权限，一种是dataworks界面操作权限，一种是MaxCompute数据相关权限（建表、查询等）。

然后有两种情况：

1）如果MaxCompute访问身份为 个人账号，那么角色的“MaxCompute数据相关权限”就会生效，这个子账号用其他客户端操作MaxCompute都可以有这个project的相关权限。

2）如果MaxCompute访问身份为 系统账号，那么角色的“MaxCompute数据相关权限”就不会生效，这个子账号在dataworks上提交的MaxCompute任务因为是通过系统账号提交所以只要系统账号有权限就可以。但是子账号用非dataworks的客户端提交MaxCompute就会没权限。

详情可以参考：

对应如下逻辑示意图：

那么，到这里亲们应该明白了，为什么在DataWorks中测试发现policy策略没有生效么？是因为配置的访问身份为系统账号，那么通过DataWorks提交的Query都会用系统账号来执行（project owner拥有最大权限且并没有受到该policy限制）。

你只需要在这里设置为【个人账号】即可满足上述需求。

 

---

本文作者：祎休

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