keystone中的domain

相关对象

Keystone中当前和domain相关的对象有user，project，group和token，其中user，project和group从sql driver看，这三个模型的name字段都和domain_id一起作为联合唯一键在数据库层面增加了约束。

token比较特殊，获取V3 token的时候有一个可选参数scope，来指定需要获取什么样scope的token，可以参考keystone V3 API。

获取token的时候，scope分为三种：

• domain
• project
• trust

其实最终keystone内部处理的时候，也会把trust转化为project。又因为获取token的时候，scope是可选参数，可以不填，所以还可以获取一种特殊的不关联scope的token，这种token的唯一的目的也就是确认一个唯一的用户。

token实际的scope最终转化为两种domain和project。

授权

keystone的授权（create_grant）过程，其实是一个三方关联的过程，三方就是：actor（被授权的主体），role（权限），target（被授权的范围）。实际授权过程可以这样理解：

为actor在target的范围内赋予role的权利。

• actor -> user & group
• targe -> project & domain
• role

再说回来，domain scope token包含的roles，就是这个domain范围内的所有这个user相关的role，其中包括user本身和user所属的group的role的一个并集。而project scope token包含的roles，同上，就是范围变成了project相关的role。

怎么用domain

keystone默认的policy.json，其实是拥有admin角色的用户可以做任何的事情，可以在domainA中创建project，也可以在domainB中创建project，这样就无法做到，限制domain内的admin只可以在所属domain内创建project，也就是domain admin的概念，为了弥补这一问题，keystone引入了policy.v3cloudsample.json。

我们来分析一下是怎么做到的，来看其中的一段例子，摘自policy.v3cloudsample.json

1 "admin_required": "role:admin",
2 
3 "identity:create_project": "rule:admin_required and domain_id:%(project.domain_id)s",
4 
5 "identity:get_project": "rule:admin_required and domain_id:%(target.project.domain_id)s",
6 
7 "identity:list_projects": "rule:admin_required and domain_id:%(domain_id)s",

先来看create_project，首先要求admin角色，需要注意的是and的后半句domain_id:%(project.domain_id)s，这条规则的意思就是create_project时，使用的token的domain_id必须等于project所在的domain的domain_id。

也就是如下场景：

1. 为userA在domainA的范围内赋予admin的权限
2. userA指定domainA作为scope，申请一个domainA scope的tokenA
3. userA使用tokenA，去创建project，创建project时domain_id参数必须为domainA的id
4. 创建project成功

这里有几个关键点需要注意，首先userA在domainA内必须要有admin权限，这样才能满足rule:admin_required，其次，token需要是一个domain scope的token，这样token中才会有domain_id ，再次，创建project的时候，domain_id参数必须等于domainA的id，这样才能满足domain_id:%(project.domain_id)s。

这样一条规则的意义在于，可以限制只有在domainA内有权限的用户才能在domainA创建project。

get_project比较好理解，就是查询的project的domain_id必须和token的domain_id相同，也就是只能查询token所在范围内的project。

list_project是查询出所有的project，但是会根据token的domain_id过滤，然后剩下所有和token的domain_id相同的project。

keystone增加了domain这样一个概念之后，其实也就把keystone本身的资源user、project、group按照domain给做了一个划分，可以做到在domain范围内的对于user、project和group的管理。

policy.v3cloudsample.json中又增加了几种的权限规则，例如：cloud_admin、domain_admin、project_domain。大家可以自己结合policy.v3cloudsample.json来看一下它们各自的作用。

 1 "admin_required": "role:admin",
 2 
 3 "cloud_admin": "rule:admin_required and domain_id:admin_domain_id",
 4 
 5 "service_role": "role:service",
 6 
 7 "service_or_admin": "rule:admin_required or rule:service_role",
 8 
 9 "owner" : "user_id:%(user_id)s or user_id:%(target.token.user_id)s",
10 
11 "admin_or_owner": "(rule:admin_required and domain_id:%(target.token.user.domain.id)s) or rule:owner",
12 
13 "admin_or_cloud_admin": "rule:admin_required or rule:cloud_admin",
14 
15 "user_domain_id": "domain_id:%(target.user.domain_id)s or domain_id:%(user.domain_id)s",
16 
17 "project_domain_id": "domain_id:%(target.project.domain_id)s or domain_id:%(project.domain_id)s",
18 
19 "groups_domain_id": "domain_id:%(group.domain_id)s or domain_id:%(target.group.domain_id)s",
20 
21 "same_domain_id": "domain_id:%(domain_id)s or domain_id:%(target.domain.id)s",
22 
23 "match_domain_id": "rule:same_domain_id or rule:user_domain_id or rule:project_domain_id or rule:groups_domain_id",
24 
25 "domain_admin": "rule:admin_required and rule:match_domain_id",
26 
27 "project_admin": "rule:admin_required and project_id:%(target.project.id)s",

具体policy规则的配置可以参考keystone的官方文档