学习阿里云的访问控制

我们使用访问控制策略来描述如何保护系统中的资源, 准许执行哪些操作, 禁止执行哪些操作. 本文从常见的访问控制策略入手, 逐步了解阿里云平台的访问控制策略表达方法.

常见的访问控制

不同的系统, 根据系统所管理的资源及所支持的操作的特性, 采取了不同的访问控制策略.

Linux文件访问控制

熟悉Linux的朋友都知道文件的访问控制，可以给用户、组及其他用户不同的读、写、执行权限。

$ ls -ltotal 0-rw-r--r--  1 gang  wheel  0 May 18 08:47 file1.txt-rw-r--r--  1 gang  wheel  0 May 18 08:47 file2.txt-rwxr-xr-x  1 gang  wheel  0 May 18 08:47 file3.sh-rwxr--r--  1 gang  wheel  0 May 18 08:47 file4

对file1.txt和file2.txt，用户gang 有读写权限；其他用户有只读权限；

对file3.sh，用户gang有读写和执行权限；其他用户有读和执行的权限；

对于file4，用户gang有读写和执行权限；其他用户有只读权限。

SQL数据库访问控制

熟悉SQL的朋友都知道数据库的访问控制，可以给不同的数据库对象以不同的操作权限。

GRANT SELECT, INSERT, UPDATE, DELETE on 
    
     .
     
      @
      
       ;
      
     
     
       to

上述语句授予了来自Host的用户User，对于数据库DB中的表Table的增删改查操作权限。

云平台访问控制

相比单个文件系统和单个数据库，云平台中的资源有以下特征

资源分散在不同区域的数据中心中。

资源种类更多。比如ECS虚拟机，RDB数据库，NoSQL数据库，FaaS等。

不同类型的资源，可以执行的操作不同。

第一个特征和第二个决定了我们在定位资源时，要比Linux文件系统及数据库表更复杂。从逻辑上来说，应该包括区域，服务类型，租户和服务实例。包含租户，是因为云平台都是多租户隔离的，服务实例运行在租户（逻辑上）隔离的环境中。

第三个特征决定了我们在授予用户操作权限时，可授权的操作是由服务类型决定的。

假如我们有以下的授权需求：

"允许租户A(TenantA)的用户User1重启(Reboot)该租户位于北京区域(cn-beijing)的ECS实例Instance-01"

如果用类似SQL的语法来表达如下：

GRANT ECS_Reboot on 'cn-beijing'.'ECS'.'TenantA'.'Instance-01' to 'User1'@'TenantA'

云平台的访问控制服务所采纳的语法是基于JSON格式的. JSON格式对于互联网开发者而言更常用 -- 绝大部分的互联网API的请求和响应格式都是JSON.

我们把上述SQL格式的授权, 翻译为JSON格式的:

{"Resources": ["'cn-beijing'.'ECS'.'TenantA'.'Instance-01'" ],"Actions": [ "ECS_Reboot"],"Users": ["User1@TenantA"]}

一方面, 同样的访问控制策略, 既可以赋给用户A, 也可以赋给用户B; 另一方面, 用户A可能的权限可能同时由多个访问控制策略所共同决定. 因此, 我们应该把访问控制策略独立出来.

访问控制策略:

{"Id": "Policy-1","Resources": ["cn-beijing.ECS.TenantA.Instance-01" ], "Actions": [ "ECS_Reboot"]},{"Id": "Policy-2","Resources": ["cn-shanghai.OSS.TenantA.MyFiles"],"Actions": ["OSS_View", "OSS_Create"]}

我们称用户被授予访问控制策略的过程叫做用户与访问控制策略的绑定.

{"Binding": {   "User": "User1@TenantA",   "Policies": ["Policy-1", "Policy-2"]}}

本文的重点是访问控制策略. 因此, 让我们把绑定的事情先放一放.

首先, 我们上面只说了正向的"准许"的访问权限, 那么我们能不能反向"拒绝"呢? 假设某个服务实例S的大部分操作, 我们都想赋给用户U, 只有很少的操作(X, Y)不能给他(她). 这种情况下, 与其列出准许的操作, 不如列出拒绝的操作.

