警告
NOTICE: THIS DOCUMENTATION SITE HAS BEEN SUPERSEDED.
For the current documentation site goto: http://docs.cloudstack.apache.org
A role represents a set of allowed functions. All CloudStack accounts have a role attached to them that enforce access rules on them to be allowed or disallowed to make an API request. Typically there are four default roles: root admin, resource admin, domain admin and user.
一个账户通常代表一个客户的服务提供者或一个大组织中的一个部门。一个账户可存在多个用户。
帐户通常按域进行分组。域中经常包含多个账户,这些账户间存在一些逻辑上关系和一系列该域和其子域下的委派的管理员(这段的意思就是说在逻辑上域下可以有管理员,子域下也可以有管理员)。比如,一个服务提供商可有多个分销商这样的服务提供商就能为每一个分销商创建一个域
对于每个账户的创建,Cloud的安装过程中创建了三种不同类型的用户账户:根管理员,域管理员,普通用户。
用户就像是账户的别名。在同一账户下的用户彼此之间并非隔离的。但是他们与不同账户下的用户是相互隔离的。大多数安装不需要用户的表面概念;他们只是每一个帐户的用户。同一用户不能属于多个帐户。
多个账户中的用户名在域中应该是唯一的。相同的用户名能在其他的域中存在,包括子域。域名只有在全路径名唯一的时候才能重复。比如,你能创建一个root/d1,也可以创建root/foo/d1和root/sales/d1。
管理员在系统中是拥有特权的账户。可能有多个管理员在系统中,管理员能创建删除其他管理员,并且修改系统中任意用户的密码。
域管理员可以对属于该域的用户进行管理操作。域管理员在物理服务器或其他域中不可见。
根管理员拥有系统完全访问权限,包括管理模板,服务方案,客户服务管理员和域。
资源属于帐户,而不是帐户中的单个用户。例如,账单、资源限制等由帐户维护,而不是用户维护。用户有权限操作任何在帐户中提供的资源。权限有角色决定。根管理员通过使用assignVirtualMachine API可以将任何虚拟机的所有权从一个帐户调整到另一个帐户。域或子域管理员可以对域中的VMs做同样的操作,包括子域。
In addition to the four default roles, the dynamic role-based API checker feature allows CloudStack root admins to create new roles with customized permissions. The allow/deny rules can be configured dynamically during runtime without restarting the management server(s).
For backward compatiblity, all roles resolve to one of the four role types: admin, resource admin, domain admin and user. A new role can be created using the roles tab in the UI and specifying a name, a role type and optionally a description.
Role specific rules can be configured through the rules tab on role specific details page. A rule is either an API name or a wildcard string that are one of allow or deny permission and optionally a description.
When a user makes an API request, the backend checks the requested API against configured rules (in the order the rules were configured) for the caller user-account’s role. It will iterate through the rules and would allow the API request if the API matches an allow rule, else if it matches a deny rule it would deny the request. Next, if the request API fails to match any of the configured rules it would allow if the requested API’s default authorized annotaions allow that user role type and finally deny the user API request if it fails to be explicitly allowed/denied by the role permission rules or the default API authorize annotations. Note: to avoid root admin being locked out of the system, all root admin accounts are allowed all APIs.
The dynamic-roles feature is enabled by default only for all new CloudStack installations since version 4.9.x.
In 4.11.x and above, existing deployment without any commands.properties file will be automatically migrated to dynamic roles. Admins may also enable dynamic roles by setting the global setting ‘dynamic.apichecker.enabled’ to true.
After an upgrade, admins can also use this migration tool to migrate old rules
from commands.properties file(s):
/usr/share/cloudstack-common/scripts/util/migrate-dynamicroles.py
.
During migration, this tool enables the global setting in the database and
copies existing static role-based rules from provided commands.properties file
(typically at /etc/cloudstack/management/commands.properties
) to the database
and renames the commands.properties file (typically to
/etc/cloudstack/management/commands.properties.deprecated). The migration
process does not require restarting the management server(s).
Usage: migrate-dynamicroles.py
[options] [-h for help]
Options:
-b DB | The name of the database, default: cloud |
-u USER | User name a MySQL user with privileges on cloud database, default: cloud |
-p PASSWORD | Password of a MySQL user with privileges on cloud database |
-H HOST | Host or IP of the MySQL server |
-P PORT | Host or IP of the MySQL server, default: 3306 |
-f FILE | The commands.properties file, default: /etc/cloudstack/management/commands.properties |
-D | Use the default role-rule permissions, and only enable dynamic roles |
-d | Dry run and debug operations this tool will perform |
Examples:
sudo python /usr/share/cloudstack-common/scripts/util/migrate-dynamicroles.py -u cloud -p cloud -H localhost -P 3006 -f /etc/cloudstack/management/commands.properties
sudo python /usr/share/cloudstack-common/scripts/util/migrate-dynamicroles.py -u cloud -p cloud -H localhost -P 3006 -D
If you’ve multiple management servers, remove or rename the commands.properties file on the management servers typically in /etc/cloudstack/management path, after running the migration tool for the first management server.
根管理员可以将资源分配给指定的域或为了保证额外的安全或性能从而需要单独基础架构帐户。为了一个指定的域或账号,区域、机架、群集或者主机可以被根管理员保留。只有域或它的子域中的用户可以使用这个基础架构。比如,只有域中的用户可以在其中的区域中创建来宾虚机。
这里有几种有效的分配方式:
对于明确的专用:当部署一个新的区域、机架、群集或者主机的时候,根管理员可以点击Dedicated选框,然后选择域或者帐户来拥有这些资源。
对于明确的专用一个已存在的区域、机架、群集或者主机:使用根管理员登录,在UI中找到资源,然后点击Dedicate按钮。
对于隐式的专用:管理员创建的计算服务方案和在部署规划区域选择ImplicitDedicationPlanner。然后在规划模型中,管理员按照是否允许一些人当没有专用资源可用的时候使用共享资源来选择严格的或者优先的。无论何时,用户基于这个服务方案创建的VM都会位于专用主机。
要使用明确专用主机,在关联组 (参阅 “关联组”)中选择explicit-dedicated 类型。比如,当创建新VM的时候,终端用户可以选择将其运行在专用基础架构上。如果一些基础架构已经被分配给专用的用户帐号或域,那么这个操作才能成功。
管理员可以将VMs从专用主机上迁移到任何想要的地方,不管目标主机是不同帐号/域专用的还是共享的主机(不对任何特殊帐号或域专用)。CloudStack将生成一个警告,不过操作还是允许的。
专用主机可用主机标签连接。如果同时需要主机标签和专用,那么VM将只会在匹配所有需求的主机上运行。如果没有专用资源可用于这类用户,那么VM就不会被不部署。
如果你删除了一个指定了专用资源的帐号或者域,那么其中的任何主机、群集、机架和区域就会被释放。它们会变成可被任何帐户或者域共享,或者管理员可选择重新把它们指定给不同的帐号或域。
系统VMs和虚拟路由器影响专用主机的行为。系统VMs和虚拟路由器由CloudStack系统账号拥有,并且它们可在任何主机上部署。它们不会伴随着明确专用主机。主机上的系统虚机和虚拟路由器使其不再适合作为严格的潜在专用主机。主机之所以不能用于严格的潜在专用主机,是因为主机已经有针对帐号(默认系统账号)的VMs。尽管如此,运行着系统VMs或虚拟路由器的主机可以被用于优先的潜在专用。
You can use an external LDAP server such as Microsoft Active Directory or ApacheDS to authenticate CloudStack end-users. CloudStack will search the external LDAP directory tree starting at a specified base directory and gets user info such as first name, last name, email and username.
To authenticate, username and password entered by the user are used. Cloudstack does a search for a user with the given username. If it exists, it does a bind request with DN and password.
To set up LDAP authentication in CloudStack, call the CloudStack API
command addLdapConfiguration
and provide Hostname or IP address
and listening port of the LDAP server. You could configure multiple
servers as well. These are expected to be replicas. If one fails,
the next one is used.
The following global configurations should also be configured (the default values are for openldap)
ldap.basedn
: Sets the basedn for LDAP. Ex: OU=APAC,DC=company,DC=comldap.bind.principal
, ldap.bind.password
: DN and password for a user
who can list all the users in the above basedn. Ex:
CN=Administrator, OU=APAC, DC=company, DC=comldap.user.object
: object type of users within LDAP. Defaults value is
user for AD and inetorgperson for openldap.ldap.email.attribute
: email attribute within ldap for a user. Default
value for AD and openldap is mail.ldap.firstname.attribute
: firstname attribute within ldap for a user.
Default value for AD and openldap is givenname.ldap.lastname.attribute
: lastname attribute within ldap for a user.
Default value for AD and openldap is sn.ldap.username.attribute
: username attribute for a user within LDAP.
Default value is SAMAccountName for AD and uid for openldap.ldap.search.group.principle
: this is optional and if set only users from
this group are listed.If the LDAP server requires SSL, you need to enable the below configurations. Before enabling SSL for LDAP, you need to get the certificate which the LDAP server is using and add it to a trusted keystore. You will need to know the path to the keystore and the password.
ldap.truststore
: truststore pathldap.truststore.password
: truststore passwordldap.group.object
: object type of groups within LDAP. Default value is
group for AD and groupOfUniqueNames for openldap.ldap.group.user.uniquemember
: attribute for uniquemembers within a group.
Default value is member for AD and uniquemember for openldap.Once configured, on Add Account page, you will see an “Add LDAP Account” button which opens a dialog and the selected users can be imported.
You could also use api commands: listLdapUsers
, ldapCreateAccount
and
importLdapUsers
.
Once LDAP is enabled, the users will not be allowed to changed password directly in cloudstack.
You can use a SAML 2.0 Identity Provider with CloudStack for user
authentication. This will require enabling the SAML 2.0 service provider plugin
in CloudStack. To do that first, enable the SAML plugin by setting
saml2.enabled
to true
and restart management server.
Starting 4.5.2, the SAML plugin uses an authorization workflow where users should
be authorized by an admin using authorizeSamlSso
API before those users can
use Single Sign On against a specific IDP. This can be done by ticking the enable
SAML Single Sign On checkbox and selecting a IDP when adding or importing users.
For existing users, admin can go to the user’s page and click on configure
SAML SSO option to enable/disable SSO for a user and select a Identity Provider.
A user can be authorized to authenticate against only one IDP.
The CloudStack service provider metadata is accessible using the
getSPMetadata
API command, or from the URL
http://acs-server:8080/client/api?command=getSPMetadata where acs-server is the
domain name or IP address of the management server. The IDP administrator can
get the SP metadata from CloudStack and add it to their IDP server.
To start a SAML 2.0 Single Sign-On authentication, on the login page users need to
select the Identity Provider or Institution/Department they can authenticate with
and click on Login button. This action call the samlsso
API command which
will redirect the user to the Identity Provider’s login page. Upon successful
authentication, the IdP will redirect the user to CloudStack. In case a user has
multiple user accounts with the same username (across domains) for the same
authorized IDP, that user would need to specify domainpath after selecting their
IDP server from the dropdown list. By default, users don’t need to specify any
domain path. After a user is successfully authenticated by an IDP server, the SAML
authentication plugin finds user accounts whose username match the username
attribute value returned by the SAML authentication response; it fails
only when it finds that there are multiple user accounts with the same user name
for the specific IDP otherwise the unique useraccount is allowed to proceed and
the user is logged into their account.
Limitations:
The following global configuration should be configured:
saml2.enabled
: Indicates whether SAML SSO plugin is enabled or not true. Default is falsesaml2.sp.id
: SAML2 Service Provider Identifier stringsaml2.idp.metadata.url
: SAML2 Identity Provider Metadata XML Url or Filename. If a URL is not provided, it will look for a file in the config directory /etc/cloudstack/managementsaml2.default.idpid
: The default IdP entity ID to use only in case of multiple IdPssaml2.sigalg
: The algorithm to use to when signing a SAML request. Default is SHA1, allowed algorithms: SHA1, SHA256, SHA384, SHA512.saml2.redirect.url
: The CloudStack UI url the SSO should redirected to when successful. Default is http://localhost:8080/clientsaml2.sp.org.name
: SAML2 Service Provider Organization Namesaml2.sp.org.url
: SAML2 Service Provider Organization URLsaml2.sp.contact.email
: SAML2 Service Provider Contact Email Addresssaml2.sp.contact.person
: SAML2 Service Provider Contact Person Namesaml2.sp.slo.url
: SAML2 CloudStack Service Provider Single Log Out URLsaml2.sp.sso.url
: SAML2 CloudStack Service Provider Single Sign On URLsaml2.user.attribute
: Attribute name to be looked for in SAML response that will contain the username. Default is uidsaml2.timeout
: SAML2 IDP Metadata refresh interval in seconds, minimum value is set to 300. Default is 1800