|
14 | 14 | under the License.
|
15 | 15 |
|
16 | 16 |
|
17 |
| -Managing Accounts, Users and Domains |
18 |
| -==================================== |
| 17 | +Managing Roles, Accounts, Users and Domains |
| 18 | +=========================================== |
| 19 | + |
| 20 | +Roles, Accounts, Users, and Domains |
| 21 | +----------------------------------- |
| 22 | + |
| 23 | +Roles |
| 24 | +~~~~~ |
| 25 | + |
| 26 | +A role represents a set of allowed functions. All CloudStack accounts have a |
| 27 | +role attached to them that enforce access rules on them to be allowed or |
| 28 | +disallowed to make an API request. Typically there are four default roles: |
| 29 | +root admin, resource admin, domain admin and user. |
19 | 30 |
|
20 |
| -Accounts, Users, and Domains |
21 |
| ----------------------------- |
22 | 31 |
|
23 | 32 | Accounts
|
24 | 33 | ~~~~~~~~
|
@@ -92,6 +101,77 @@ administrator can do the same for VMs within the domain from one account
|
92 | 101 | to any other account in the domain or any of its sub-domains.
|
93 | 102 |
|
94 | 103 |
|
| 104 | +Using Dynamic Roles |
| 105 | +------------------- |
| 106 | + |
| 107 | +In addition to the four default roles, the dynamic role-based API checker feature |
| 108 | +allows CloudStack root admins to create new roles with customized permissions. |
| 109 | +The allow/deny rules can be configured dynamically during runtime without |
| 110 | +restarting the management server(s). |
| 111 | + |
| 112 | +For backward compatiblity, all roles resolve to one of the four role types: |
| 113 | +admin, resource admin, domain admin and user. A new role can be created using |
| 114 | +the roles tab in the UI and specifying a name, a role type and optionally a |
| 115 | +description. |
| 116 | + |
| 117 | +Role specific rules can be configured through the rules tab on role specific |
| 118 | +details page. A rule is either an API name or a wildcard string that are one of |
| 119 | +allow or deny permission and optionally a description. |
| 120 | + |
| 121 | +When a user makes an API request, the backend checks the requested API against |
| 122 | +configured rules (in the order the rules were configured) for the caller |
| 123 | +user-account's role. It will iterate through the rules and would allow the |
| 124 | +API request if the API matches an allow rule, else if it matches a deny rule |
| 125 | +it would deny the request. Next, if the request API fails to match any of |
| 126 | +the configured rules it would allow if the requested API's default authorized |
| 127 | +annotaions allow that user role type and finally deny the user API request |
| 128 | +if it fails to be explicitly allowed/denied by the role permission rules or the |
| 129 | +default API authorize annotations. Note: to avoid root admin being locked |
| 130 | +out of the system, all root admin accounts are allowed all APIs. |
| 131 | + |
| 132 | +The dynamic-roles feature is enabled by default only for all new CloudStack |
| 133 | +installations since version `4.9.x <https://cwiki.apache.org/confluence/display/CLOUDSTACK/Dynamic+Role+Based+API+Access+Checker+for+CloudStack>`_. |
| 134 | + |
| 135 | +After an upgrade, existing deployments can be migrated to use this feature by |
| 136 | +running a migration tool by the CloudStack admin. The migration tool is located |
| 137 | +at ``/usr/share/cloudstack-common/scripts/util/migrate-dynamicroles.py``. |
| 138 | + |
| 139 | +During migration, this tool enables an internal flag in the database, |
| 140 | +copies existing static role-based rules from provided commands.properties file |
| 141 | +(typically at ``/etc/cloudstack/management/commands.properties``) to the database |
| 142 | +and renames the commands.properties file (typically to |
| 143 | +/etc/cloudstack/management/commands.properties.deprecated). The migration |
| 144 | +process does not require restarting the management server(s). |
| 145 | + |
| 146 | +Usage: ``migrate-dynamicroles.py`` [options] [-h for help] |
| 147 | + |
| 148 | +Options: |
| 149 | + |
| 150 | +-b DB |
| 151 | + The name of the database, default: cloud |
| 152 | +-u USER |
| 153 | + User name a MySQL user with privileges on cloud database, default: cloud |
| 154 | +-p PASSWORD |
| 155 | + Password of a MySQL user with privileges on cloud database |
| 156 | +-H HOST |
| 157 | + Host or IP of the MySQL server |
| 158 | +-P PORT |
| 159 | + Host or IP of the MySQL server, default: 3306 |
| 160 | +-f FILE |
| 161 | + The commands.properties file, default: /etc/cloudstack/management/commands.properties |
| 162 | +-d |
| 163 | + Dry run and debug operations this tool will perform |
| 164 | + |
| 165 | + |
| 166 | +Example: |
| 167 | + |
| 168 | +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 |
| 169 | + |
| 170 | +If you've multiple management servers, remove or rename the commands.properties |
| 171 | +file on all management servers typically in /etc/cloudstack/management path, |
| 172 | +after running the migration tool for the first management server |
| 173 | + |
| 174 | + |
95 | 175 | Dedicating Resources to Accounts and Domains
|
96 | 176 | --------------------------------------------
|
97 | 177 |
|
|
0 commit comments