Users and Permissions¶
CloudBolt’s permissions model is composed of the following concepts:
- Users who can be created directly in CloudBolt or through an external authentication system (such as LDAP).
- Groups that contain users and are in turn associated with Environments.
- Group Roles that provide Users in a Group certain privileges for Environments associated with that Group. For example, a user could be made a requester in a group called ‘Finance Dept’, which would allow them to request servers in all Environments the Finance Dept can access.
- Special Roles that provide Users with certain privileges based on certain criteria in a given context, such as being the owner of a server. These roles are not associated with a particular Group and cannot be assigned to Users.
- Global Roles that provide Users certain sitewide privileges (such as the CloudBolt Admin role.)
The privileges afforded to roles, as described above, can include permissions for default CloudBolt functionality, such as server.control_power, as well as Server Actions and Resource Actions. The privilege of running Server and Resource Actions can be given either individually or in bulk.
Groups and Permissions¶
Group Roles: Who Can Do What¶
There are five different group roles that come out-of-the-box with CloudBolt: Viewer, Requestor, Approver, Resource Admin, and Group Admin. Each user within a group can be assigned any combination of these roles, and depending on which roles they have, a user will be given the ability to perform certain individual or group-related actions.
Administrators can customize what permissions each of these roles have as desired, or even delete them if they are not needed. In the Roles page there are buttons to both restore individual out-of-the-box roles to their default configurations and to restore all out-of-the-box roles. The latter will revive deleted default roles, but neither will affect any user-defined roles.
The table below describes the actions a user can perform with respect to each role, when the roles have their default configuration:
|Viewer||View group servers and users in a group to which they belong|
|Requestor||Request orders for creating, modifying, or deleting servers individually or within a group to which they belong|
|Approver||Approve any requested orders for fulfillment|
|Resource Admin||Manage parameters and networks on group, as well as blueprints and servers|
|Group Admin||Add CloudBolt users to their group, change roles granted to other users in the group, create and delete sub-groups, cannot access console on a server|
When viewing the Roles UI, there are separate sections for Roles Assignable to Users (Group Roles) and Special Roles. The Special Roles are not assignable, but are instead determined by context. For example, the Resource Owner role comes into play whenever determining permissions for a Resource that the user owns.
By default, these Special Roles get all of the permissions for the particular object type. For example, a Server Owner can do anything to a Server they own.
Delegated Group Administration¶
Delegated group administration allows organizations to decentralize CloudBolt administration at the group level by giving select users the ability to administer entire groups. Because by default Group Admins are only able to make changes within their group and not the entire CloudBolt instance, delegated group administration is a safe way for CloudBolt admins to delegate administrative responsibilities to others so that it may match existing organizational structure.
For example, if Barbara is the technical head of the investment banking division of a financial company, she might be given the out-of-the-box Group Admin role of the CloudBolt group called Investment Banking. As groups can be nested, Barbara could perform her own delegated group administration by creating subgroups for any Investment Banking subdivisions and give the Group Admin role for those subgroups to other users (assuming the Group Admin role has not been customized to remove those permissions). Delegation can also be accomplished on a more fine-grained level by associating permissions such as group.create_subgroup and group.manage_members with roles and assigning users to those roles in a group.
If a user has only the default Group Admin role, no other roles are automatically implied. This means that the Group Admin user would not automatically be able to request or approve orders unless they or another Group Admin gives them the appropriate roles and privileges.
Changing a User’s Role(s)¶
Roles granted to users for a particular group can be configured by going to the group details view and opening the Users tab or on the User’s profile page.
Inheritance of Group Permissions¶
There is an option on the Groups list page to enable inheritance of Group permissions from parent groups to subgroups. This applies to both internal and external users, but only Group Roles.
When inheritance is first enabled, all currently-configured Users and their Roles on any parent group will be inherited down to all its subgroups. Such inherited permissions will be marked as such in the UI, and cannot be removed from the subgroups.
From then on, while inheritance is enabled, any changes made to permissions on a parent group will be propagated down to its subgroup(s). This applies when a User is given a new Group Role (including through an “External User Sync” action) or a Role is removed for a User in that Group. A new subgroup will also automatically get its parent group’s permissions on creation.
Inheritance can be disabled from the Groups list page if it is no longer needed. It will change the existing permissions so they are no longer considered inherited and can be removed, but will not automatically remove them itself.
In addition to showing all the default Group Roles and Special Roles, the Roles page in the CloudBolt UI also allows editing those roles, creating new Group Roles, and deleting Group Roles.
The set of permissions that a user has in a particular context is the sum of all the permissions across all the Group Roles they have in the applicable group, as well as any Special Roles that apply.
A distinction should be made between the effect of having a permission on a Group Role and a Special Role. With a Group Role, that permission will apply to all objects in the Group, but with a Special Role the objects where the user will have that permission will only be those where they match the criteria of that Special Role. For example, the server.view permission in the default Viewers role means that any user with that role in a Group will be able to view all servers in that Group. However, having the server.view permission in the default Server Owner role only allows users to see servers they own.
When editing a Role, the configuration can consist of both permissions for various pieces of CloudBolt functionality (e.g., server.manage_snapshots) and giving that Role permission to run various Server Actions and Resource Actions. There are two possible approaches with regards to privileges for Actions. There are special permissions, server.all_actions and resource.all_actions, that can be used to give a Role permission to run all Server and Resource Actions, respectively. Alternatively, a Role can be given permission to only run specific Actions by using the Server Actions and Resource Actions fields.
For Special Roles, there are some limitations on what can be changed. For one, they cannot be deleted. They also cannot be renamed. When editing, the permissions and actions fields are modified according to the Role being edited to improve clarity. For example, giving non-server permissions to or associating Resource Actions with the Server Owner role doesn’t really make sense, so those options are not available.
There is a reference page that lists a bit more detail on the permission options, such as descriptions. It is linked to both from descriptions on the Roles list and within the help text for the permissions field in the Role edit dialog.
Global Roles include the CloudBolt Admin, Devops Admin, Super Admin, and API Access roles. An end user account may be granted one or all of these roles. These roles confer extra permissions to a user.
The Super Admin role gives all permissions in CB. This includes the ability to administer CB, plus full access to all groups, servers, and resources.
The Devops Admin role gives a user access to all servers without needing to belong to that server’s group.
Normally, a user may request an API token (via the Authentication endpoint), which grants them access to use the API. If this permission is disabled on a user’s profile, they will be unable to request an API token and will therefore be unable to use the API.
This permission is only present if the CB_ADMIN_ENABLED setting is set to True in `customer_settings.py`. For most CloudBolt users, using the Super Admin global role provides sufficient granularity of administrator permissions, and CloudBolt Admin is not necessary.
The CloudBolt Admin role gives a user access to the CloudBolt Admin page which allows creating and editing of all CloudBolt objects including:
- resource handlers
This admin page also lets CloudBolt Admins make changes to email notification and other global settings.
CloudBolt Admins are also the only users allowed to create top-level groups in the group tree.
CloudBolt Admins are not automatically granted any permissions on groups, servers, or resources (they only have the right to administer CloudBolt itself).