{ "Id": "Policy-3","Statements": [  {     "Effect": "Allow",    "Resources" : ["S"],    "Actions" : [ "*" ]  },  {     "Effect": "Deny",    "Resources": ["S"],    "Actions": ["X", "Y"]  } ]}

由于默认情况下是没有授权的, 因此, 我们需要增加一个表示允许全部授权的规则, 然后再加上拒绝的规则. 这也意味着, "拒绝"规则的效力是高于"准许"规则的. 由于我们申明有了两(多)个规则, 因此, 增加一个"Statements"数组来表达它们.

其次, 作为一个平台, 我们将来可能会引入更多的策略表达能力, 因此, 我们需要引入策略规则版本的概念.

{ "Id": "Policy-3", "Version": "1.0","Statements": [  {     "Effect": "Allow",    "Resources" : ["S"],    "Actions" : [ "*" ]  },  {     "Effect": "Deny",    "Resources": ["S"],    "Actions": ["X", "Y"]  } ]}

阿里云平台的访问控制

让我们拿一个真正的阿里云访问控制策略的例子来对比一下上面我们自己假想的访问控制策略.

{"Version": "1", "Statement": [  {     "Effect": "Allow",    "Resource" : ["acs:ecs:*:*:instance/inst-001", "acs:ecs:*:*:instance/inst-002"],    "Action" : [ "ecs:*" ]  },  {     "Effect": "Deny",    "Resource": ["acs:ecs:*:*:instance/inst-001","acs:ecs:*:*:instance/inst-002"],    "Action": ["ecs:Delete*", "ecs:Modify*", "ecs:Re*"]  } ]}

差别在哪里?

阿里云采用了单数表达法. 我们前面使用的是"Statements", "Resources", "Actions", 在阿里云中实际上是"Statement", "Resource", "Action".

阿里云中的全局资源名称中,各个部分之间的分隔符是冒号":"而不是点".", 而且统一使用了小写的名称, 它的一般写法是"acs:<service-name>:<region>:<account>:<instance>". 其中, acs代表阿里云; service-name代表阿里云所提供的云服务的名字(英文代码), region表示数据中心区域(英文代码); account代表我们的账号ID; instance代表服务实例的ID.

服务的全局操作名称也是使用了冒号来分割服务名称和操作名称, 它的一般写法是"<service-name>:<API name>|<API name starts with (*) >"

参考阿里云的帮助文档, 我们可以发现阿里云的访问策略语法功能更丰富.

练习

设想以下场景：

我们团队有两个项目P1和P2，项目人员有产品工程师，开发工程师，测试工程师，运维工程师。其中项目的产品工程师是只负责各自的项目，开发工程师，测试工程师和运维工程师则同时参与两个项目中。我们为每个项目分别申请了一台测试机器，两台生产机器以及一个测试RDB数据库和一个高可用生产RDB数据库。测试环境的机器，开发工程师和开发工程师都可以查看和重启。生产环境的机器，只有运维工程师可以查看和重启。产品工程师只能查看所负责项目. 这个需求怎么用阿里云的访问控制策略实现?

项目P1:

P1-Test-App1, 用于测试环境的应用程序节点

P1-Test-RDB1, 用于测试环境的RDB数据库

P1-Prod-App1, P1-Prod-App2 用于生产环境的应用程序节点

P1-Prod-RDB1 用于生产环境的高可用版本的RDB数据库

项目P2:

P2-Test-App1, 用于测试环境的应用程序节点

P2-Test-RDB1, 用于测试环境的RDB数据库

P2-Prod-App1, P2-Prod-App2 用于生产环境的应用程序节点

P2-Prod-RDB1 用于生产环境的高可用版本的RDB数据库

参考文档

阿里云访问控制策略. 语法结构: 基本元素: 权限规则:

阿里云ECS鉴权:

阿里云RDB鉴权: