Home›Groups and Permissions
Groups and Permissions
Groups associate Users with Environments and help you to manage permissions, approval processes, and quotas. Groups can represent a business unit, department, team, project, or any other set of users. Permissions for Groups of Users can also be used for access and approval workflows in CloudBolt.
- In the navigation menu, hover over the Groups option.
- Click Groups for quick access to the Groups page, or view Your Groups, number of Users, Servers, Resources, and Rates for Groups and up to three levels of Sub-groups.
Each group has the same set of roles to which users can belong, and which grant permissions within that group. For example, a user could be a requester within one group and an approver in another.
Groups are stored hierarchically in CloudBolt to help you:
- Easily model organizational structures for staff.
- Delegate permission to administer the groups to the appropriate person within these organizations.
|You can define any type for Groups, but you are required to explicitly make new group types capabe of ordering resources. Navigate to Admin > System > Miscellaneous Settings. Edit Valid group types for Orders.|
Group Roles: Who Can Do What
A role allows you to assign specific privileges to group members. Those privileges apply only to resources and Environments that are associated with the group. For example, a user with the default requestor role on a group is allowed to request resources in the environments associated with the group.
By default, a resource admin role on that same group can manage any of the servers that belong to that group. There are a total of five out-of-the-box roles on groups, and you can also configure your own.
Click Admin > Roles.
- Approver: Approve any requested orders for fulfillment.
- Group Admin: Manages organizational aspects of this group: membership and permissions, subgroup creation and management, and delegation of responsibilities to other group members.
- Requestor: Request orders for creating, modifying, or deleting servers individually or within a group to which they belong.
- Resource Admin: Manage Parameters and networks on Groups, as well as Blueprints and servers.
- Viewer: Basic permission to view Group servers, members, and activity.
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.
Click Restore defaults to return all out-of-the-box roles to their default configuration. This also reinstates deleted default roles.
In the Actions column, click the curved arrow icon to restore individual out-of-the-box roles to their default configurations.
Neither of the Restore defaults actions will affect any user-defined roles.|
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.
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.