项目空间内的访问控制分为以下五类:
- 用户管理
- ACL授权
- Policy授权
- 角色管理
- 基于标签的访问控制管理
用户管理
任意非项目空间Owner用户必须被加入MaxCompute项目空间中,并被授予相对应权限,方能操作MaxCompute中的数据、作业、资源及函数。示例如下:
假设Alice创建一个名为WonderLand的项目,自动成为Owner。没有Alice的授权,其他任何人都无法访问WonderLand。
Alice要授权Bob允许他访问WonderLand中的一些对象,操作如下:
- Bob要有一个合法的云账号或者是Alice的RAM子账号。
- Alice要把Bob的账号加到项目中来。
- 赋一些对象的权限给Bob。
注意:
- Alice要禁止Bob访问项目,则直接将他的账号从项目中移除即可。
- Bob虽然被移除出了项目,但他之前被授予的权限仍然保留在项目中。下次一旦他被Alice加入同一个项目,原有的权限将会被自动激活。
RAM子账号管理
RAM子账号分两类,每个项目有不同的RAM子账号,不同的RAM子账号访问交换空间中的内容有一定的区别。
场景描述 | 是否允许 |
---|---|
Alice把云账号Andy加入到Project中 | 允许 |
Alice把她的子账号Tony加入到Project中 | 允许 |
Alice把Andy的子账号daniel加入到Project中 | 不允许 |
授权
授权三要素:主体(Subject)、客体(Object)和操作(Action)。
您可以通过ACL(基于对象)和Policy(基于策略)两种方法进行授权。
ACL授权
ACL授权的基本语法如下:
GRANT <privileges> ON <object> TO <subject>;
REVOKE <privileges> ON <object> FROM <subject>;
示例如下:
假设云账号用户dean@aliyun.com是新加入到项目空间WonderLand的成员。他需要提交作业、创建数据表、查看项目空间已存在的对象。管理员执行的授权操作如下:
use WonderLand; #打开WonderLand项目空间
add user ALIYUN$dean@aliyun.com; #添加用户到项目中
grant CreateInstance on project WanderLand to user ALIYUN$dean@aliyun.com; #对用户进行授权
权限列表如下:
对象类型 | 支持的操作 | 说明 |
---|---|---|
project | Read | 查看项目空间自身(不包括项目空间的任何对象的信息,如CreateTime等) |
project | Write | 更新项目空间自身(不包括项目空间的任何对象的信息,如Comments) |
project | List | 查看项目空间所有类型的对象列表 |
project | CreateTable | 在项目空间中创建Table |
project | CreateInstance | 在项目空间中创建Instance |
project | CreateFunction | 在项目空间中创建Function |
project | CreateResource | 在项目空间中创建Resource |
project | CreateJob | 在项目空间中创建Job |
project | All | 具备上述所有权限 |
Table | Describe | 读取Table的Metadata |
Table | Select | 读取Table的Rows |
Table | Alter | 修改Table的Metadata |
Table | Update | 覆盖或添加Table的Rows |
Table | Drop | 删除Table |
Table | All | 具备上述所有权限 |
Function | Read | 读取 |
Function | Write | 更新 |
Function | Delete | 删除 |
Function | All | 具备上述所有权限 |
Resource Instance Job | Read | 读取 |
Resource Instance Job | Write | 更新 |
Resource Instance Job | Delete | 删除 |
Resource Instance Job | All | 具备上述所有权限 |
授权内容
- 表:授权的对象可以是一张表,也可以是表里面的字段(列)。
- 函数UDF:指用户自定义函数。
- 资源Resource:指用户上传的各种资源文件,例如JAR包、文本文件等。
ACL授权应用场景
项目WonderLand的Owner Alice要给成员Bob授予创建表、查看项目空间内的表、提交作业、读取表userprofile的权限,操作如下:
Use wonderland; #进入项目空间
add user RAM$alice@aliyun.com:bob; #添加用户
grant list,createinstance on project wonderland to user RAM$alice@aliyun.com:bob; #进行命令授权
grant describe,select on table userprofile to RAM$alice@aliyun.com:bob; #授予读取表userprofile的权限
Bob在做数据开发的时候需要用到项目空间已经开发好的UDF getusertype,这个udf使用了资源getusertype.jar,操作如下:
grant read on function getusertype to user RAM$alice@aliyun.com:bob;
grant read on resource getusertype.jar to user RAM$alice@aliyun.com:bob;
Policy
Policy授权机制主要解决ACL授权机制无法解决的一些复杂授权场景,如下所示:
- 一次操作对一组对象进行授权,如所有的函数、所有以 “taobao” 开头的表。
- 带限制条件的授权,如授权只会在指定的时段内才会生效、当请求者从指定的IP地址发起请求时授权才会生效、或者只允许用户使用SQL(而不允许其它类型的Task)来访问某张表。
Policy有RolePolicy和ProjectPolicy两种,基本语法如下:
get policy; #读取项目空间的Policy
put policy <policy file>; #设置(覆盖)项目空间的Policy
get policy on role <role name>; #读取项目空间中某个角色的Policy
put policy <policy file> on role <role name>; #设置(覆盖)项目空间中某个角色的Policy
Policy授权应用场景
项目空间SecretGarden的Dean要让他所在的项目空间的所有成员,都可以使用项目空间里的udf、jar包、python资源,该如何授权?
use SecretGarden; #进入项目空间
put policy ./all_udfs_resources.json #上传Policy配置文件到project resource中
文件内容如下:
"Version": "1",
"Statement":
[{
"Effect":"Allow",
"Principal":"*",
"Action":["odps:Read"],
"Resource":"acs:odps:*:projects/SecretGarden/tables/*"
},
[{
"Effect":"Allow",
"Principal":"*",
"Action":["odps:Read"],
"Resource":"acs:odps:*:projects/SecretGarden/resources/*"
}]
}
ACL与Policy的区别
ACL | Policy | |
---|---|---|
Subject&Object是否必须存在 | 是 | 否 |
删除对象时,是否自动撤销相关授权 | 是 | 否 |
是否支持白名单(Allow)授权 | 是 | 是 |
是否支持黑名单(Deny)授权 | 否 | 是 |
是否支持带限制条件的授权 | 否 | 是 |
是否支持通配符(*) | 否 | 是 |
角色管理
当项目空间内用户比较多时,对用户逐个授权的管理方式会很繁琐。因此MaxCompute提供了角色管理,把一组的授权的操作对象赋予一个角色,再把此角色授权给一个用户,角色(Role)即是一组访问权限的集合。
每一个项目空间在创建时,会自动创建一个admin的角色,并且为该角色授予了确定的权限:可以访问项目空间内的所有对象、对用户或角色进行管理、对用户或角色进行授权。
与项目空间Owner相比,admin角色不能进行以下操作:
- 不能将admin权限指派给用户
- 不能设定项目空间的安全配置
- 不能修改项目空间的鉴权模型
- 不能共享资源
角色的限制:
- admin角色所对应的权限不能被修改。
- 没被使用的角色才可以被删除。
应用场景
Alice的公司有Bob、Tony、Peggy、George等更多数据开发工程师加入,Alice把员工分成不同的部门,每个部门只能访问各自工作范围内的数据。例如希望客户部只能看到customers表,仓储管理部门只能看devices表等,需进行如下操作:
create role customers_mgr;
grant describe,select on table customers to role customers_mgr;
grant customers_mgr to RAM$alice@aliyun.com:peggy;
create role warehouse_mgr;
grant describe,select on table devices to role warehouse_mgr;
grant warehouse_mgr to RAM$alice@aliyun.com:george;
如果仓储管理数据团队也需要访问customers表,则执行下述命令:
grant describe,select on table customers to role warehouse_mgr;
查看权限
MaxCompute支持查看指定用户的权限、查看指定角色的权限、以及查看指定对象的授权列表。
-
查看指定用户的权限:
show grants; show grants for <username>;
-
查看指定角色的权限:
describe role <rolename>;
-
查看指定对象的授权列表:
show acl for <objectName> [on type <objectType>];
基于标签的访问控制
ACL和Policy是数据库比较常见的权限管理模型,MaxCompute除此之外还提供了基于标签的访问控制。它是项目空间级别的一种强制访问控制策略(Mandatory Access Control, MAC),它的引入是为了让项目空间管理员能更加灵活地控制用户对列级别敏感数据的访问。
例如对于一个国家来说(类比MaxCompute的一个项目空间),这个国家公民要想开车(类比读数据操作),必须先申请获得驾照(类比申请SELECT权限)。这些就属于DAC考虑的范畴。
但由于这个国家交通事故率一直居高不下,于是该国新增了一条法律:禁止酒驾。此后,所有想开车的人除了持有驾照之外,还必须不能喝酒。类比MaxCompute,这个禁止酒驾就相当于禁止读取敏感度高的数据。这就属于MAC考虑的范畴。
注意:
- select table时才检查label。
- 检查完label后,下面的acl、policy的权限仍需要验证。
数据的敏感等级分类
Project Owner需要定义明确的数据敏感等级和访问许可等级划分标准,默认时所有用户的访问许可等级为0级,数据安全级别默认为0级。
LabelSecurity对敏感数据的粒度可以支持列级别,管理员可以对表的任何列设置敏感度标记(Label),一张表可以由不同敏感等级的数据列构成。
LabelSecurity基本操作
操作 | 命令 |
---|---|
打开LabelSecurity安全机制开关 | Set LabelSecurity=true/false; |
设置用户安全许可标签 | SET LABEL TO USER ; |
设置数据敏感等级标签 | SET LABEL TO TABLE tablename[(column_list)]; |
显示授权低级别用户访问高敏感数据 | GRANT LABEL ON TABLE [(column_list)] TO USER [WITH EXP ]; |
撤销显示授权 | revoke label on table [(column_list)] from user |
查看一个用户能访问哪些敏感数据集 | show label [] grants [for user ]; |
查看一个敏感数据表能被哪些用户访问 | show label [] grants on table ; |
用户对指定表上列级别的Label授权 | show label [] grants on table for user ; |
包安装者对包中敏感资源许可访问级别 | allow project to install package [using label ]; |