转载 2015年07月09日 14:39:52


CloudStack has a fairly simplistic permissions hierarchy. It consists of:

* Domains
* Accounts
* Users
* Projects


Domains are, more or less, the equivalent of an organizational unit. Domains (generally) don't own resources, but they can impose resource limits upon all accounts held within them. Domains can house projects and accounts, but domains don't really own any instances, volumes, or other resources on their own. A domain is basically a container for other things which can own resources such as instances, volumes, networks, snapshots, templates, etc. Domains must be unique to their parent (ROOT/dom1, ROOT/dom2, etc), however they can repeat if they are a child of another domain (ROOT/dom1/sub1 and ROOT/dom2/sub1 is acceptable even though "sub1" is not unique, it is unique to its parent).

ROOT Domain

The root domain is somewhat special because all domains are a child of this parent domain. An admin account of the ROOT domain has the ability to manipulate (via the API) other resources belonging to all child domains (e.g. ALL domains, because all domains are a child of ROOT). So admin accounts of the ROOT domain have global admin privileges.

Accounts, Account Types, and Users

At the time of writing, Cloudstack doesn't currently support RBAC, so permissions exist at two levels – Admin and User. Account names must be unique to a domain, but not unique to all domains (e.g. joe@foo.tld and joe@bar.tld are acceptable because although "joe" is not unique foo.tld and bar.tld are separate domains).

Admin Account

An admin account has domain admin privileges. It is still constrained to domain limitations set by the ROOT admin on that domain (# of instances permitted, # of volumes, etc) but it has more privileges. For example, a domain admin can create additional accounts within a domain or generate API keys for users. It can also create sub-domains within its own domain and report on their resource utilization. For a full list of the differences, please see the API guide.

User Account

A user account has privileges to create new resources (instances, volumes, snapshots, etc) but very little administrative privileges. At this time, user accounts cannot generate API keys or additional users within their account, they can only view them. For a full list of commands available to users, please consult the API guide.

Usernames, Passwords, and API Keys

Usernames, passwords, and API keys belong to an account. This is the username & password you would log into the Web UI with (and if you generated an API key, the API key you would use for making API calls). Usernames must be unique to the domain they belong to (e.g. two users within the domain foo.tld cannot have the same username – you can't have two joe@foo.tld users), but they can be duplicative between multiple domains (e.g. joe@foo.tld and joe@bar.tld). Users do not own any resources, they are simply used as a means to manipulate and access resources owned by the account they are a part of. Users cannot have separate permissions between them, they inherit the permissions of the account they belong to.

Accounts and Resources

Accounts own resources. This is extremely important so I'll state it again: Accounts own resources. If you delete an account all resources associated with it (instances, volumes, snapshots, etc) will be removed as well. Usage is also tracked at an account level. So for billing or chargeback purposes, if the usage module is enabled, reporting is available for resources used at an account level.


Projects are similar to accounts but unique in one special aspect. Projects can share control of resources amongst multiple accounts. The resources themselves (instances, volumes, snapshots, etc) are owned by the project and are allowed to be manipulated by multiple accounts within the same domain. So if there was a joint project being worked on by multiple departments within an organization a project could be created and could invite other accounts (departments in the organization) to take part in the project. With a project, one account must be delegated as the project administrator. A project admin has the ability to invite and revoke access to other accounts within the domain with regard to access on that project. A project admin only has control of the project and has no other authority over other accounts (e.g. it cannot impose account-level restrictions such as limits on the number of instances, volumes, snapshots, etc permitted), only over which accounts can access the project. While there can only be one project admin, it can be moved between accounts without affecting anything because all resources created by the project are owned by the project and not the individual accounts that are participating in it.


Domain,project,user,role,token 的概念理解

OpenStack 的 Keystone V3 中引入了 Domain 的概念。引入这个概念后,关于 admin 这个role 的定义就变得复杂了起来。  1. Domain,project,u...
  • u010305706
  • u010305706
  • 2017年01月13日 11:43
  • 853

mysql5.7版本开始创建用户需要create user

5.7版本之后,直接使用:grant select on mysql.test01 to hug@localhost; 是不行的,会报错: Error Code: 1133. Can't find ...
  • gcgl000hugang12345
  • gcgl000hugang12345
  • 2016年04月05日 16:36
  • 10080

[问题篇]VMWare搭建Openstack——执行自动化Linux Shell 创建Admin Tenant User报错

最近在写基于OpenStack部署的自动化部署脚本,我没有使用官方推荐的工具,由于目前没有足够多的时间,学习成本比较高,还是自己写Linux Shell来的比较快,而且比较灵活,也不复杂,不过这个东西...
  • chinagissoft
  • chinagissoft
  • 2015年07月15日 08:35
  • 1068

【Ruby on Rails Tutorial笔记】将第一个Rails应用部署到 Heroku实践遇到的问题及解决过程记录

sidewalker@sidewalker-Presario-CQ43-Notebook-PC:~/Documents/rails/sum2014/rails_projects/first_app$ ...
  • u012496650
  • u012496650
  • 2014年08月14日 09:46
  • 1233


  • chenwei8280
  • chenwei8280
  • 2015年06月19日 14:08
  • 449


  • LOVE____JAVA
  • LOVE____JAVA
  • 2013年10月16日 11:14
  • 1684

OpenStack-M版(Mitaka)搭建- – -身份认证服务(Keystone)篇

转载请注明:姬子的博客 » OpenStack-M版(Mitaka)搭建- – -身份认证服务(Keystone)篇 Keystone 作为 OpenStack 的核心组件之一,为...
  • qq_20154221
  • qq_20154221
  • 2016年11月27日 13:20
  • 4168

小议:Domain User无法远程登录Computer

今天在论坛中看到有人提问Domain User无法远程登录Computer的解决方案?依据我的个人经验,可能是Domain User访问该Computer的权限比较少,受了限制。   不是说一...
  • ShelleyLiu0415
  • ShelleyLiu0415
  • 2015年10月30日 10:55
  • 1124

交换机domain 概念详解

交换机是基于域(domain)对用户管理 交换机时基于域对用户进行管理, 在目前AAA的实现中,所有用户都属于某个域。用户属于哪个域是由用户名中带的“@”后的字符串来决定的,比如“user@hua...
  • yiluyangguang1234
  • yiluyangguang1234
  • 2015年12月24日 11:25
  • 1657

几个关于windows domain的概念

Domain controller On Microsoft Servers, a domain controller (DC) is a server that responds to secur...
  • OnlyQi
  • OnlyQi
  • 2014年04月25日 12:14
  • 1794