转载 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.



Project Management Account

  • 2010-12-27 12:07
  • 997KB
  • 下载

oracle user account

转载: Oracle的用户帐户管理里面大有学问了, 控制非常灵活, 设计非常精巧, 如果我们能够在我们自己的数据库...

Win7禁用UAC(User Account Control,用户帐户控制)设置

UAC简介: UAC(User Account Control,用户帐户控制)是微软为提高系统安全而在Windows Vista中引入的新技术,它要求用户在执行可能会影响计算机运行的操作或执行更改影...

User Account Management

User Account Management When a user connects to your Red Hat Directory Server (Directory Server), fi...

Windows Vista for Developers——第四部分:用户帐号控制(User Account Control,UAC)

转自: Windows Vista for Developers——...

SQL Server 2008 User Account Create (For Frank's website)

After open SQL server 2008: click the Security --> Login --> new Login --> give the login name and ...

创建Predix UAA(User Account and Authentication)

作者:唐翊国,开发者生态资深经理,GE数字集团 23年工作经验,长期在杜邦、欧文斯科宁、庄信万丰等从事制造业信息化工作,规划、实施了大量MES、SAP ERP、LIMS、BPM等项目,积累了丰富的制造...

User Account Management

User Account Management When a user connects to your Red Hat Directory Server (Directory Server), fi...