项目的层级化,或者说是嵌套化,可以在横向上缩小了资源的管理维度,以更贴合实际业务的形式进行了资源的隔离;子项目对自己的资源有了更高的自由度,父项目的管理就得到了大大的简化。

Keystone V3 API支持子项目,下面从概念以及实际的业务逻辑看看子项目是什么样的。

基本概念

Domain

Domain是V3中增加的一个概念,作为project上层的容器,云平台的客户应当是一个Domain的所有者。Domain中可以包含project,user,group(这三种类型的对象都只能属于一个Domain)。客户在自己的Domain中可以随意创建项目、用户组、用户以及定义角色。

Project

Project是一系列资源的集合,项目中的用户以及组可以根据自身的角色以及配额使用项目中的资源。在V2中

Group

组是用户的集合,可以对一个组进行角色的分配,这样组内的所有用户都具有了相同的角色,便于对用户的统一划分和管理。

User

字面意思就是用户,这里的用户不仅仅指某个人,也可以是一个服务、一个系统,总的说就是使用了openstack服务的对象。

Role

角色用来分配给用户,使用户具有一定对资源的使用权限。

Project,Group,User,Role都只能属于一个Domain。

Use Case

nested_user_case

  • 云平台客户为New公司,也是Domain的所有者
  • New公司根据需求,在Domain中创建三个项目:市场、销售、技术
  • 技术部门在自己的项目内创建两个子项目:运维、研发
  • 研发也可以根据实际需求创建子项目:A、B
  • 创建管理员组,将管理员用户添加到管理员组中,并分配管理员角色,将管理员组映射到Domain中,这时管理员组中的用户都具备了Domain的管理员权限,可以对所有的资源进行管理
  • 创建用户组A,将相关用户加到A组中,分配其工程师角色,并将A组映射到项目A中,这样A组的用户只能操作A项目的资源,其他项目对A组的用户是不可见的

待解决

  1. 目前M版的openstack的nova组件还没有实现对子项目的配额的支持
  2. horizon不能表现出子项目的逻辑关系

实际上第一个待解决的问题是一个关键性的问题,如果只有当前的逻辑模型,而没有实现嵌套配额,那么子账户的功能就丧失了一大半,就我所知,目前只有cinder完成了嵌套配额的功能。社区已经有 相关的代码提交了,不知什么时候能完成啊。